linux-kernel - Re: PTRACE_DETACH without stop [Re: [PATCH 04/11] ptrace: implement PTRACE

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:	Sun, 15 May 2011 18:35:23 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	Denys Vlasenko <vda.linux@...glemail.com>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	indan@....nu
Subject: Re: PTRACE_DETACH without stop  [Re: [PATCH 04/11] ptrace:
 implement PTRACE_INTERRUPT]

Hey, again.

On Sun, May 15, 2011 at 06:10:00PM +0200, Jan Kratochvil wrote:
> I do not think this change is much related to this patchset.
> 
> But having to PTRACE_INTERRUPT the tracee before PTRACE_DETACH has no
> advantage, it is just a performance (see transparent tracking of 10000+ thread
> 	https://lkml.org/lkml/2011/5/15/115
> ) problem and also getting it correct.  As when one wait()s and gets
> WIFSTOPPED one needs to respawn to signal otherwise the signal gets lost on
> PTRACE_ATTACH.  How to respawn it?  By PTRACE_INTERRUPT with DATA==signal?
> Or PTRACE_CONT with DATA==signal?  With rapid signalling of the tracee the
> debugger may never have a chance to correctly quit.  Handling other cases
> transparently for the original parent also may not be fully clear.
> 
> It would be nice to write documentation already while discussing this patch,
> I do not know if PTRACE_INTERRUPT respects DATA etc., it may show ptrace is
> still tricky.

Hmmm... you seem to be a bit confused about different ptrace traps
(again, a lot of this probably stems from incorrect manpage).  They
don't interact with each other that way and there is no correctness
issue (if there is, it's a but and should be fixed) of
INTERRUPT+DETACH compared to DETACH without interrupt.  The only
difference is performance, so let's concentrate on that.

The reason why I'm reluctant to drop trapped requirement from both
SEIZE and DETACH is that removing those synchronization points opens
up a lot of corner cases.  I'm they can all be dealt with but it's
gonna be measurably more complex and possibly fragile.  Given that the
current implementation mandates traps on both ATTACH and DETACH, I'd
like to leave that part alone unless there are pretty strong
arguments, and, sure, performance might as well be strong enough.

But, I'd really like to know how much it actually costs to attach and
detach a lot of tasks before deciding anything.

Thank you.

-- 
tejun
--
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/