linux-kernel - Re: [PATCH 0/3] signalfd: a kernel interface for dumping pending signals

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:	Wed, 23 Jan 2013 05:19:24 +0100
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	Andrey Vagin <avagin@...nvz.org>
Cc:	linux-kernel@...r.kernel.org, criu@...nvz.org,
	linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Pavel Emelyanov <xemul@...allels.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>
Subject: Re: [PATCH 0/3] signalfd: a kernel interface for dumping pending signals

Hi Andrey,

On Tue, Jan 22, 2013 at 11:15 AM, Andrey Vagin <avagin@...nvz.org> wrote:
> This patch set adds ability to choose a signal queue and
> to read signals without dequeuing them.
>
> Three new flags are added:
> SFD_SHARED_QUEUE     -- reads will be from process-wide shared signal queue
> SFD_PER_THREAD_QUEUE -- reads will be from per-thread signal queue
> SFD_PEEK             -- don't dequeue signals

A fuller description of the patch, including information that was in
previous versions of this patch would be helpful. Let me see if I can
summarize/fill out the API side of things, and ask a few questions
along the way (yes, I could answer some of the questions by checking
the code, but I want to know what the *intended* behavior is).

The patch series adds a total of 4 flags to signalfd(). In addition to
those you list above, the other is

SFD_RAW -- return raw siginfo structs when reading, rather than signalfd_siginfo

The intention is that these flags be used in conjunction with pread(),
to peek at queued signals. The 'offset' argument is treated as a
position. Thus, for example, to non-destructively read all of the
per-thread signals in raw form from the per-thread queue, one would
write

fd = signalfd(-1, SFD_PER_THREAD_QUEUE | SFD_RAW | SFD_PEEK)
for (j = 0; ; j++) {
    s = pread(fd, buf, ocunt, j)
    if (s == 0) /* No more signals */
        break;
}

Right?

Now some questions. I don't require all of the following, but I'm
wanting to know what's possible, for documentation purposes.

Q1: with this patch series, is it permissible to specify
SFD_PER_THREAD_QUEUE or SFD_SHARED_QUEUE without specifying either
SFD_PEEK or SFD_QUEUE? In other words, can one do traditional
signalfd_siginfo reads, but selecting from a specific queue.

Q2: Is it possible to specify SFD_PEEK without SFD_RAW, so that one
can peek at siginfo structs rather than signalfd_siginfo structs?

Q3: Is it possible to specify SFD_RAW without SFD_PEEK, so that one
can destructively read signalfd_siginfo structs? Can that be done
using any read interface (read(), pread(), etc.)?

Q4: Is it possible to specify both SFD_PER_THREAD_QUEUE and
SFD_SHARED_QUEUE? In that case, in what order are signals read from
the two queues?

Thanks,

Michael

> Cc: Serge Hallyn <serge.hallyn@...onical.com>
> Cc: Oleg Nesterov <oleg@...hat.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: "Eric W. Biederman" <ebiederm@...ssion.com>
> Cc: Al Viro <viro@...iv.linux.org.uk>
> Cc: Pavel Emelyanov <xemul@...allels.com>
> CC: Cyrill Gorcunov <gorcunov@...nvz.org>
> Cc: Michael Kerrisk <mtk.manpages@...il.com>
>
> --
> 1.7.11.7
>

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