All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Vagin <avagin@parallels.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Andrey Vagin <avagin@openvz.org>, <linux-kernel@vger.kernel.org>,
	<criu@openvz.org>, <linux-fsdevel@vger.kernel.org>,
	<linux-api@vger.kernel.org>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Pavel Emelyanov <xemul@parallels.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>
Subject: Re: [PATCH 0/3] signalfd: a kernel interface for dumping pending signals
Date: Wed, 23 Jan 2013 15:03:23 +0400	[thread overview]
Message-ID: <20130123110323.GA23139@paralelels.com> (raw)
In-Reply-To: <CAKgNAkgfV3qdrvBUYKBAgaYXUTZ5hMYLhwaiLkZO0KBTA_=1zw@mail.gmail.com>

On Wed, Jan 23, 2013 at 05:19:24AM +0100, Michael Kerrisk (man-pages) wrote:
> Hi Andrey,
> 
> On Tue, Jan 22, 2013 at 11:15 AM, Andrey Vagin <avagin@openvz.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

In additional we can say, that this patch series adds three orthogonal,
independent groups of flags.
* SFD_RAW
* SFD_PEEK
* SFD_SHARED_QUEUE, SFD_PER_THREAD_QUEUE

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

siginfo_t *buf;

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

This examples reads signals one by one

or

  siginfo_t *buf = NULL;
  unsigned long buf_size = 0, nr = 0;
  int ret;

  while (1) {
	bug_size += PAGE_SIZ;
	buf = realloc(buf, buf_size);
	if (buf == NULL)
		goto err;
	ret = pread(fd, buf + nr, sizeof(siginfo_t), nr);
	if (ret == -1)
		goto err;
	nr += ret / sizeof(siginfo_t);
	if (ret < PAGE_SIZE) /* No more signals */
		break;
  }

pread() can read more than one signal.

* The interface of signalfd could be a bit more predictable,
  if we will treat pos as offset in bytes, not in elements.

  pread(fd, buf, sizeof(siginfo_t), i * sizeof(siginfo_t)) -
               reads a signal with a sequence number i in a queue.
> 
> 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.

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

Yes, it is possible. read() and pread() returns signalfd_siginfo structs
in this case.

> 
> 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.)?
Yes, it is possible too. read() will return siginfo structs.

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

It is equal to the case, when none of these flags are not specified.
And it is equal to what we had before this patches.
signalfd() reads signals from a private queue, then from a shared queue.

ps: A good analogy:
signalfd looks like a pipe if SFD_PEEK are not specified, otherwise it looks
like a file

> Thanks,
> 
> Michael
> 
> > Cc: Serge Hallyn <serge.hallyn@canonical.com>
> > Cc: Oleg Nesterov <oleg@redhat.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> > Cc: Al Viro <viro@zeniv.linux.org.uk>
> > Cc: Pavel Emelyanov <xemul@parallels.com>
> > CC: Cyrill Gorcunov <gorcunov@openvz.org>
> > Cc: Michael Kerrisk <mtk.manpages@gmail.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/

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Vagin <avagin-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: "Michael Kerrisk (man-pages)"
	<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Andrey Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<criu-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Serge Hallyn
	<serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	"Eric W. Biederman"
	<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
	Cyrill Gorcunov
	<gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH 0/3] signalfd: a kernel interface for dumping pending signals
Date: Wed, 23 Jan 2013 15:03:23 +0400	[thread overview]
Message-ID: <20130123110323.GA23139@paralelels.com> (raw)
In-Reply-To: <CAKgNAkgfV3qdrvBUYKBAgaYXUTZ5hMYLhwaiLkZO0KBTA_=1zw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Wed, Jan 23, 2013 at 05:19:24AM +0100, Michael Kerrisk (man-pages) wrote:
> Hi Andrey,
> 
> On Tue, Jan 22, 2013 at 11:15 AM, Andrey Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.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

In additional we can say, that this patch series adds three orthogonal,
independent groups of flags.
* SFD_RAW
* SFD_PEEK
* SFD_SHARED_QUEUE, SFD_PER_THREAD_QUEUE

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

siginfo_t *buf;

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

This examples reads signals one by one

or

  siginfo_t *buf = NULL;
  unsigned long buf_size = 0, nr = 0;
  int ret;

  while (1) {
	bug_size += PAGE_SIZ;
	buf = realloc(buf, buf_size);
	if (buf == NULL)
		goto err;
	ret = pread(fd, buf + nr, sizeof(siginfo_t), nr);
	if (ret == -1)
		goto err;
	nr += ret / sizeof(siginfo_t);
	if (ret < PAGE_SIZE) /* No more signals */
		break;
  }

pread() can read more than one signal.

* The interface of signalfd could be a bit more predictable,
  if we will treat pos as offset in bytes, not in elements.

  pread(fd, buf, sizeof(siginfo_t), i * sizeof(siginfo_t)) -
               reads a signal with a sequence number i in a queue.
> 
> 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.

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

Yes, it is possible. read() and pread() returns signalfd_siginfo structs
in this case.

> 
> 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.)?
Yes, it is possible too. read() will return siginfo structs.

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

It is equal to the case, when none of these flags are not specified.
And it is equal to what we had before this patches.
signalfd() reads signals from a private queue, then from a shared queue.

ps: A good analogy:
signalfd looks like a pipe if SFD_PEEK are not specified, otherwise it looks
like a file

> Thanks,
> 
> Michael
> 
> > Cc: Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> > Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> > Cc: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> > Cc: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
> > Cc: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> > CC: Cyrill Gorcunov <gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
> > Cc: Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >
> > --
> > 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/

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Vagin <avagin-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: "Michael Kerrisk (man-pages)"
	<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Andrey Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	criu-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Serge Hallyn
	<serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	"Eric W. Biederman"
	<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
	Cyrill Gorcunov
	<gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH 0/3] signalfd: a kernel interface for dumping pending signals
Date: Wed, 23 Jan 2013 15:03:23 +0400	[thread overview]
Message-ID: <20130123110323.GA23139@paralelels.com> (raw)
In-Reply-To: <CAKgNAkgfV3qdrvBUYKBAgaYXUTZ5hMYLhwaiLkZO0KBTA_=1zw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Wed, Jan 23, 2013 at 05:19:24AM +0100, Michael Kerrisk (man-pages) wrote:
> Hi Andrey,
> 
> On Tue, Jan 22, 2013 at 11:15 AM, Andrey Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.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

In additional we can say, that this patch series adds three orthogonal,
independent groups of flags.
* SFD_RAW
* SFD_PEEK
* SFD_SHARED_QUEUE, SFD_PER_THREAD_QUEUE

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

siginfo_t *buf;

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

This examples reads signals one by one

or

  siginfo_t *buf = NULL;
  unsigned long buf_size = 0, nr = 0;
  int ret;

  while (1) {
	bug_size += PAGE_SIZ;
	buf = realloc(buf, buf_size);
	if (buf == NULL)
		goto err;
	ret = pread(fd, buf + nr, sizeof(siginfo_t), nr);
	if (ret == -1)
		goto err;
	nr += ret / sizeof(siginfo_t);
	if (ret < PAGE_SIZE) /* No more signals */
		break;
  }

pread() can read more than one signal.

* The interface of signalfd could be a bit more predictable,
  if we will treat pos as offset in bytes, not in elements.

  pread(fd, buf, sizeof(siginfo_t), i * sizeof(siginfo_t)) -
               reads a signal with a sequence number i in a queue.
> 
> 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.

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

Yes, it is possible. read() and pread() returns signalfd_siginfo structs
in this case.

> 
> 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.)?
Yes, it is possible too. read() will return siginfo structs.

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

It is equal to the case, when none of these flags are not specified.
And it is equal to what we had before this patches.
signalfd() reads signals from a private queue, then from a shared queue.

ps: A good analogy:
signalfd looks like a pipe if SFD_PEEK are not specified, otherwise it looks
like a file

> Thanks,
> 
> Michael
> 
> > Cc: Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> > Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> > Cc: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> > Cc: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
> > Cc: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> > CC: Cyrill Gorcunov <gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
> > Cc: Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >
> > --
> > 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/

  reply	other threads:[~2013-01-23 11:04 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22 10:15 [PATCH 0/3] signalfd: a kernel interface for dumping pending signals Andrey Vagin
2013-01-22 10:15 ` Andrey Vagin
2013-01-22 10:15 ` [PATCH 1/3] signal: add a helper for dequeuing signals from a specified queue Andrey Vagin
2013-01-22 10:15   ` Andrey Vagin
2013-02-05 12:00   ` [PATCH 1/3] signal: add a helper for dequeuing signals from a specified queue (v2) Andrey Vagin
2013-02-05 12:00     ` Andrey Vagin
2013-01-22 10:15 ` [PATCH 2/3] signalfd: add ability to choose a private or shared queue Andrey Vagin
2013-01-22 10:15   ` Andrey Vagin
2013-02-07 18:17   ` Oleg Nesterov
2013-02-08  0:35     ` Michael Kerrisk (man-pages)
2013-02-08  0:35       ` Michael Kerrisk (man-pages)
2013-02-08 19:12       ` Oleg Nesterov
2013-01-22 10:15 ` [PATCH 3/3] signalfd: add ability to read siginfo-s without dequeuing signals Andrey Vagin
2013-01-29 19:03   ` [PATCH 3/3] signalfd: add ability to read siginfo-s without dequeuing signals (v2) Andrey Vagin
     [not found]     ` <CAKgNAkgQA=zK=2ZnytPFU=DH6jr0sja0iy6K+j6c7unheLFniQ@mail.gmail.com>
2013-02-02  7:15       ` Andrey Wagin
2013-02-02  7:15         ` Andrey Wagin
2013-02-07 17:34     ` Oleg Nesterov
2013-02-07 17:34       ` Oleg Nesterov
2013-02-07 21:13       ` Andrey Wagin
2013-02-07 21:13         ` Andrey Wagin
2013-02-08  0:51         ` Michael Kerrisk (man-pages)
2013-02-08 19:10         ` Oleg Nesterov
2013-02-08 20:15           ` Michael Kerrisk (man-pages)
2013-02-08 20:15             ` Michael Kerrisk (man-pages)
2013-02-09 18:22             ` Oleg Nesterov
2013-02-09 22:53               ` Michael Kerrisk (man-pages)
2013-02-09 22:53                 ` Michael Kerrisk (man-pages)
2013-02-10 10:04                 ` [CRIU] " Andrew Vagin
2013-02-10 10:04                   ` Andrew Vagin
2013-02-11 16:47                   ` Oleg Nesterov
2013-02-11 16:47                     ` Oleg Nesterov
2013-02-10 10:07               ` Andrew Vagin
2013-02-10 10:07                 ` Andrew Vagin
2013-02-11  9:29             ` Denys Vlasenko
2013-02-11 10:59               ` [CRIU] " Andrew Vagin
2013-02-11 10:59                 ` Andrew Vagin
2013-02-11 14:46                 ` Denys Vlasenko
2013-02-11 14:46                   ` Denys Vlasenko
2013-02-11 14:53                   ` Pavel Emelyanov
2013-02-11 14:53                     ` Pavel Emelyanov
2013-02-11 17:25                     ` Denys Vlasenko
2013-02-11 17:25                       ` Denys Vlasenko
2013-02-12 14:50                       ` Pavel Emelyanov
2013-02-12 14:50                         ` Pavel Emelyanov
2013-01-23  4:19 ` [PATCH 0/3] signalfd: a kernel interface for dumping pending signals Michael Kerrisk (man-pages)
2013-01-23 11:03   ` Andrew Vagin [this message]
2013-01-23 11:03     ` Andrew Vagin
2013-01-23 11:03     ` Andrew Vagin
2013-01-23 12:11     ` Michael Kerrisk (man-pages)
2013-01-23 12:11       ` Michael Kerrisk (man-pages)
2013-01-23 13:03       ` Andrew Vagin
2013-01-23 13:03         ` Andrew Vagin
2013-01-23 13:03         ` Andrew Vagin
2013-02-07 18:20   ` Oleg Nesterov
2013-02-07 18:20     ` Oleg Nesterov
2013-02-08  0:36     ` Michael Kerrisk (man-pages)
2013-02-08  0:36       ` Michael Kerrisk (man-pages)

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=20130123110323.GA23139@paralelels.com \
    --to=avagin@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@openvz.org \
    --cc=criu@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=gorcunov@openvz.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=oleg@redhat.com \
    --cc=serge.hallyn@canonical.com \
    --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.