linux-kernel - Re: [PATCH v2 1/3] base: mark 'no

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YP+ql3QFYnefR/Cf@kroah.com>
Date:   Tue, 27 Jul 2021 08:41:27 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Bill Wendling <morbo@...gle.com>
Cc:     Nathan Chancellor <nathan@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] base: mark 'no_warn' as unused

On Mon, Jul 26, 2021 at 11:15:52PM -0700, Bill Wendling wrote:
> On Mon, Jul 26, 2021 at 10:27 PM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > On Mon, Jul 26, 2021 at 01:47:33PM -0700, Nathan Chancellor wrote:
> > > + Greg and Rafael as the maintainer and reviewer of drivers/base/module.c
> > > respectively, drop everyone else.
> >
> > Odd no one cc:ed us originally, I guess they didn't want the patch ever
> > merged?  :(
> >
> > >
> > > Original post:
> > >
> > > https://lore.kernel.org/r/20210726201924.3202278-2-morbo@google.com/
> > >
> > > On 7/26/2021 1:19 PM, 'Bill Wendling' via Clang Built Linux wrote:
> > > > Fix the following build warning:
> > > >
> > > >    drivers/base/module.c:36:6: error: variable 'no_warn' set but not used [-Werror,-Wunused-but-set-variable]
> > > >          int no_warn;
> >
> > That's not going to be a good warning to ever have the kernel use due to
> > how lots of hardware works (i.e. we need to do a read after a write but
> > we can throw the read away as it does not matter).
> >
> >
> > > >
> > > > This variable is used to remove another warning, but causes a warning
> > > > itself. Mark it as 'unused' to avoid that.
> > > >
> > > > Signed-off-by: Bill Wendling <morbo@...gle.com>
> > >
> > > Even though they evaluate to the same thing, it might be worth using
> > > "__always_unused" here because it is :)
> >
> > But it is not unused, the value is written into it.
> >
> I believe that only matters if the variable is marked "volatile".

"volatile" means nothing anymore, never use it or even think about it
again please :)

> Otherwise, the variable itself is never used. A "variable that's
> written to but not read from," in fact, is the whole reason for the
> warning.

But that is ok!  Sometimes you need to do this with hardware (like all
PCI devices).  This is a legitimate code flow for many hardware types
and if a C compiler thinks that this is not ok, then it is broken.

So be VERY careful when changing drivers based on this warning.  Because
of this, I do not think you can enable it over the whole kernel without
causing major problems in some areas.

But that is independent of this specific issue you are trying to patch
here, I say this to warn you of a number of stupid places where people
have tried to "optimize away" reads based on this compiler warning in
drivers, and we have had to add them back because it broke
functionality.

> > So this isn't ok, sometimes we want to write to variables but never care
> > about the value, that does not mean the compiler should complain about
> > it.
> >
> Typically, if you don't care about the return value, you simply don't
> assign it to a variable (cf. printf). However, the functions that
> assign to "no_warn" have the "warn_unused_result" attribute. The fact
> that the variable is named "no_warn" seems to indicate that it's meant
> to remain unused, even if it probably should be checked.

These functions have warn_unused_result set on them because for 99% of
the time, I want the value to be checked.  But as you can see in this
use, as per the comments in the code, we do not care about the result
for a very good reason.  So we just assign it to a variable to make the
compiler quiet.

> Would you rather the warning be turned off on some level?

Which warning?

The code here, as-is, is correct.  We already have 1 compiler warning
work around in place, do you want to add another one?  How many can we
stack on top of each other?

And again, why did you not cc: the maintainers of this code for this
change?  That's not good...

thanks,

greg k-h