linux-kernel - Re: [PATCH] iov_iter: separate direction from flavour

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-=wjFOoSvSXfm0N_y0eHRM_C-Ki+-9Y7QzfLdJ9B8h1QFuw@mail.gmail.com>
Date:   Sun, 4 Jul 2021 15:53:09 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Guenter Roeck <linux@...ck-us.net>, Christoph Hellwig <hch@....de>,
        Al Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        David Sterba <dsterba@...e.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        Anton Altaparmakov <anton@...era.com>,
        David Howells <dhowells@...hat.com>,
        Pavel Begunkov <asml.silence@...il.com>
Subject: Re: [PATCH] iov_iter: separate direction from flavour

On Sun, Jul 4, 2021 at 3:47 PM Matthew Wilcox <willy@...radead.org> wrote:
>
>
> We could slip:
>
> #ifndef uaccess_user
> #define uaccess_user() !uaccess_kernel()
> #endif
>
> into asm-generic, switch the test over and then make it arm/m68k's
> problem to define uaccess_user() to true?

Yeah, except at this point I suspect I'll just remove that WARN_ON_ONCE().

I liked it as long as it wasn't giving these false positives. It's
conceptually the right thing to do, but it's also the case that only
CONFIG_SET_FS architectures can trigger it, and none of them get any
real testing or matter much any more.

All the truly relevant architectures have been converted away from set_fs().

And it's actually fairly hard to get this wrong even if you do have
CONFIG_SET_FS - because no generic code does set_fs() any more, so you
*really* have to screw up the few cases where you do it in your own
architecture code.

If it had been easy to fix I'd have kept it, but this amount of pain
isn't worth it - I just don't want to add extra code for architectures
that do things wrong and don't really matter any more.

             Linus