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

[Pavel Emelyanov]

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.