Re: [patch v4 00/27] posix-timers: Cure the SIG_IGN mess

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, Sep 27 2024 at 09:39, Eric W. Biederman wrote:
> I have stopped looking at this after patch 4.
>
> The current code can and does handle userspace injecting a signal with
> si_sys_private sent to an non-zero value using rt_sigqueueinfo(2) and
> that value will be delivered to userspace.
>
> I think the at least the ability to inject such a signal (ignoring
> si_sys_private) is very interesting for debuggers and checkpoint restart
> applications.
>
> I get the feeling the rest of the patch series depends upon not
> supporting userspace injecting signals with si_code == SI_TIMER.  That
> seems unnecessary.
>
> It seems reasonable to depend upon something like the SIGQUEUE_PREALLOC
> in the flags field of struct sigqueue to detect a kernel generated
> signal.  Rather than adding various hacks to make everything work
> with just a struct kernel_siginfo_t.  Especially as the timer signals
> today are the only signals that are preallocated.

Fair enough.

> Is there any chance 18/27 posix-timers: Embed sigqueue in struct k_itimer
> can be moved up?
>
> That should allow removing the reliance on si_sys_private.
>
> That should prevent the need to add another hack with sys_private_ptr in
> struct kernel_siginfo
>
> Perhaps what needs to happen is to update collect_signal to return the
> sigqueue entry (if it was preallocated), instead of the resched_timer.
> Then the timer code can just use container_of to get the struct
> k_itimer?
>
> After that si_sys_private can move into struct k_itimer, and the code
> won't need to worry about userspace setting that value, or about needing
> to clear that value.  As si_sys_private will always be 0 in preallocated
> signals.

Let me try that.

Thanks for taking a look!

       tglx