Re: [PATCH v2] signal: add procfd_signal() syscall

On Thu, Nov 29, 2018 at 9:14 PM Andy Lutomirski [off-list ref] wrote:

quoted

On Nov 29, 2018, at 11:55 AM, Christian Brauner [off-list ref] wrote:

quoted

On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote:

quoted

On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner [off-list ref] wrote:

quoted

On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski [off-list ref] wrote:

The #1 fix would add a copy_siginfo_from_user64() or similar.

Thanks very much! That all helped a bunch already! I'll try to go the
copy_siginfo_from_user64() way first and see if I can make this work. If
we do this I would however only want to use it for the new syscall first
and not change all other signal syscalls over to it too. I'd rather keep
this patchset focussed and small and do such conversions caused by the
new approach later. Does that sound reasonable?

Absolutely. I don’t think we can change old syscalls — the ABI is set in stone.
But for new syscalls, I think the always-64-bit behavior makes sense.

It looks like we already have a 'struct signalfd_siginfo' that is defined in a
sane architecture-independent way, so I'd suggest we use that.

We may then also want to make sure that any system call that takes a
siginfo has a replacement that takes a signalfd_siginfo, and that this
replacement can be used to implement the old version purely in
user space.

Is the current procfd_signal() proposal (under whichever name) sufficient
to correctly implement both sys_rt_sigqueueinfo() and sys_rt_tgsigqueueinfo()?
Can we implement sys_rt_sigtimedwait() based on signalfd()?
If yes, that would leave waitid(), which already needs a replacement
for y2038, and that should then also return a signalfd_siginfo.
My current preference for waitid() would be to do a version that
closely resembles the current interface, but takes a signalfd_siginfo
and a __kernel_timespec based rusage replacement (possibly
two of them to let us map wait6), but does not operate on procfd or
take a signal mask. That would require yet another syscall, but I
don't think I can do that before we want to have the set of y2038
safe syscalls.

       Arnd