Hi,
On 02/05/18 11:21, luca abeni wrote:
> Hi,
>
> On Mon, 30 Apr 2018 12:41:47 +0200
> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> wrote:
> [...]
> > >> 2. Possibly, I am misreading the code, but the SIGXCPU signal
> > >> appears to be a process-directed signal, rather than a
> > >> thread-directed signal? Am I correct, and if so, is that really
> > >> the desired behavior?
> > >>
> > >
> > > Actually, I can't remember and need to check the code.
> >
> > So, I went back and reviewed the kernel course. Indeed the signal
> > seems to be process-directed:
> >
> > static inline void check_dl_overrun(struct task_struct *tsk)
> > {
> > if (tsk->dl.dl_overrun) {
> > tsk->dl.dl_overrun = 0;
> > __group_send_sig_info(SIGXCPU, SEND_SIG_PRIV, tsk);
> > }
> > }
> >
> > __group_send_sig_info() sends a signal to a thread group.
> >
> > This smells buggy. In sched_setattr(), we are setting per-thread
> > scheduling attributes. Surely, the signal should be thread-directed
> > when an overrun occurs? Otherwise, how does the application know
> > which thread overran?
>
> Sorry for jumping late in the discussion...
And more sorry to be even more late to reply. :(
> Anyway, I agree that there is a bug here (thanks for noticing!), and
> the signal was originally designed (in my understanding) to be
> thread-directed.
Not sure. AFAIK, all threads of a group should be able (by default) to
receive and handle the signal. It should however be the running task
that receives and handles it first since check_thread_timers() is called
from the timer interrupt and has the running task task_struct as
parameter and complete_signal() (at the end of __send_signal()) checks
if such task wants to handle the signal:
https://elixir.bootlin.com/linux/v4.17-rc7/source/kernel/signal.c#L909
Does it make any sense?
Thanks,
- Juri
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
