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?
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent 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