Re: Kernelnewbies Digest, Vol 44, Issue 51
Hi All, I have a doubt regarding the threaded interrupt handing mechanism. what is the kernel context of execution while executing interrupt thread. if i check for macro in_irq() or in_interrupt() withing handler thread , my understanding is that they both are going to return me 0 (since we are in kernel thread), as threads runs in process context. Also, since they are "kernel threads", they must be schedulable enteties. what conceptually deviated me from my understanding is one of the driver which had a threaded interrupt mechanism and when i checked in_interrupt() macro, it returned me a non zero value so i am a bit confused. thanks in advance. Vishwas S
From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces@kernelnewbies.org] On Behalf Of Vishwas Srivastava Sent: Saturday, July 26, 2014 10:07 AM To: kernelnewbies@kernelnewbies.org Subject: Re: Kernelnewbies Digest, Vol 44, Issue 51 Hi All, I have a doubt regarding the threaded interrupt handing mechanism. what is the kernel context of execution while executing interrupt thread. if i check for macro in_irq() or in_interrupt() withing handler thread , my understanding is that they both are going to return me 0 (since we are in kernel thread), as threads runs in process context. Also, since they are "kernel threads", they must be schedulable enteties. what conceptually deviated me from my understanding is one of the driver which had a threaded interrupt mechanism and when i checked in_interrupt() macro, it returned me a non zero value so i am a bit confused. By any chance had you disabled interrupts or bottom halves when you made this call to in_interrupt()? The reason I ask is the last time I looked into this the conclusion I came to was that in_interrupt() would return non-zero under a couple of different conditions; 1) the code was really executing in either a bottom half or IRQ context, or; 2) the code was executing in process context but had previously disabled interrupts or bottom halves, e.g. a call to spin_lock_bh() or anything else that disables bottom halves. At the time I was trying to figure out how to tell for sure whether or not a given function was being called from a bottom half (as opposed to executing in process context with bottom halves disabled) and from what I could see at the time, there was no way to distinguish the two conditions. Disclaimer: I’m no expert on this stuff, just reporting what I concluded at the time from eyeballing the code. Perhaps I missed something. Jeff Haran thanks in advance. Vishwas S
Hi Jeff, yes, your guess is correct. The place i checked in_interrupt() was a region before which a call to spin_lock_bh() was made. So what is the rule? if in_interrupt() return me true then that is the region of the code which can not be context switched or if i am out of interrupt (in kernel thread) and have called spin_lock_bh(), then this macro is not reliable to safely find out if the region below this can not be context switched? If that is the case, then perhaps only the "false" return of the macro in_interrupt is reliable. thanks, Vishwas S On Mon, Jul 28, 2014 at 9:54 PM, Jeff Haran <Jeff.Haran@citrix.com> wrote:
*From:* kernelnewbies-bounces@kernelnewbies.org [mailto: kernelnewbies-bounces@kernelnewbies.org] *On Behalf Of *Vishwas Srivastava *Sent:* Saturday, July 26, 2014 10:07 AM *To:* kernelnewbies@kernelnewbies.org *Subject:* Re: Kernelnewbies Digest, Vol 44, Issue 51
Hi All,
I have a doubt regarding the threaded interrupt handing mechanism.
what is the kernel context of execution while executing interrupt thread.
if i check for macro
in_irq() or in_interrupt() withing handler thread , my understanding is that they both are going to return me 0 (since we are in kernel thread),
as threads runs in process context.
Also, since they are "kernel threads", they must be schedulable enteties.
what conceptually deviated me from my understanding is one of the driver which had a threaded interrupt mechanism and when i checked
in_interrupt() macro, it returned me a non zero value so i am a bit confused.
By any chance had you disabled interrupts or bottom halves when you made this call to in_interrupt()?
The reason I ask is the last time I looked into this the conclusion I came to was that in_interrupt() would return non-zero under a couple of different conditions; 1) the code was really executing in either a bottom half or IRQ context, or; 2) the code was executing in process context but had previously disabled interrupts or bottom halves, e.g. a call to spin_lock_bh() or anything else that disables bottom halves. At the time I was trying to figure out how to tell for sure whether or not a given function was being called from a bottom half (as opposed to executing in process context with bottom halves disabled) and from what I could see at the time, there was no way to distinguish the two conditions. Disclaimer: I’m no expert on this stuff, just reporting what I concluded at the time from eyeballing the code. Perhaps I missed something.
Jeff Haran
thanks in advance.
Vishwas S
participants (2)
-
Jeff Haran -
Vishwas Srivastava