Re: [PATCH] [v2] waitqueue: shut up clang -Wuninitialized warnings

[Nick Desaulniers]

On Tue, Jul 23, 2019 at 1:22 PM Nathan Chancellor
<natechancellor@xxxxxxxxx> wrote:
>
> On Tue, Jul 23, 2019 at 01:03:05PM +0200, Arnd Bergmann wrote:
> > On Tue, Jul 23, 2019 at 12:50 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > > On Fri, Jul 19, 2019 at 01:36:00PM +0200, Arnd Bergmann wrote:
> > > > --- a/include/linux/wait.h
> > > > +++ b/include/linux/wait.h
> > > > @@ -70,8 +70,17 @@ extern void __init_waitqueue_head(struct wait_queue_head *wq_head, const char *n
> > > >  #ifdef CONFIG_LOCKDEP
> > > >  # define __WAIT_QUEUE_HEAD_INIT_ONSTACK(name) \
> > > >       ({ init_waitqueue_head(&name); name; })
> > > > -# define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) \
> > > > +# if defined(__clang__) && __clang_major__ <= 9
> > > > +/* work around https://bugs.llvm.org/show_bug.cgi?id=42604 */
> > > > +#  define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name)                                      \
> > > > +     _Pragma("clang diagnostic push")                                        \
> > > > +     _Pragma("clang diagnostic ignored \"-Wuninitialized\"")                 \
> > > > +     struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)      \
> > > > +     _Pragma("clang diagnostic pop")
> > > > +# else
> > > > +#  define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) \
> > > >       struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> > > > +# endif
> > >
> > > While this is indeed much better than before; do we really want to do
> > > this? That is, since clang-9 release will not need this, we're basically
> > > doing the above for pre-release compilers only.
> >
> > Kernelci currently builds arch/arm and arch/arm64 kernels with clang-8,
> > and probably won't change to clang-9 until after that is released,
> > presumably in September.
> >
> > Anyone doing x86 builds would use a clang-9 snapshot today
> > because of the asm-goto support, but so far the fix has not
> > been merged there either. I think the chances of it getting
> > fixed before the release are fairly good, but I don't know how
> > long it will actually take.
> >
> >        Arnd
>
> Furthermore, while x86 will only be supported by clang-9 and up, there
> are other architectures/configurations that work with earlier versions
> that will never see that fix. There are a few people that still use
> clang-7 for example.
>
> In an ideal world, everyone should be using the latest version of clang
> because of all of the fixes and improvements that are going into that
> latest version but the same can be said of any piece of software. I am
> not sure that it is fair to force someone to upgrade when it works for
> them. Not everyone runs Ubuntu/Debian to get access to apt.llvm.org
> builds or wants to add random repositories to their list or wants to
> build clang from source.
>
> I suppose it comes down to policy: if we don't want to support versions
> of LLVM before 9.x then we should just break the build when it is
> detected but Nick has spoken out against that and I think that he has a
> fair point.
>
> https://lore.kernel.org/lkml/CAKwvOdnzrMOCo4RRsfcR=K5ELWU8obgMqtOGZnx_avLrArjpRQ@xxxxxxxxxxxxxx/

Note that pre-clang-9 can be used for LTS x86_64; I don't think
CONFIG_JUMP_LABEL was made mandatory for x86 until 4.20 release, IIRC.
There's only a small window of non LTS kernels and only for x86 where
clang-9+ is really necessary.

Thanks,
~Nick Desaulniers