linux-kernel - Re: [RFC] clang: 'unused-function' warning on static inline functions

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: <CAK8P3a2H6enP0dsFRcf9pumRg1wxhVpynQYJooiMQRUGpCvQHQ@mail.gmail.com>
Date:   Wed, 7 Jun 2017 10:17:18 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     Matthias Kaehlcke <mka@...omium.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Christoph Hellwig <hch@....de>,
        Steven Rostedt <rostedt@...dmis.org>,
        David Rientjes <rientjes@...gle.com>,
        Douglas Anderson <dianders@...omium.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Mark Brown <broonie@...nel.org>,
        David Miller <davem@...emloft.net>
Subject: Re: [RFC] clang: 'unused-function' warning on static inline functions

On Tue, Jun 6, 2017 at 11:29 PM, Jens Axboe <axboe@...nel.dk> wrote:
> On 06/06/2017 03:23 PM, Matthias Kaehlcke wrote:
>> El Tue, Jun 06, 2017 at 09:32:35AM -0700 Linus Torvalds ha dit:
>>
>>> On Tue, Jun 6, 2017 at 4:16 AM, Arnd Bergmann <arnd@...db.de> wrote:
>>>>
>>>> Those should all be fairly easy to address, I'd vote for leaving the
>>>> warning enabled
>>>> in clang, and possibly asking the gcc maintainers to add a similar feature for
>>>> warning about it.
>>>
>>> Hell no. That warning is pointless shit.
>>
>> I tend to disagree, the warning is useful to detect truly unused
>> static inline functions, which should be removed, rather than be
>> carried around/maintained for often long periods of time.
>
> One example is the patch sent for CFQ, which has macros for define
> functions for setting/clearing bits on the queue:
>
> #define CFQ_CFQQ_FNS(name)
>
> for one bit, we never clear the bit after we set it, we only set it and
> later test for it. Hence the clear variant of that function is unused.
>
> Now I get a warning. The fix to that would be to define a new variant of
> CFQ_CFQQ_FNS() that only declares the exact one I need for the version
> that is never cleared.
>
> Or the fix is to just ignore the bogus warning on an unused inline.  I
> greatly prefer the latter.
>
> The counter example is this one:
>
> http://git.kernel.dk/cgit/linux-block/commit/?id=03ea8ad78cfb2910862c8dfcd2a627fc04097db2
>
> where it is truly just dead junk. I'd rather just leave the dead junk
> than have pointless warnings, if I have to choose one of the two
> outcomes.

This is a relatively rare case, with an inline function defined by a macro, and
I sent a patch for a similar one in 1f318a8bafcf ("modules: mark
__inittest/__exittest
as __maybe_unused"). I think this is a case where the __maybe_unused
annotation is reasonable, though for the other instances of unused inline
functions in .c files, there is often a better way: typically the only caller
of a function is inside of an #ifdef and moving the inline function definition
into the same #ifdef block makes it clearer what is going on.

      Arnd