Re: in_interrupt race

[Paul Mackerras]

Robert Love writes:

> We have two cases: 
> 
> (a) we are in an interrupt or softirq, 
> (b) we are not in an interrupt or softirq. 
> 
> If (a), we are not preemptible and thus do _not_ need explicit
> preemption disabling.

True.

> If (b) we are preemptible, and then it does not matter what happens
> during this check, since we are not preemptible and the check won't
> return a false true.

Huh?  First you say we are preemptible, then you say we are not, in
the same sentence?

> Now, if we are actually using in_interrupt() as "is this exact CPU
> processing an interrupt?" we may not get what we want (because we could
> end up on CPU#2 from #1, and now #1 is indeed in an interrupt).  But
> that is rarely (if ever?) the point of the call.
> 
> The majority, if not all, uses of in_interrupt is to see if you entered
> the current code from an interrupt.  Like in schedule, "did we enter
> this function off an interrupt?"  Thus, with or without preemption:
> 
> 	if (in_interrupt())
> 		/* yep! */
> 
> will _always_ return false if your current CPU is not in an interrupt. 

No.  The point is that in_interrupt() asks two separate questions:
(1) which cpu are we on?  (2) is that cpu in interrupt context?
If we switch cpus between (1) and (2) then we can get a false positive
from in_interrupt().

> This says nothing of the CPU you may of been on, but then who cares
> about it?

We don't care about any cpu, what we want to know is whether the
current thread of execution is in process context or not.  Which is
why it is bogus for in_interrupt to need to ask which cpu we are on,
and why the local_bh_count and local_irq_count should go in the
thread_info struct IMHO.  I am working on that now. :)

Paul.