From mboxrd@z Thu Jan 1 00:00:00 1970 From: vishu.kernel@gmail.com (Vishwas Srivastava) Date: Tue, 29 Jul 2014 01:26:04 +0530 Subject: Kernelnewbies Digest, Vol 44, Issue 51 In-Reply-To: <4E5779AD88B2F040B8A7E83ECF544D1A5366A6@SJCPEX01CL02.citrite.net> References: <4E5779AD88B2F040B8A7E83ECF544D1A536535@SJCPEX01CL02.citrite.net> <4E5779AD88B2F040B8A7E83ECF544D1A5366A6@SJCPEX01CL02.citrite.net> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org 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 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 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