linux-kernel - Re: PTRACE_SEIZE should not stop [Re: [PATCH 02/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]

Message-ID: <20110516130339.GA12539@host1.jankratochvil.net>
Date:	Mon, 16 May 2011 15:03:39 +0200
From:	Jan Kratochvil <jan.kratochvil@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	oleg@...hat.com, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu
Subject: Re: PTRACE_SEIZE should not stop  [Re: [PATCH 02/11] ptrace:
 implement PTRACE_SEIZE]

Hi Tejun,

On Mon, 16 May 2011 14:42:59 +0200, Tejun Heo wrote:
> I still don't understand why you need to know the order beforehand.
> Wouldn't pending list be enough?  What are you trying to achieve?

If you check the GDB debugging session transcript I gave GDB stopped in
a moment when all the threads already returned from tkill()s sending SIGUSR1s
and SIGUSR2.

All threads are stopped, user is investigating the situation.  And GDB tells
the user (only) SIGUSR1 was delivered.  The user has no chance to find out
SIGUSR2 is already pending / to be delivered.  This is one of the many reasons
why debugging various racy cases is a nightmare.

I was trying to suggest some ways how to give user the complete overview of
the debuggee situation - where both SIGUSR1 and SIGUSR2 would be reported on
the first stop.

You are right GDB could examine SigCgt, SigBlk (not sure if others) and report
those signals.  Maybe it is right that way and we can forget about it.

There is (was) a larger problem of signals reordering which I fixed in
	[patch 3/4]#3 linux-nat: Do not respawn signals
	http://sourceware.org/ml/gdb-patches/2010-09/msg00360.html
but that mess you should have fixed by PTRACE_INTERRUPT which no longer
interacts with signals.  But it gave me the idea of another situation above
where the debugger may want to know all the currently pending signals at once.

Thanks,
Jan
--
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/