On Tue, May 15, 2018 at 12:01:58PM +0200, Dominik Brodowski wrote: > On Tue, May 15, 2018 at 09:22:23AM +0100, Mark Rutland wrote: > > On Mon, May 14, 2018 at 10:24:45PM +0200, Dominik Brodowski wrote: > > > On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote: > > > > I agree it would be nicer if it had a wrapper that took a pt_regs, even > > > > if it does nothing with it. > > > > > > > > We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd > > > > need a ksys_ni_syscall() for our traps.c logic, and adding this > > > > uniformly would involve some arch-specific rework for x86, too, so I > > > > decided it was not worth the effort. > > > > > > Couldn't you just open-code the "return -ENOSYS;" in traps.c? > > > > I guess so. I was just worried that debug logic might be added to the generic > > ni_syscall() in future, and wanted to avoid potential divergence. > > > > > Error injection has no reasonable stable ABI/API expectations, so that's not > > > a show-stopper either. > > > > If people are happy with using SYSCALL_DEFINE0() for ni_syscall, I'm happy to > > do that -- it's just that we'll need a fixup for x86 as that will change the > > symbol name. > > For me, it's less about using SYSCALL_DEFINE0() for ni_syscall, but more > about keeping the syscall invokation easy. Therefore, we do pass a pointer > struct pt_regs to sys_ni_syscall() on x86, even though it does not expect > it. > > /* this is a lie, but it does not hurt as sys_ni_syscall just returns -EINVAL */ > extern asmlinkage long sys_ni_syscall(const struct pt_regs *); Oh, sure, we do the same on arm64 in this series. Having a pt_regs wrapper for it (e.g. using SYSCALL_DEFINE0()) would allow us to avoid that lie (which might be best for CFI stuff), would allow us to avoid some name mangling on arm64, and would seemingly confuse people less. Thanks, Mark.
