On Mon, 2002-04-22 at 19:06, Paul Mackerras wrote:
> > 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?
Sorry - yes, we are preemptible. I meant to say even if we do preempt,
we still end up returning false, which is all we care about.
> 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().
How can we get a false positive? Positive => we are in an interrupt.
If we are in an interrupt, we can't preempt, so this is not an issue.
Negative => we are not in an interrupt. Even if we do preempt, we
preempt to a CPU where we are _also_ not in an interrupt, so we get the
same answer. In other words, if we preempt, no matter where we were or
where we end up, in_interrupt is (correctly) false.
> > 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. :)
Right, but I don't see a flaw (as noted previously) in the current
scheme... if preemption is a problem, then we are certainly in process
context so it is a non-issue!
Robert Love
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 22:00:34 EST