linux-kernel - Re: [CRIU] [PATCH 2/3] signalfd: add ability to return siginfo in a raw format (v2)

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: <CANaxB-zR1daDmu3wxKMfw70Fv63=bSqUfjvibRG98RECKJQndw@mail.gmail.com>
Date:	Mon, 21 Jan 2013 21:57:24 +0400
From:	Andrey Wagin <avagin@...il.com>
To:	Andrew Vagin <avagin@...allels.com>
Cc:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
	Oleg Nesterov <oleg@...hat.com>,
	David Howells <dhowells@...hat.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
	criu@...nvz.org, Cyrill Gorcunov <gorcunov@...nvz.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [CRIU] [PATCH 2/3] signalfd: add ability to return siginfo in a
 raw format (v2)

2013/1/21 Andrew Vagin <avagin@...allels.com>:
> On Sun, Jan 20, 2013 at 09:33:41PM +0100, Michael Kerrisk (man-pages) wrote:
>> Hi Oleg,
>>
>> On Sun, Jan 20, 2013 at 8:55 PM, Oleg Nesterov <oleg@...hat.com> wrote:
>> > On 01/20, Andrew Vagin wrote:
>> >>
>> >> > SFD_RAW
>> >> > SFD_SHARED_QUEUE -- reads will be from process-wide shared signal queue
>> >> > SFD_PER_THREAD_QUEUE --reads will be from per-thread signal queue
>> >>
>> >> I suggested this variant in the initial series, but then we decided to
>> >> avoid adding new flags.
>> >
>> > Yes, because SFD_SHARED/PRIVATE will add even more complications into this
>> > code. And outside of signalfd.c too. And nobody except c/r will ever use
>> > these features I guess.
>>
>> So, I must admit that I don't understand why adding SFD_SHARED and
>> SFD_PER_THREAD in signalfd() makes things more complicated than adding
>> the equivalents in pread(). But, I'll take your word for that, if
>> that's what you meant.
>
> You could look at the initial series.
> http://thread.gmane.org/gmane.linux.file-systems/70327
>
> In this case dequeue_signal should be changed for specifying a queue.
> signalfd_poll() should be fixed too. All this changes are not a big
> deal, but...
>
> If we want to have two flags for specifying queues, we will need one
> more flag SFD_PEEK, which will say, that signals should not be dequeued.
> Currently we get this information from offset too. If offset isn't zero,
> signals are not dequeued. With flags this sentence will look ugly.

I'm going to prepare a series with flags tomorrow.

Thanks.

>
>>
>> However, note that I did suggest that in the initial implementation
>> you might require that if SFD_SHARED_QUEUE or SFD_PER_THREAD_QUEUE is
>> specified in signalfd(), then SFD_RAW could be required as well.
>> Later, if someone wants to do the work, they could relax the
>> constraint, so as to allow signalfd() to be used to do per-queue
>> select even when reading siginfo (i.e., SFD_SHARED_QUEUE or
>> SFD_PER_THREAD_QUEUE specified but not SFD_RAW). Surely that is not
>> more complicated than the current implementation. And it allows for an
>> orthogonal expansion of the design that seems more natural and may one
>> day be useful.
>>
>> 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/