question regarding down_interruptible

Vijay Ram Chitrapu chitrapu.vijayram at
Mon Apr 4 23:37:30 EDT 2011

Thanks Dave for that reply.
While i try out registering handlers for all possible signals, I
forgot to mention this point in my previous email.

The userspace is waiting on a select call. As per the system design,
the kernel module interrupts when there is a data intended to the user
(via poll in kernel). If this could be the cause for the userspace
getting a signal, then typically what signal is generated to the
process to invoke select to inform that the I/O is ready. Is it SIGIO?


On Mon, Apr 4, 2011 at 9:18 PM, Dave Hylands <dhylands at> wrote:
> Hi Vijay,
> On Sun, Apr 3, 2011 at 9:27 PM, Vijay Ram Chitrapu
> <chitrapu.vijayram at> wrote:
>> Hi Experts,
>> I have a system in which there is a only 1 user process and a
>> corresponding kernel module (driver) associated with it to send and
>> receive data to the user process. In the kernel module, i have a
>> semaphore to protect a critical section of code during the rx and tx
>> paths. However, at some instance of code execution, the
>> down_interruptible returns EINTR, which means that the user process
>> has received some interrupt due to which the process has come out of
>> sleep due to the signal it received, due to which the kernel module
>> has not got the semaphore. At this point of time, i have no idea as to
>> which signal has triggered the user process to come out of the sleep.
>> Is there a way in which we can know which signal has a process
>> received, without registering any user defined handler to it?
>> Any thoughts/ideas on debugging this problem can be of great help.
>> Also please correct me if i am wrong in any of my understanding
>> regarding down_interruptible.
> The simplest way is to just register a signal handler for all possible
> signals (in the user program) and print out which one actually
> happened.
> --
> Dave Hylands
> Shuswap, BC, Canada

More information about the Kernelnewbies mailing list