Kernelnewbies Digest, Vol 44, Issue 51

Kernelnewbies Digest, Vol 44, Issue 51

[Vishwas Srivastava]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140726/4b6fb106/attachment.html 

Kernelnewbies Digest, Vol 44, Issue 51

[Jeff Haran]

From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces at kernelnewbies.org] On Behalf Of Vishwas Srivastava
Sent: Saturday, July 26, 2014 10:07 AM
To: kernelnewbies at 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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140728/1ffc5ba8/attachment-0001.html 

Kernelnewbies Digest, Vol 44, Issue 51

[Vishwas Srivastava]

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 at kernelnewbies.org [mailto:
> kernelnewbies-bounces at kernelnewbies.org] *On Behalf Of *Vishwas Srivastava
> *Sent:* Saturday, July 26, 2014 10:07 AM
> *To:* kernelnewbies at 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
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140728/5d11cf26/attachment.html 

Kernelnewbies Digest, Vol 44, Issue 51

[Vishwas Srivastava]

thank Jeff for your time to read and reply my mail.

One more ques,
                         are you aware of  anything in linux which can be
used to check  safely, if a particular piece of code is not running in
process context, and therefore can not be preempted or context switched?
For sure, I am going to be much careful to use in_interrupt/in_irq macros
in future.

thanks in advance.
Vishwas S


On Tue, Jul 29, 2014 at 12:30 AM, Jeff Haran <Jeff.Haran@citrix.com> wrote:

>
>
>
>
> *From:* Vishwas Srivastava [mailto:vishu.kernel at gmail.com]
> *Sent:* Monday, July 28, 2014 10:29 AM
> *To:* Jeff Haran; kernelnewbies at kernelnewbies.org
>
> *Subject:* Re: Kernelnewbies Digest, Vol 44, Issue 51
>
>
>
> 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?
>
>
>
> Vishwas,
>
>
>
> My take from this was that the in_interrupt() macro is perhaps
> inappropriately named. It doesn?t tell you you are in an interrupt
> handler. It?s interpreting the bits of the thread_info preempt_count
> field and those bits can be set for a variety of reasons. I?ve found it?s
> not productive to try to impose rules on it after the fact. Not that
> different than for instance the spin_lock() function. If you just read
> that function name, ?spin_lock()?, you might come to the conclusion that
> it implies there is always some sort of spin loop going on. And that?s true
> in many cases, but on a UP system with kernel pre-emption disable,
> spin_lock() does nothing (at least it didn?t do anything the last time I
> look at it closely, that might have changed since). The code does what it
> does and one must struggle through reading it in order to figure out how to
> use it (and hope that you?ve come to the right conclusions and haven?t
> missed some subtlety and that it doesn?t change too much in the future).
> Not the most efficient state of affairs IMHO, but that?s them apples.
>
>
>
> 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.
>
>
>
> ?Reliable? in the sense that what it does sort of matches its mnemonics in
> the case where it returns false. But when it returns true, it means
> something else.
>
>
>
> Jeff Haran
>
>
>
> thanks,
>
> Vishwas S
>
>
>
> On Mon, Jul 28, 2014 at 9:54 PM, Jeff Haran <Jeff.Haran@citrix.com> wrote:
>
>
>
> *From:* kernelnewbies-bounces at kernelnewbies.org [mailto:
> kernelnewbies-bounces at kernelnewbies.org] *On Behalf Of *Vishwas Srivastava
> *Sent:* Saturday, July 26, 2014 10:07 AM
> *To:* kernelnewbies at 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
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140729/288fb2e2/attachment-0001.html