From: kernelnewbies-boun...@kernelnewbies.org 
[mailto:kernelnewbies-boun...@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





_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Reply via email to