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

On Fri, Nov 30, 2018 at 3:40 PM Christian Brauner [off-list ref] wrote:

On December 1, 2018 12:12:53 PM GMT+13:00, Arnd Bergmann [off-list ref] wrote:

quoted

On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione [off-list ref]
wrote:

quoted

On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner

[off-list ref] wrote:

quoted

quoted

On December 1, 2018 11:09:58 AM GMT+13:00, Arnd Bergmann

[off-list ref] wrote:

quoted

quoted

One humble point I would like to make is that what I care about

most is a sensible way forward without having to redo essential parts
of how syscalls work.

quoted

quoted

I don't want to introduce a sane, small syscall that ends up

breaking all over the place because we decided to fix past mistakes
that technically have nothing to do with the patch itself.

quoted

quoted

However, I do sympathize and understand these concerns.

IMHO, it's fine to just replicate all the splits we have for the
existing signal system calls. It's ugly, but once it's done, it'll be
done for a long time. I can't see a need to add even more signal
system calls after this one.

We definitely need waitid_time64() and rt_sigtimedwait_time64()
in the very near future.

Right, I remember you pointing this out in a prior mail.
Thanks for working on this for such a long time now, Arnd!
Can we agree to move on with the procfd syscall given the current constraints?
I just don't want to see the syscall being
blocked by a generic problem whose
ultimate solution is to get rid of weird
architectural constraints.

Creating and using a copy_siginfo_from_user64() function would work
for everyone, no?