archive mirror
 help / color / mirror / Atom feed
From: Al Viro <>
To: Linus Torvalds <>
Cc: Christophe Leroy <>,
	Benjamin Herrenschmidt <>,
	Paul Mackerras <>,
	Michael Ellerman <>,
	Dave Airlie <>, Daniel Vetter <>,
	Andrew Morton <>,
	Kees Cook <>, Peter Anvin <>,
	Linux Kernel Mailing List <>,
	linuxppc-dev <>,
	Linux-MM <>,
	linux-arch <>,
Subject: Re: [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to user_full_access_begin/end()
Date: Fri, 3 Apr 2020 21:52:05 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Apr 03, 2020 at 11:01:10AM -0700, Linus Torvalds wrote:
> On Fri, Apr 3, 2020 at 12:21 AM Christophe Leroy
> <> wrote:
> >
> > Now we have user_read_access_begin() and user_write_access_begin()
> > in addition to user_access_begin().
> I realize Al asked for this, but I don't think it really adds anything
> to the series.
> The "full" makes the names longer, but not really any more legible.
> So I like 1-4, but am unconvinced about 5 and would prefer that to be
> dropped. Sorry for the bikeshedding.
> And I like this series much better without the cookie that was
> discussed, and just making the hard rule be that they can't nest.
> Some architecture may obviously use a cookie internally if they have
> some nesting behavior of their own, but it doesn't look like we have
> any major reason to expose that as the actual interface.
> The only other question is how to synchronize this? I'm ok with it
> going through the ppc tree, for example, and just let others build on
> that.  Maybe using a shared immutable branch with 5.6 as a base?

I can do a 5.7-rc1-based branch with that; depending upon what we end
up doing for arm and s390 we can always change the calling conventions
come next cycle ;-/

My impressions after digging through arm side of things:

1) the only instance of nesting I'd found there (so far) is a mistake.
The rule should be "no fucking nesting, TYVM".

2) I'm really unhappy about the uaccess_with_memcpy thing.  Besides
being fucking ugly, it kills any hope of lifting user_access_begin/end
out of raw_copy_to_user() - the things done in that bastard are
obviously *NOT* fit for uaccess block.  Including the wonders like
        /* the mmap semaphore is taken only if not in an atomic context */
        atomic = faulthandler_disabled();

        if (!atomic)
which, IMO, deserves to be taken out and shot.  Not that pin_page_for_write()
in the same file (arch/arm/lib/uaccess_with_memcpy.c) did not deserve the
same treatment...  As far as I can tell, the whole point of that thing
is that well, memcpy() is optimized better than raw_copy_to_user()...
So what's wrong with taking the damn optimized memcpy and using it for
raw_copy_to_user() instead?

Is that the lack of STRT analogue that would store several registers?
Because AFAICS commit f441882a5229ffaef61a47bccd4518f7e2749cbc
Author: Vincent Whitchurch <>
Date:   Fri Nov 9 10:09:48 2018 +0100
    ARM: 8812/1: Optimise copy_{from/to}_user for !CPU_USE_DOMAINS
makes for much saner solution...  I realize that it's v6+ and this
thing is specifically for a v5 variant, but...

3) how much do we need to keep the old DACR value in a register for
uaccess_restore()?  AFAICS, if we prohibit nesting it becomes
a function of USER_DS/KERNEL_DS setting (and that - only for
CPU_USE_DOMAINS), doesn't it?  And we had to have fetched it
recently, back when access_ok() had been done, so shouldn't
it be in cache?

  reply	other threads:[~2020-04-03 20:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03  7:20 [PATCH v2 1/5] uaccess: Add user_read_access_begin/end and user_write_access_begin/end Christophe Leroy
2020-04-03  7:20 ` [PATCH v2 2/5] uaccess: Selectively open read or write user access Christophe Leroy
2020-05-29  4:20   ` Michael Ellerman
2020-04-03  7:20 ` [PATCH v2 3/5] drm/i915/gem: Replace user_access_begin by user_write_access_begin Christophe Leroy
2020-05-29  4:20   ` Michael Ellerman
2020-04-03  7:20 ` [PATCH v2 4/5] powerpc/uaccess: Implement user_read_access_begin and user_write_access_begin Christophe Leroy
2020-05-29  4:24   ` Michael Ellerman
2020-04-03  7:20 ` [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to user_full_access_begin/end() Christophe Leroy
2020-04-03 18:01   ` Linus Torvalds
2020-04-03 20:52     ` Al Viro [this message]
2020-04-21  2:49       ` Al Viro
2020-04-21  9:12         ` Russell King - ARM Linux admin
2020-04-21 18:34         ` Linus Torvalds
2020-04-05 18:47     ` Christophe Leroy
2020-04-04  6:20   ` kbuild test robot
2020-04-04  7:17   ` kbuild test robot
2020-05-29  4:20 ` [PATCH v2 1/5] uaccess: Add user_read_access_begin/end and user_write_access_begin/end Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).