Hi Michael,
how do we move forward from this situation ?
The kernel source [1] and the related documentation [2] have been
already updated to include both the SCHED_FLAG_RECLAIM and
SCHED_FLAG_DL_OVERRUN flags.
Now, it's time to update the sched_setattr() manpage as well (even if
the SIGXCPU signal is per-process and not per-thread).
Many thanks and best regards,
Claudio
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/sched/deadline.c
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/scheduler/sched-deadline.txt
2018-05-28 18:01 GMT+02:00 Juri Lelli <juri.lelli@xxxxxxxxxx>:
> 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
--
Claudio Scordino, Ph.D.
Project Manager - International R&D projects
Evidence Srl
Via Carducci 56
56010 S.Giuliano Terme - Pisa - Italy
Phone: +39 050 99 11 122
Mobile: + 39 393 811 7491
Fax: +39 050 99 10 812
http://www.evidence.eu.com
--
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
