Message-ID: <CAK8P3a3_dPbjB23QffnYMtw+5ojfwChrVC8LLMQqNctU7Nh+mQ@mail.gmail.com>
Date:   Thu, 17 Feb 2022 08:49:59 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Christophe Leroy <christophe.leroy@...roup.eu>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Christoph Hellwig <hch@....de>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "dalias@...c.org" <dalias@...c.org>,
        "linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
        "linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "jcmvbkbc@...il.com" <jcmvbkbc@...il.com>,
        "guoren@...nel.org" <guoren@...nel.org>,
        "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
        "linux-hexagon@...r.kernel.org" <linux-hexagon@...r.kernel.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "will@...nel.org" <will@...nel.org>,
        "ardb@...nel.org" <ardb@...nel.org>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "bcain@...eaurora.org" <bcain@...eaurora.org>,
        "deller@....de" <deller@....de>, "x86@...nel.org" <x86@...nel.org>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "geert@...ux-m68k.org" <geert@...ux-m68k.org>,
        "linux-snps-arc@...ts.infradead.org" 
        <linux-snps-arc@...ts.infradead.org>,
        "linux-xtensa@...ux-xtensa.org" <linux-xtensa@...ux-xtensa.org>,
        "hca@...ux.ibm.com" <hca@...ux.ibm.com>,
        "linux-alpha@...r.kernel.org" <linux-alpha@...r.kernel.org>,
        "linux-um@...ts.infradead.org" <linux-um@...ts.infradead.org>,
        "linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
        "openrisc@...ts.librecores.org" <openrisc@...ts.librecores.org>,
        "green.hu@...il.com" <green.hu@...il.com>,
        "shorne@...il.com" <shorne@...il.com>,
        "monstr@...str.eu" <monstr@...str.eu>,
        "tsbogend@...ha.franken.de" <tsbogend@...ha.franken.de>,
        "linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
        "nickhu@...estech.com" <nickhu@...estech.com>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "dinguyen@...nel.org" <dinguyen@...nel.org>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        "richard@....at" <richard@....at>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good

On Thu, Feb 17, 2022 at 8:20 AM Christophe Leroy
<christophe.leroy@...roup.eu> wrote:
> Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> >
> > Christoph Hellwig and a few others spent a huge effort on removing
> > set_fs() from most of the important architectures, but about half the
> > other architectures were never completed even though most of them don't
> > actually use set_fs() at all.
> >
> > I did a patch for microblaze at some point, which turned out to be fairly
> > generic, and now ported it to most other architectures, using new generic
> > implementations of access_ok() and __{get,put}_kernel_nocheck().
> >
> > Three architectures (sparc64, ia64, and sh) needed some extra work,
> > which I also completed.
> >
> > The final series contains extra cleanup changes that touch all
> > architectures. Please review and test these, so we can merge them
> > for v5.18.
>
> As a further cleanup, have you thought about making a generic version of
> clear_user() ? On almost all architectures, clear_user() does an
> access_ok() then calls __clear_user() or similar.

This already exists in include/asm-generic/uaccess.h, but that file is
currently not as easy to use as it should be. I've previously looked into
what it would take to get more architectures to use common code
in that file, but I currently have no plans to work on that.

> Maybe also the same with put_user() and get_user() ? After all it is
> just access_ok() followed by __put_user() or __get_user() ? It seems
> more tricky though, as some architectures seems to have less trivial
> stuff there.

Same here: architectures can already provide a __put_user_fn()
and __get_user_fn(), to get the generic versions of the interface,
but few architectures use that. You can actually get all the interfaces
by just providing raw_copy_from_user() and raw_copy_to_user(),
but the get_user/put_user versions you get from that are fairly
inefficient.

> I also see all architectures have a prototype for strncpy_from_user()
> and strnlen_user(). Could be a common prototype instead when we have
> GENERIC_STRNCPY_FROM_USER / GENERIC_STRNLEN_USER
>
> And we have also
> user_access_begin()/user_read_access_begin()/user_write_access_begin()
> which call access_ok() then do the real work. Could be made generic with
> call to some arch specific __user_access_begin() and friends after the
> access_ok() and eventually the might_fault().

In my opinion, the biggest win would be to move the type-agnostic part of
get_user/put_user into completely generic code, this is what architectures
get wrong the most, see patch 02/18 in this series for instance.

What I'd like to see is that architectures only provide fixed-length
versions of unsafe_get_user()/unsafe_put_user(), with the type-agnostic
versions (get_user(), __get_user(), unsafe_get_user() and their put
versions) all defined once in include/linux/uaccess.h based on those.

I tried implementing this in the past, but unfortunately the resulting
object code from my generalized implementation was worse than
what we have today, so I did not continue that work.

      Arnd

Powered by blists - more mailing lists