Re: [PATCH] [PATCH v2] mm: initialize 'seq' in gup_fast to remove -Wmaybe-uninitialized warning

[Alexey Suchkov]

> 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; 
     |		^~~