> It turns out I misread SIGNAL_GROUP_EXIT check in ptrace_stop(),
> didn't notice '(->parent->signal != current->signal) ||' before
> it.
I thought that might have been it.
> Do you see any solution which doesn't need tasklist_lock to be
> held while traversing global process list?
Eh, kind of, but I'm not sure I want to get into it. This only comes up in
a pathological case and we don't actually take the lock unless the weird
case really happened. My inclination is to get the rest of the cleanups
and optimizations ironed out and merged in first. Then we can revisit this
oddball case later on.
> > > 3. Can't go to do_signal_stop() after return
> > > from ptrace_stop() in get_signal_to_deliver()
> >
> > This is only true because of the check in get_signal_to_deliver,
> > which I've said I think should be taken out for other reasons.
>
> Yes, changelog refers to SIGNAL_GROUP_EXIT check in get_signal_to_deliver.
> However, do_signal_stop() returns 0 when it doesn't see SIGNAL_STOP_DEQUEUED,
> (which was cleared by SIGNAL_GROUP_EXIT), so I think we don't depend on
> SIGNAL_GROUP_EXIT check in get_signal_to_deliver. No?
Ah yes, you are right. So there is no conflict with removing the check as
I want to do.
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
