lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ