linux-kernel - Re: [PATCH] userns: suppress kmemleak message

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] [day] [month] [year] [list]

Message-ID: <CAJAFBLDx3eexWQs1L08NFGBwQcvXsgfP3_w3V+2zMgGP-jDDpA@mail.gmail.com>
Date:   Fri, 16 Dec 2016 14:52:58 +0100
From:   Fubo Chen <fubo.chen@...il.com>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Jakub Kicinski <kubakici@...pl>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Maciej Żenczykowski <zenczykowski@...il.com>
Subject: Re: [PATCH] userns: suppress kmemleak message

On Fri, Dec 16, 2016 at 10:39 AM, Johannes Berg
<johannes@...solutions.net> wrote:
>
>> > I can't see the using kmemleak_not_leak is possibly good form.  I
>> > would much rather have suggestions about constructs that won't
>> > confuse kmemleak and won't need ugly annotations that serve no
>> > purpose but to appease a tool.  Perhaps the user_header variable
>> > needs to be moved out of user_namespace_sysctl_init.
>
> The user_header variable is probably (rightfully so) optimised away by
> the compiler since it can't ever be read. Therefore, it simply doesn't
> exist in the resulting binary (and it really shouldn't either) and the
> kmemleak_not_leak() really is the only way to resolve that, I'd say.
>
>> The only alternative I see is to use WRITE_ONCE() instead of "=" to
>> set "user_header" such that the compiler cannot optimize that
>> variable away. Which of these two approaches do you prefer?
>
> That seems really wrong - forcing the linker/compiler to retain a
> variable in the image that can never possibly be read (by anything
> other than kmemleak) is just a complete waste of space.

Does this reply count as a Reviewed-by for the original patch?

Fubo.