From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Vagin <avagin@parallels.com>
Cc: Pavel Emelyanov <xemul@parallels.com>,
David Howells <dhowells@redhat.com>,
linux-kernel@vger.kernel.org, criu@openvz.org,
Cyrill Gorcunov <gorcunov@openvz.org>,
Andrey Wagin <avagin@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [CRIU] [PATCH 1/4] signalfd: add ability to return siginfo in a raw format
Date: Wed, 26 Dec 2012 17:31:12 +0100 [thread overview]
Message-ID: <20121226163112.GA6593@redhat.com> (raw)
In-Reply-To: <20121226144751.GA18767@paralelels.com>
On 12/26, Andrew Vagin wrote:
>
> On Tue, Dec 25, 2012 at 05:58:03PM +0100, Oleg Nesterov wrote:
> > On 12/25, Pavel Emelyanov wrote:
> > >
> > > On 12/25/2012 07:27 PM, Oleg Nesterov wrote:
> > > >
> > > > I guess that probably you actually need DUMP, not DEQUEUE. but the
> > > > latter is not trivial. However, perhaps we can do this assuming that
> > > > all other threads are sleeping and nobody can do dequeue_signal().
> > > > Say, we can play with ppos/llseek. If *ppos is not zero,
> > > > signalfd_dequeue() could dump the nth entry from list or return 0.
> > >
> > > This would be perfect, but isn't it better to preserve the pos
> > > semantics -- we do know size of entry we're about to copy, we can
> > > treat pos as offset in bytes, not in elements.
> >
> > nr-of-records looks better (more flexible) than nr-of-bytes to me. And
> > perhaps we can also encode private-or-shared into ppos. But I will not
> > argue in any case.
>
> Oleg and Pavel, could you look at these two patches. I implemented in them,
> what you described here.
cosmetics nits below, feel free to ignore...
Damn. But after I wrote this email I realized that llseek() probably can't
work. Because peek_offset/f_pos/whatever has to be shared with all processes
which have this file opened.
Suppose that the task forks after sys_signalfd(). Now if parent or child
do llseek this affects them both. This is insane because signalfd is
"strange" to say at least, fork/dup/etc inherits signalfd_ctx but not the
"source" of the data.
So I think we should not use llseek. But, probably we can rely on pread() ?
This way we can avoid the problem above, and this looks even simpler.
> +int peek_signal(struct task_struct *tsk, sigset_t *mask,
> + siginfo_t *info, int offset, bool group)
> +{
> + struct sigpending *pending;
> + struct sigqueue *q;
> + int i = 0, ret = 0;
> +
> + if (group)
> + pending = &tsk->signal->shared_pending;
> + else
> + pending = &tsk->pending;
> +
> + list_for_each_entry(q, &pending->list, list) {
> + if (sigismember(mask, q->info.si_signo))
> + continue;
> +
> + if (i == offset) {
> + copy_siginfo(info, &q->info);
> + ret = info->si_signo;
> + break;
> + }
> +
> + i++;
> + }
> +
> + return ret;
> +}
This helper is trivial. Any reason it should live in signal.c ? Just put
this code into signalfd_peek(). Besides, this helps if !CONFIG_SIGNALFD.
> If lseek sets a positive position, signals are taken from a shared queue.
> If lseek sets a negative position, signals are taken from a private queue.
Personally, I'd prefer, say,
#define SIGNALFD_SHARED_OFFSET big-enough-number
if offset >= SIGNALFD_SHARED_OFFSET we use ->shared_pending.
Again, I won't insist. And if we add SIGNALFD_SHARED_OFFSET
then we should probably define SIGNALFD_PRIVATE_OFFSET as
well for consistency.
> struct signalfd_ctx {
> sigset_t sigmask;
> + loff_t peek_offset;
Why we can't simply use ->f_pos ?
> @@ -242,6 +259,13 @@ static ssize_t signalfd_read(struct file *file, char __user *buf, size_t count,
> if (ret < 0)
> break;
>
> + if (ctx->peek_offset) {
> + if (ctx->peek_offset > 0)
> + ctx->peek_offset++;
> + else
> + ctx->peek_offset--;
...
> +loff_t signalfd_llseek(struct file *f, loff_t offset, int whence)
> +{
> + struct signalfd_ctx *ctx = f->private_data;
> +
> + switch (whence) {
> + case SEEK_SET:
> + ctx->peek_offset = offset;
> + break;
> + case SEEK_CUR:
> + ctx->peek_offset += offset;
probably you need some locking (say, f_lock) to ensure that these
peek_offset modifications can't race with each other. If you rely
on f_pos you only need to ensure thar signalfd_llseek() can't race
with itself.
Oleg.
next prev parent reply other threads:[~2012-12-26 16:31 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-24 8:13 [PATCH 0/4] signalfd: a kernel interface for dumping/restoring pending signals Andrey Vagin
2012-12-24 8:13 ` Andrey Vagin
2012-12-24 8:13 ` [PATCH 1/4] signalfd: add ability to return siginfo in a raw format Andrey Vagin
2012-12-24 16:53 ` Oleg Nesterov
2012-12-25 8:29 ` Andrey Wagin
2012-12-25 14:30 ` Oleg Nesterov
2012-12-25 15:27 ` Oleg Nesterov
2012-12-25 15:40 ` Pavel Emelyanov
2012-12-25 16:58 ` Oleg Nesterov
2012-12-26 14:47 ` [CRIU] " Andrew Vagin
2012-12-26 16:31 ` Oleg Nesterov [this message]
2012-12-27 14:36 ` Andrey Wagin
2012-12-27 15:30 ` Oleg Nesterov
2012-12-27 18:40 ` Andrey Wagin
2012-12-28 14:12 ` Oleg Nesterov
2012-12-28 14:28 ` Andrey Wagin
2012-12-28 14:46 ` Oleg Nesterov
2012-12-28 14:48 ` Andrey Wagin
2012-12-28 14:56 ` Oleg Nesterov
2012-12-24 8:13 ` [PATCH 2/4] signal: add a helper for dequeuing signals from a specified queue Andrey Vagin
[not found] ` <1356336807-5517-3-git-send-email-avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2012-12-24 20:52 ` Michael Kerrisk
2012-12-24 20:52 ` Michael Kerrisk
2012-12-24 8:13 ` [PATCH 3/4] signalfd: add ability to choose a private or shared queue Andrey Vagin
2012-12-24 17:05 ` Oleg Nesterov
2012-12-24 20:53 ` Michael Kerrisk
2012-12-24 8:13 ` [PATCH 4/4] signal: allow to send any siginfo to itself Andrey Vagin
[not found] ` <1356336807-5517-1-git-send-email-avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2012-12-24 20:51 ` [PATCH 0/4] signalfd: a kernel interface for dumping/restoring pending signals Michael Kerrisk
2012-12-24 20:51 ` Michael Kerrisk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121226163112.GA6593@redhat.com \
--to=oleg@redhat.com \
--cc=avagin@gmail.com \
--cc=avagin@parallels.com \
--cc=criu@openvz.org \
--cc=dhowells@redhat.com \
--cc=gorcunov@openvz.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=xemul@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.