Messages in this thread | | | Date | Sat, 28 Jun 2008 16:38:25 +0400 | From | Oleg Nesterov <> | Subject | Re: [PATCH 1/3] sched: fix TASK_WAKEKILL vs SIGKILL race |
| |
On 06/09, Roland McGrath wrote: > ^^^^^ Oops, something is wrong! I received this message today, 06/28.
> > Note this "__TASK_STOPPED | __TASK_TRACED" check in signal_pending_state(). > > This is needed to preserve the current behaviour (ptrace_notify). I hope > > this check will be removed soon, but this (afaics good) change needs the > > separate discussion. > > Agreed. I think it might actually already be safe to drop it, but we can > get to that after this settles.
Great! I'll re-send the patch which drops it in a minute.
Could you also look at other patches?
[PATCH 2/3] ptrace: never sleep in TASK_TRACED if SIGKILL'ed http://marc.info/?l=linux-kernel&m=121362601402886
[PATCH 3/3] ptrace: kill may_ptrace_stop() http://marc.info/?l=linux-kernel&m=121362601702897
I think ptrace_stop() really needs changes. But I don't know what is the supposed behaviour of PT_TRACE_EXIT. Should we sleep even if the task was killed? Should we sleep if the thread was killed because another one does exit_group() or exec() ?
We can use "SIGNAL_GROUP_EXIT && (group_exit_code & 0x7f)" instead of signal_group_exit() to be sure that task was killed by the fatal signal.
Oleg.
| |