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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 8 Feb 2012 01:51:21 +0400
From:	Cyrill Gorcunov <gorcunov@...nvz.org>
To:	Pedro Alves <palves@...hat.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Jan Kratochvil <jan.kratochvil@...hat.com>,
	Tejun Heo <tj@...nel.org>, Andrew Vagin <avagin@...nvz.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ptrace: add ability to get clear_tid_address

On Tue, Feb 07, 2012 at 09:15:07PM +0000, Pedro Alves wrote:
> On 02/07/2012 08:56 PM, Cyrill Gorcunov wrote:
> > On Tue, Feb 07, 2012 at 08:07:38PM +0000, Pedro Alves wrote:
> >> On 02/03/2012 04:51 PM, Oleg Nesterov wrote:
> >>> On 02/03, Pavel Emelyanov wrote:
> >>
> >>>> Because there's no need for current to get this value of himself, but can
> >>>> be useful for e.g. gdb.
> >>>
> >>> OK, perhaps this makes sense, I do not know.
> >>>
> >>> Jan, Pedro, do you think gdb can use PTRACE_GET_TID_ADDRESS (returns
> >>> tracee->clear_child_tid) ?
> >>
> >> Off hand, I'm not picturing a use.  But that may well just mean I'm lacking
> >> imagination.  Andrew, Pavel, did you have a particular idea in mind when you
> >> said it may be useful for debugging a multithreading program / gdb?
> >>
> > 
> > Might not we set up hw watchpoint on this address and get interrupt
> > before pthread-join will find it? (To be fair I'm not sure if such
> > trick will work, didn't test ;)
> 
> For a debugger wanting to know when a pthread_join was about to return?
> Might be simpler to put a breakpoint (or stap probe, or some such) inside
> pthread_join.

Yes, could be, but it means you have to install pthread debug libs, right?
(have no idea actually since I personally use debug printing instead of
 breakpoints).

> It's the kernel that writes to this address, so I've no
> idea if the watchpoint trap ends up visible on userspace. Which thread
> would it be reported to, given that this is cleared when the child
> is gone, I have no idea either.

Yeah, need some help from someone who wrote hw-breakpoints support in
kernel (i don't remember the details).

	Cyrill
--
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