Re: [PATCH v2 00/36] remove in-kernel syscall invocations (part 1)

[Dominik Brodowski]

On Thu, Mar 15, 2018 at 10:02:04PM +0100, Arnd Bergmann wrote:
> On Thu, Mar 15, 2018 at 8:04 PM, Dominik Brodowski
> <linux@xxxxxxxxxxxxxxxxxxxx> 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.

Thanks for your review -- on this issue, please see my other messages.

> 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.

Well, we do not want to call syscalls from other kernel functions, so that
issue will go away by means of these patchsets anyway. With regard to
type-checking the syscall table, we might want to keep the definitions
around and/or generate prototypes from SYSCALL_DEFINEx() directly.

Thanks,
	Dominik