lkml.org 
[lkml]   [2008]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race
Date
> In the code path mentioned above, I see only ia64 has chance to let
> ptraced thread deliver those pending signals before TASK_TRACED is

This is the key thing that makes no sense to me. What do you mean by
"deliver" here? The normal meaning of to "deliver" a signal means that
get_signal_to_deliver() dequeues and processes it. This can never happen
inside any other kernel code path. It certainly can never happen inside
ptrace_stop or ptrace_notify.

The difference between ia64 and others is that inside ptrace_stop(), it can
release the siglock and then can block (in page faults, or by preemption).
No signal delivery can happen.

What perhaps can happen is that TIF_SIGPENDING being set can cause a
TASK_INTERRUPTIBLE wait in the page fault path to return early and
ia64_sync_user_rbs will bail out before doing all its work. But you
haven't described any problem like that.

Please tell us the exact code path you think is happening in the error case
you can reproduce. Describe the actual code path, not high-level notions
like "deliver those pending signals".


Thanks,
Roland


\
 
 \ /
  Last update: 2008-05-23 06:25    [W:0.059 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site