[CRIU] [PATCH 0/4] signalfd: a kernel interface for dumping/restoring pending signals

[Andrew Vagin]

On Tue, Dec 04, 2012 at 03:18:32PM +0400, Pavel Emelyanov wrote:
> On 12/04/2012 02:05 PM, Andrey Vagin wrote:
> > The idea is simpe. We need to get the siginfo for each signal on dump,
> > and then return it back on restore.
> > 
> > The first problem is that the kernel doesn’t report complete siginfo-s
> > in user-space. In a signal handler the kernel strips SI_CODE from
> > siginfo. When a siginfo is received from signalfd, it has a different
> > format with fixed sizes of fields. The interface of signalfd was
> > extended. If a signalfd is created with the flag SFD_RAW, it returns
> > siginfo in a raw format. We need to choose a queue, so two flags
> > SFD_GROUP and SFD_PRIVATE were added.
> > 
> > rt_igqueueinfo looks suitable for restoring signals, but it can’t send
> > siginfo with a positive si_code, because these codes are reserved for
> > the kernel. In the real world each person has right to do anything with
> > himself, so I think a process should able to send any siginfo to itself.
> > 
> > Andrey Vagin (3):
> >   signal: add helper to get siginfo without removing from the queue
> >   signalfd: add ability to get signal without removing from the queue
> >   signalfd: add ability to send any siginfo to itself
> > 
> >  fs/signalfd.c                 | 84 +++++++++++++++++++++++++++++++++++++++----
> >  include/linux/sched.h         |  2 ++
> >  include/uapi/linux/signalfd.h |  2 ++
> >  kernel/signal.c               | 27 ++++++++++++++
> >  4 files changed, 109 insertions(+), 6 deletions(-)
> > 
> 
> Andrey, this looks very good. Fix the shared/personal queue handling,
> resolve my comments and I'll apply these patches. Then start pushing
> the kernel part upstream.

I'm going to start after my vacation.

Thanks.