question regarding down_interruptible

question regarding down_interruptible

[Vijay Ram Chitrapu]

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.

Regards,
Vijay

question regarding down_interruptible

[Dave Hylands]

Hi Vijay,

On Sun, Apr 3, 2011 at 9:27 PM, Vijay Ram Chitrapu
<chitrapu.vijayram@gmail.com> 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
http://www.davehylands.com

question regarding down_interruptible

[Vijay Ram Chitrapu]

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?

Regards,
Vijay

On Mon, Apr 4, 2011 at 9:18 PM, Dave Hylands <dhylands@gmail.com> wrote:
> Hi Vijay,
>
> On Sun, Apr 3, 2011 at 9:27 PM, Vijay Ram Chitrapu
> <chitrapu.vijayram@gmail.com> 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
> http://www.davehylands.com
>

question regarding down_interruptible

[Mulyadi Santosa]

On Tue, Apr 5, 2011 at 10:37, Vijay Ram Chitrapu
<chitrapu.vijayram@gmail.com> wrote:
> 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?

it's select() right? no async I/O? well,then AFAIK it;s not
signal...the blocking process is scheduled back to run queue and
scheduler kicks in...

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com