Re: in_interrupt race

[Robert Love]

On Mon, 2002-04-22 at 17:39, george anzinger wrote: 

> Robert Love wrote:
> > Or perhaps leave the code as-is but make the rule preemption needs to be
> > disabled before calling (either implicitly or explicitly).  I.e., via a
> > call to preempt_disable or because interrupts are disabled, a lock is
> > held, etc ...
> 
> Right, getting a consistant flag is not much use if it isn't used within
> the same context.

Oh, wait ... someone clue me in to what I am missing, but the context
does not matter - in fact, we do not need even my fix. 

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.

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.

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. 
This says nothing of the CPU you may of been on, but then who cares
about it?

	Robert Love