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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130121154444.GA10849@paralelels.com>
Date:	Mon, 21 Jan 2013 19:44:44 +0400
From:	Andrew Vagin <avagin@...allels.com>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
CC:	Oleg Nesterov <oleg@...hat.com>, Andrey Wagin <avagin@...il.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)

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.

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