[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20090624205112.3EA944059B@magilla.sf.frob.com>
Date: Wed, 24 Jun 2009 13:51:12 -0700 (PDT)
From: Roland McGrath <roland@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Ratan Nalumasu <rnalumasu@...il.com>,
Vitaly Mayatskikh <vmayatsk@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC,PATCH 2/2] change __wake_up_parent() to use filtered
wakeup
> > an untraced thread calls do_notify_parent_cldstop() but its group_leader
> > is ptrace_reparented(). Then waitee->group_leader->real_parent is who
> > gets the wakeup, but __wake_up_parent->child_wait_wakeup would check
> > only waiter == waitee->group_leader->parent.
>
> ... and in this case we do not wake up ->group_leader->real_parent.
>
> But this is fine? It doesn't make sense to wake up, wait_consider_task()
> will notice task_ptrace() and do nothing?
Right. I knew it needed more thought (that's why I said "maybe wrong" to
begin with ;-).
> I really need to think with a fresh head, but it seems to me we could add
> BUG_ON(p->parent != parent) into wait_consider_task() after "if (ptrace...)"
> check.
>
> And this "proves" your check in child_wait_callback() is correct, with
> __WNOTHREAD do_wait_thread(parent) is always called with parent ==
> sleeper, the caller of do_wait().
>
> No?
Yes, I think that's right.
> Btw, this reminds me that wait_consider_task() doesn't need the "parent"
> argument. I noticed this after adding wait_opts, but forgot to send a
> patch.
With the wq.private now in wait_opts, yes.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists