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]

Date:	Sun, 20 Jan 2013 19:43:01 +0100
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	Andrew Vagin <avagin@...allels.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)

Hi Andrey,

On Sun, Jan 20, 2013 at 6:41 PM, Andrew Vagin <avagin@...allels.com> wrote:
>
>> > signalfd is a special descriptor, so I think it
>> > is not a big deal, that it works a bit strange.
>>
>> Sure, but the more we special case things, the uglier the ABI as a
>> whole becomes. So special casing should be avoided as far as we can.
>>
>> > If all other would
>> > decides, that a new syscall is better, I will not ague.
>>
>> And that's more or less how I see it too. I'm not going to argue for a
>> new syscall, based on what I know so far.
>>
>> Here is one idea to think about though, while more or less maintaining
>> your proposed interface.
>>
>> At the moment, you select signal queues in the pread() call. An
>> alternative would be to do it in the signalfd() call. In other words,
>> you could have the following flags used with signalfd()
>>
>> 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. Oleg, what do you think about this?
>
>>
>> Specifying both SFD_SHARED_QUEUE  and SFD_PER_THREAD_QUEUE would be
>> the same as omitting them both, providing the default behavior of
>> slecting from both queues.
>>
>> My point here is that you can then separate the RAW functionality from
>> the queue selector functionality. Now, it might be that at the moment
>> you always require that if the caller specifies SFD_SHARED_QUEUE  or
>> SFD_PER_THREAD_QUEUE, then they must also specify SFD_RAW. But later,
>> that constraint might be relaxed, so that users could use signalfd()
>> to select from a particular queue when reading traditional (non-RAW)
>> signalfd_siginfo structures from a signalfd.
>
> I am not sure, that you understood this moment correctly.
> Currently SFD_RAW is independent on SFD_*_QUEUE. If signalfd is
> created without SFD_RAW, pread returns signalfd_siginfo-s.
> If SFD_RAW is set, read returns siginfo_t-s.

So, do you mean it is already possible to do:

fd = signalfd(-1, &mask, 0)      // no SFD_RAW flag
pread(fd, buf, count, SFD_PER_THREAD_QUEUE_OFFSET + pos)

to read a siginfo from the thread specific signal queue?

Thanks

> One more point for two flags is that we will be able to choose a queue
> from which signals will be dequeued. Currently we can choose a queue only
> for pread.

Also a good point, and another reason to place queue selection in the
signalfd() call, rather than in pread().

Cheers,

Michael


>> This does seem like a
>> very sensible design optimization to make now (and an easy one, I
>> would suppose). What do you think?
>>
>> Cheers,
>>
>> Michael
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
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/