linux-kernel - Re: rename probe_kernel_* and probe_user

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: <CAHk-=wi+bj=CYNSOKRK7AFg32BBxHCeEWxWWxSggDE+wTGqtrg@mail.gmail.com>
Date:   Wed, 17 Jun 2020 11:19:59 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: rename probe_kernel_* and probe_user_*

On Wed, Jun 17, 2020 at 11:11 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> I'm actually a bit surprised that we don't even get a warning for that
> horrible pattern that smells a bit like the gcc 'cast as lvalue'
> thing.

Oh, it's because I once again got confused by the naming.

"get_kernel_nofault()" doesn't have the "get_user()" semantics despite
being written like it. The arguments are in the reverse order, and the
pointer cast is on the address, not the target.

It's more obvious in the code, but not when grepping for things and
being used to the (much MUCH more common) get_user() semantics.

I really think get_kernel_nofault() should reverse the order of
arguments, because right now that "[PATCH 3/3] maccess: rename
probe_kernel_address to get_kernel_nofault" is really really
confusing.

You rename the function to look and act like get_user() (except for
kernel accesses, of course), but you leave it with an argument order
that is very much the reverse of what get_user() has.

So no. I won't be merging this series after all.

           Linus