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:6.522 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site