On 07/27, Roland McGrath wrote:
>
> > Assuming you agree with this change... I don't know how it should be merged.
> > Probably the change in signal.c should be sent separately, but this breaks
> > -mm tree.
>
> The relevant -mm differences are just in one patch that folds finish_stop
> into do_signal_stop, right?
Ah. I forgot signals-tracehook_notify_jctl-change.patch is still pending in
-mm.
> If I can apply just that one patch to the
> Linus tree (i.e. v2.6.31-rc4+) and then yours without conflicts, that does
> just fine.
Or you can just merge these 2 patches, perhaps this would be better.
> The signal.c change should go upstream ASAP, and that patch should also
> include a change to the tracehook_notify_jctl kerneldoc so that it is
> accurate about the locking et al.
Confused, signals-tracehook_notify_jctl-change.patch already updated the
comment?
> > - notify = tracehook_notify_jctl(stop_count == 0 ? CLD_STOPPED : 0,
> > - CLD_STOPPED);
> > + notify = sig->group_stop_count == 1 ? CLD_STOPPED : 0;
> > + notify = tracehook_notify_jctl(notify, CLD_STOPPED);
> >
> > + if (sig->group_stop_count) {
> > + if (!--sig->group_stop_count)
>
> This warrants a comment here about the first if. The only reason it is
> there is that tracehook_notify_jctl is allowed to drop and reacquire the
> siglock,
and SIGCONT may come in between,
> which makes the sig->group_stop_count = 1 logic et al beforehand
> very important.
Agreed, will resend...
Oleg.
