Messages in this thread | | | Subject | Re: [PATCH, for 2.6.29] ptrace: fix the usage of ptrace_fork() | From | Markus Metzger <> | Date | Tue, 10 Feb 2009 21:21:59 +0100 |
| |
On Tue, 2009-02-10 at 19:40 +0100, Oleg Nesterov wrote:
> > 2. there is a race between a thread detaching > > and another thread releasing the same task.
I think I now see the problem. Ptrace uses the tasklist_lock to protect against __ptrace_unlink() races.
I could either introduce a separate lock to protect bts buffer deallocation, or I put the kfree part under the tasklist_lock, as you suggest below.
> Perhaps, for 2.6.29, we can do something like the "patch" below? > > (btw, do you agree with the change in copy_process() I sent? )
Both patches look good to me.
> --- a/arch/x86/kernel/ptrace.c > +++ b/arch/x86/kernel/ptrace.c > @@ -810,11 +810,15 @@ static void ptrace_bts_untrace(struct ta > > static void ptrace_bts_detach(struct task_struct *child) > { > + // We can race with de_thread/do_wait which > + // can do ptrace_bts_untrace() before us > if (unlikely(child->bts)) { > - ds_release_bts(child->bts); > - child->bts = NULL; > - > - ptrace_bts_free_buffer(child); > + // This all will be freed by ptrace_bts_untrace() > + // later, but we should update ->mm > + down_write(->mmap_sem); > + mm->total_vm -= bts_size; > + mm->locked_vm -= bts_size); > + up_write(->mmap_sem); > } > } > #else >
You already sent out the first one. I don't have access to any test machine from home. I could send the patch tomorrow (evening).
thanks and regards, markus.
| |