From: chitrapu.vijayram@gmail.com (Vijay Ram Chitrapu)
To: kernelnewbies@lists.kernelnewbies.org
Subject: question regarding down_interruptible
Date: Tue, 5 Apr 2011 09:07:30 +0530 [thread overview]
Message-ID: <BANLkTi=tRUQNugQ4_iacrMWWvD3g_CPDEw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTinfpoLUBpFPnM96ApaEwvHYeeWoJQ@mail.gmail.com>
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
>
next prev parent reply other threads:[~2011-04-05 3:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-04 4:27 question regarding down_interruptible Vijay Ram Chitrapu
2011-04-04 15:48 ` Dave Hylands
2011-04-05 3:37 ` Vijay Ram Chitrapu [this message]
2011-04-05 6:24 ` Mulyadi Santosa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTi=tRUQNugQ4_iacrMWWvD3g_CPDEw@mail.gmail.com' \
--to=chitrapu.vijayram@gmail.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).