linux-kernel - Re: [PATCH] ptrace: add ability to retrieve signals without removing them from a queue

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: <5123BC20.9040405@parallels.com>
Date:	Tue, 19 Feb 2013 21:53:36 +0400
From:	Pavel Emelyanov <xemul@...allels.com>
To:	mtk.manpages@...il.com, Oleg Nesterov <oleg@...hat.com>
CC:	Andrey Vagin <avagin@...nvz.org>, linux-kernel@...r.kernel.org,
	criu@...nvz.org, linux-api@...r.kernel.org,
	Roland McGrath <roland@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	David Howells <dhowells@...hat.com>,
	Dave Jones <davej@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] ptrace: add ability to retrieve signals without removing
 them from a queue

On 02/19/2013 04:15 PM, Michael Kerrisk (man-pages) wrote:
> On Wed, Feb 13, 2013 at 4:16 PM, Andrey Vagin <avagin@...nvz.org> wrote:
>> This patch adds a new ptrace request PTRACE_PEEKSIGINFO.
>>
>> This request is used to retrieve information about a signal with the
>> specified sequence number. A siginfo_t structure is copied from the child
>> to location data in the parent.
>>
>> The low 16 bits of addr contains a sequence number of signal in a queue:
> 
> I think 16 bits is probably not enough.... Already, on the "out of the
> box" system that I have at hand, one can queue more than 2^16-1
> signals:
> 
>     $ cat /proc/$$/status | grep SigQ
>     SigQ:	2/126065

Yup :( Well, actually it would be enough to have only 1 bit as "flags"
and the rest (31 at least) for the number. But taking into account
Oleg's wish to have an ability to extend the amount of flags in the
future, we should make addr point to something like

struct siginfo_peek_options {
	unsigned int flags;
	unsigned int pos;
};

and force flags to contain zero in all the bits but one, and this
latter bit is to select between private or shared queue. In this case
the patch loses its main advantage -- the simplicity.

Oleg, please, suggest which way would be more preferable?

> Cheers,
> 
> Michael
--
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/