[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0e5985d7-e73b-455b-6b05-351831f09340@c-s.fr>
Date: Sun, 5 Apr 2020 20:47:26 +0200
From: Christophe Leroy <christophe.leroy@....fr>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Michael Ellerman <mpe@...erman.id.au>
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Dave Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Al Viro <viro@...iv.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>, Peter Anvin <hpa@...or.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
Linux-MM <linux-mm@...ck.org>,
linux-arch <linux-arch@...r.kernel.org>,
intel-gfx@...ts.freedesktop.org
Subject: Re: [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to
user_full_access_begin/end()
Le 03/04/2020 à 20:01, Linus Torvalds a écrit :
> On Fri, Apr 3, 2020 at 12:21 AM Christophe Leroy
> <christophe.leroy@....fr> 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.
>
Yes I was not sure about it, that's the reason why I added it as the
last patch of the series.
And in the meantime, we see Robots reporting build failures due to
additional use of user_access_begin() in parallele to this change, so I
guess it would anyway be a challenge to perform such a change without
coordination.
> 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?
Michael, can you take patches 1 to 4 ?
Otherwise, can you ack patch 4 to enable merging through another tree ?
Christophe
Powered by blists - more mailing lists