|
From: KASHISH BHATIA [mailto:kashish.bhatia1989@xxxxxxxxx]
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@xxxxxxxxxx> wrote: From:
kernelnewbies-bounces@xxxxxxxxxxxxxxxxx [mailto:kernelnewbies-bounces@xxxxxxxxxxxxxxxxx]
On Behalf Of KASHISH BHATIA 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 |
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
