lkml.org 
[lkml]   [2018]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2 00/36] remove in-kernel syscall invocations (part 1)
On Thu, Mar 15, 2018 at 8:04 PM, Dominik Brodowski
<linux@dominikbrodowski.net> wrote:
> Here is a re-spin of the first set of patches which reduce the number of
> syscall invocations from within the kernel; the RFC may be found at
>
> The rationale for this change is described in patch 1 as follows:
>
> The syscall entry points to the kernel defined by SYSCALL_DEFINEx()
> and COMPAT_SYSCALL_DEFINEx() should only be called from userspace
> through kernel entry points, but not from the kernel itself. This
> will allow cleanups and optimizations to the entry paths *and* to
> the parts of the kernel code which currently need to pretend to be
> userspace in order to make use of syscalls.
>
> The whole series can be found at
>
> https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git syscalls-next
>
> and will be submitted for merging for the v4.17-rc1 cycle, probably together
> with another batch of related patches I hope to send out tomorrow as a RFC.

Nice work!

I've already commented on a few patches that now have a kernel-internal
helper function that takes a __user pointer. I think those are all only used
in the early boot code (initramfs etc) that runs before we set_fs() to the
user address space, but it also causes warnings with sparse. If we
can change all of them to take kernel pointers, that would let us avoid
the sparse warnings and start running with a normal user address space
view. Unfortunately, some of the syscall seem to be harder to change to
that than others, so not sure if it's worth the effort.

Another open question are the declarations in include/linux/syscalls.h.
These serve as a help for type-checking today, making sure that
each syscall we refer to from either the syscall table or called
by some kernel function uses the same prototype that matches
the syscall definition, which raises the question of whether we want
to keep the header around at all.

Arnd

\
 
 \ /
  Last update: 2018-03-15 22:02    [W:0.621 / U:0.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site