public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jisheng Zhang <jszhang@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] riscv: uaccess: optimizations
Date: Wed, 26 Jun 2024 21:04:19 +0800	[thread overview]
Message-ID: <ZnwR0_MkAJW6i5sk@xhacker> (raw)
In-Reply-To: <CAHk-=wjDrx1XW1oEuUap=MN+Ku_FqFXQAwDJhyC5Q1CJkgBbFA@mail.gmail.com>

On Tue, Jun 25, 2024 at 11:12:16AM -0700, Linus Torvalds wrote:
> On Tue, 25 Jun 2024 at 00:22, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > I think the only bets we really need from an architecture
> > here are:
> >
> > - __enable_user_access()/__disable_user_access() in
> >    the label version
> 
> KCSAN wants user_access_save/restore() too, but yes.
> 
> > - __raw_get_mem_{1,2,4,8}() and __raw_put_mem_{1,2,4,8}()
> 
> You still need to split it into user/kernel.
> 
> Yes, *often* there is just one address space and they can be one "mem"
> accessor thing, but we do have architectures with actually separate
> user and kernel address spaces.
> 
> But yes, it would be lovely if we did things as "implement the
> low-level accessor functions and we'll wrap them for the generic case"
> rather than have every architecture have to do the wrapping..
> 
> The wrapping isn't just the label-based "unsafe" accesses and the
> traditional error number return case, it's also the size-based case
> statements ("poor man's generics").
> 
> The problem, of course, is that the majority of architectures are
> based on the legacy interfaces, so it's a lot of annoying low-level
> small details. I think there's a reason why nobody did the arm64
> "unsafe" ones - the patch didn't end up being that bad, but it's just
> fairly grotty code.
> 
> But apparently the arm64 patch was simple enough that at least RISC-V
> people went "that doesn't look so bad".
> 
> Maybe other architectures will also be fairly straightforward when
> there's a fairly clear example of how it should be done.

>> We have something like this already on powerpc and x86,
>> and Linus just did the version for arm64, which I assume
>> you are using as a template for this. Four architectures

Yep, this series is inspired by Linus's patch series, and to be honest,
some code is borrowed from his arm64 version ;) I saw he improved
arm64, then I thought a nice improvement we want for riscv too, can I do
similarly for riscv? 

  reply	other threads:[~2024-06-26 13:18 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-25  4:04 [PATCH 0/4] riscv: uaccess: optimizations Jisheng Zhang
2024-06-25  4:04 ` [PATCH 1/4] riscv: implement user_access_begin and families Jisheng Zhang
2024-06-26 23:38   ` Cyril Bur
2024-06-25  4:04 ` [PATCH 2/4] riscv: uaccess: use input constraints for ptr of __put_user Jisheng Zhang
2024-06-25  5:54   ` Arnd Bergmann
2024-06-26 12:32     ` Jisheng Zhang
2024-06-26 12:49       ` Jisheng Zhang
2024-06-26 13:18         ` Jisheng Zhang
2024-06-26 13:35         ` Andreas Schwab
2024-06-26 13:54           ` Jisheng Zhang
2024-06-26 13:12   ` Andreas Schwab
2024-06-26 13:12     ` Jisheng Zhang
2024-06-26 14:25       ` Arnd Bergmann
2024-06-26 16:02         ` Jisheng Zhang
2024-06-27  6:46           ` Arnd Bergmann
2024-06-28 15:36         ` David Laight
2024-06-25  4:04 ` [PATCH 3/4] riscv: uaccess: use 'asm goto' for put_user() Jisheng Zhang
2024-07-05  2:22   ` kernel test robot
2024-07-06  0:02   ` kernel test robot
2024-06-25  4:05 ` [PATCH 4/4] riscv: uaccess: use 'asm goto output' for get_user Jisheng Zhang
2024-07-05  4:13   ` kernel test robot
2024-06-25  7:21 ` [PATCH 0/4] riscv: uaccess: optimizations Arnd Bergmann
2024-06-25 18:12   ` Linus Torvalds
2024-06-26 13:04     ` Jisheng Zhang [this message]
2024-06-30 16:59     ` Linus Torvalds
2024-07-05 11:25       ` Will Deacon
2024-07-05 17:58         ` Linus Torvalds
2024-07-08 13:52           ` Will Deacon
2024-07-08 15:30             ` Mark Rutland
2024-07-23 14:16               ` Will Deacon
2024-07-08 15:21           ` Mark Rutland
2024-07-24 22:57 ` Palmer Dabbelt

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=ZnwR0_MkAJW6i5sk@xhacker \
    --to=jszhang@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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