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 at 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 at 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