The local variable 'seq' in gup_fast (mm/gup.c) was declared
without initialization, which can trigger:

mm/gup.c:3165:20: warning: ‘seq’ may be used uninitialized [-Wmaybe-uninitialized]

Initialize 'seq' to 0. This does not change behavior, since
read_seqcount_retry() always writes to it before use.

Changes since v1:
- Removes the accidental formatting from v1.

Signed-off-by: Alexey Suchkov <dywoq.contact@gmail.com>
---
 mm/gup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/gup.c b/mm/gup.c
index 8e7dc2c6e..879798de5 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -3131,7 +3131,7 @@ static unsigned long gup_fast(unsigned long start, unsigned long end,
 {
 	unsigned long flags;
 	int nr_pinned = 0;
-	unsigned seq;
+	unsigned int seq = 0;
 
 	if (!IS_ENABLED(CONFIG_HAVE_GUP_FAST) ||
 	    !gup_fast_permitted(start, end))
-- 
2.53.0

On Mon,  2 Mar 2026 22:34:05 +0300 Alexey Suchkov <aleks.koyf@gmail.com> wrote:

> The local variable 'seq' in gup_fast (mm/gup.c) was declared
> without initialization, which can trigger:
> 
> mm/gup.c:3165:20: warning: ‘seq’ may be used uninitialized [-Wmaybe-uninitialized]
> 
> Initialize 'seq' to 0. This does not change behavior, since
> read_seqcount_retry() always writes to it before use.
> 
> ...
>
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -3131,7 +3131,7 @@ static unsigned long gup_fast(unsigned long start, unsigned long end,
>  {
>  	unsigned long flags;
>  	int nr_pinned = 0;
> -	unsigned seq;
> +	unsigned int seq = 0;
>  
>  	if (!IS_ENABLED(CONFIG_HAVE_GUP_FAST) ||
>  	    !gup_fast_permitted(start, end))

stupid gcc.  I liked uninitalized_var(), particularly for its
self-documenting nature.  Never agreed with Linus's hate on it.

Thanks, I tweaked the changelog a bit:

: The local variable 'seq' in gup_fast (mm/gup.c) was declared
: without initialization, which with gcc-15.2.1 can trigger:
: 
: mm/gup.c:3165:20: warning: `seq' may be used uninitialized [-Wmaybe-uninitialized]
: 
: Work around this by initializing 'seq' to 0.  This does not change
: behavior, since read_seqcount_retry() always writes to it before use.

On Mon,  2 Mar 2026 22:34:05 +0300 Alexey Suchkov <aleks.koyf@gmail.com> wrote:

> The local variable 'seq' in gup_fast (mm/gup.c) was declared
> without initialization, which can trigger:
> 
> mm/gup.c:3165:20: warning: ‘seq’ may be used uninitialized [-Wmaybe-uninitialized]
> 
> Initialize 'seq' to 0. This does not change behavior, since
> read_seqcount_retry() always writes to it before use.

Hi Alexey, I hope you're doing well!

Unfortunately I think that this patch is still unneeded. The variable seq is
used in two places, raw_seqcount_try_begin and read_seqcount_retry, and nowhere
else in the function. Both are guarded by if (gup_flags & FOLL_PIN).

raw_seqcount_try_begin is a macro that sets the value of seq.
read_seqcount_retry is a macro that indeed reads the value of seq, but at
that point seq has already been initialized by raw_seqcount_try_begin.

So I am having a hard time seeing where it would ever be used in an
uninitialized context. The compiler should be smart enough to expand the
macro, see that the writer and consumer are under the same if conditions,
and realize that it is always initialized before being used.

I'm curious to know if the compilation warning above is theoretical, or
if you've actually it it during compilation.

Let me know what you think. Have a great day!
Joshua

> Changes since v1:
> - Removes the accidental formatting from v1.
> 
> Signed-off-by: Alexey Suchkov <dywoq.contact@gmail.com>
> ---
>  mm/gup.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/gup.c b/mm/gup.c
> index 8e7dc2c6e..879798de5 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -3131,7 +3131,7 @@ static unsigned long gup_fast(unsigned long start, unsigned long end,
>  {
>  	unsigned long flags;
>  	int nr_pinned = 0;
> -	unsigned seq;
> +	unsigned int seq = 0;
>  
>  	if (!IS_ENABLED(CONFIG_HAVE_GUP_FAST) ||
>  	    !gup_fast_permitted(start, end))
> -- 
> 2.53.0

> Hi Alexey, I hope you're doing well!
> 
> Unfortunately I think that this patch is still unneeded. The variable seq is
> used in two places, raw_seqcount_try_begin and read_seqcount_retry, and nowhere
> else in the function. Both are guarded by if (gup_flags & FOLL_PIN).
>
> raw_seqcount_try_begin is a macro that sets the value of seq.
> read_seqcount_retry is a macro that indeed reads the value of seq, but at
> that point seq has already been initialized by raw_seqcount_try_begin.

> So I am having a hard time seeing where it would ever be used in an
> uninitialized context. The compiler should be smart enough to expand the
> macro, see that the writer and consumer are under the same if conditions,
> and realize that it is always initialized before being used.
>
> I'm curious to know if the compilation warning above is theoretical, or
> if you've actually it it during compilation.
>
> Let me know what you think. Have a great day!
> Joshua

Hi Joshua,

Thanks for your review. I did see this warning in practice with GCC 15.2.1 and "make -j$(nproc) W=2":

In function ‘gup_fast’, 
	inlined from ‘gup_fast_fallback’ at mm/gup.c:3202:14: 
mm/gup.c:3165:20: warning: ‘seq’ may be used uninitialized [-Wmaybe-uninitialized] 
3165 | 		if (read_seqcount_retry(&current->mm->write_protect_seq, seq)) { 
     | 									  ^ 
mm/gup.c: In function ‘gup_fast_fallback’: 
mm/gup.c:3134:18: note: ‘seq’ was declared here 
3134 | unsigned seq; 
     |		^~~

On Mon, Mar 02, 2026 at 11:48:35AM -0800, Joshua Hahn wrote:
> Unfortunately I think that this patch is still unneeded. The variable seq is
> used in two places, raw_seqcount_try_begin and read_seqcount_retry, and nowhere
> else in the function. Both are guarded by if (gup_flags & FOLL_PIN).

Yeah, historically GCC wasn't great with that pattern.  It failed to
notice that the condition was the same and so there was no path through
the code that would use an uninit variable.  Hence my question about
what compiler version he's using to see whether we can disregard this
because it's an old compiler that we don't support any more.

On Mon, Mar 02, 2026 at 10:34:05PM +0300, Alexey Suchkov wrote:
> The local variable 'seq' in gup_fast (mm/gup.c) was declared
> without initialization, which can trigger:
> 
> mm/gup.c:3165:20: warning: ‘seq’ may be used uninitialized [-Wmaybe-uninitialized]
> 
> Initialize 'seq' to 0. This does not change behavior, since
> read_seqcount_retry() always writes to it before use.

What compiler?

> What compiler?
My compiler is GCC 15.2.1