signals handling in kernel

[Jeff Haran]

From: KASHISH BHATIA [mailto:kashish.bhatia1989 at gmail.com]
Sent: Friday, August 14, 2015 11:06 AM
To: Jeff Haran
Subject: Re: signals handling in kernel

Jeff,
You are right, that's what my understanding was about signals. But after posting the question on the mailing list, I was going through
signal.c and signal.h files and I kind of wrote a kernel module where I am able to send signal from one kthread to another but I am still not able to override the existing default handler of the signal.
Though I came across one of the exported function called "kernel_sigaction()" through which one can register signal handler but I am not sure it will work as expected. The API was introduced in kernel 3.16 version.

On Fri, Aug 14, 2015 at 10:10 PM, Jeff Haran <Jeff.Haran at citrix.com<mailto:Jeff.Haran at citrix.com>> wrote:

From: kernelnewbies-bounces at kernelnewbies.org<mailto:kernelnewbies-bounces at kernelnewbies.org> [mailto:kernelnewbies-bounces at kernelnewbies.org<mailto:kernelnewbies-bounces at kernelnewbies.org>] On Behalf Of KASHISH BHATIA
Sent: Friday, August 14, 2015 6:09 AM
To: Pranay Srivastava
Cc: kernelnewbies
Subject: Re: signals handling in kernel

I want to write a module which will spawn two kthreads where kthread-1 will send signal X to kthread-2 and kthread-2 has registered a signal handler to catch signal X. When the signal X is caught by kthread-2, it will execute its signal handler.
Just am exploring signal handing and its intricacies, so thought of this exercise. Is it possible ?

I think signal handlers of the sort you describe are a feature of user space. If a process (kthread or user space) that is blocked on a call to wait_event_interruptible() is sent a signal, the call to wait_event_interruptible() will return with an –ERESTARTSYS so you can add “signal handler” code there. But I don’t think it’s possible to register a signal handler from kernel space like you can using the signal() or sigaction() systems calls that you can use from user space.

If somebody else thinks different, please do pipe up. This signal stuff in the kernel has always been a bit mysterious to me.

Jeff Haran
 Kashish,

Please don’t top post.

To me that kernel_sigaction() function looks like it might be a work in progress. Browsing calls to it in 4.1 I don’t see any cases where an actual function gets registered. SIG_DFL, SIG_IGN seem to be the only signal “handlers” passed in, the exception being a mysterious literal 2 in signal.h that is accompanied by this comment:

285 static inline void allow_signal(int sig)
286 {
287         /*
288          * Kernel threads handle their own signals. Let the signal code
289          * know it'll be handled, so that they don't get converted to
290          * SIGKILL or just silently dropped.
291          */
292         kernel_sigaction(sig, (__force __sighandler_t)2);
293 }

It doesn’t appear to me that it’s intended to enable kernel threads to register signal handlers in the same sense as user space can, at least not yet. Seems it’s more about giving kthreads the ability to tell the rest of the kernel that “Kernel threads handle their own signals”.

Jeff Haran

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150814/030dfdee/attachment-0001.html