[PATCH 0/4] riscv: uaccess: optimizations
Jisheng Zhang
jszhang at kernel.org
Wed Jun 26 06:04:19 PDT 2024
On Tue, Jun 25, 2024 at 11:12:16AM -0700, Linus Torvalds wrote:
> On Tue, 25 Jun 2024 at 00:22, Arnd Bergmann <arnd at 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?
More information about the linux-riscv
mailing list