On Mon, Nov 10, 2025 at 04:09:05PM +0100, Oleg Nesterov wrote:
...
> > >   if (!((sig->flags & SIGNAL_GROUP_EXIT) || sig->group_exec_task)) {
> > >           sig->group_exec_task = tsk;
> > >           sig->notify_count = -zap_other_threads(tsk);
> >
> > Hi Oleg! I somehow manage to miss a moment -- why negative result here?
> 
> You know, initially I wrote
> 
>               sig->notify_count = 0 - zap_other_threads(tsk);
> 
> to make it clear that this is not a typo ;)

Aha! Thanks a huge for explanation :)

> 
> This is for exit_notify() which does
> 
>       /* mt-exec, de_thread() -> wait_for_notify_count() */
>       if (tsk->signal->notify_count < 0 && !++tsk->signal->notify_count)
>               wake_up_process(tsk->signal->group_exec_task);
> 
> Then setup_new_exec() sets notify_count > 0 for __exit_signal() which does
> 
>       /* mt-exec, setup_new_exec() -> wait_for_notify_count() */
>       if (sig->notify_count > 0 && !--sig->notify_count)
>               wake_up_process(sig->group_exec_task);
> 
> Yes this needs more comments and (with or without this patch) cleanups.
> Note that exit_notify() and __exit_signal() already (before this patch)
> use ->notify_count almost the same way, just exit_notify() assumes that
> notify_count < 0 means the !thread_group_leader() case in de_thread().

Yeah, just realized. It's been a long time since I looked into this signals
and tasks related code so to be honest don't think I would be helpful here)
Anyway while looking into patch I got wonder why

+static int wait_for_notify_count(struct task_struct *tsk)
+{
+       for (;;) {
+                       return -EINTR;
+               set_current_state(TASK_KILLABLE);
+               if (!tsk->signal->notify_count)
+                       break;

We have no any barrier here in fetching @notify_count? I mean updating
this value is done under locks (spin or read/write) in turn condition
test is a raw one. Not a big deal since set_current_state() and schedule()
are buffer flushers by themselves and after all not immediate update of
notify_count simply force us to yield one more schedule() call but I've
been a bit confused that we don't use some read_once here or something.
Another (more likely) that I've just said something stupid)

+               schedule();
        }
+       __set_current_state(TASK_RUNNING);
+       return 0;
+}

        Cyrill

Reply via email to