Yes. And that's pretty fundamental, I fear (not fundamental to us, it's
just a fundamental synchronization problem that we can't really handle
in the general case).
> >can't be a new irq after the call, because we just disabled it (and we
>
> Wrong. There can be since we may have an irq handler running after the
> first spin_unlock below, while disable_irq() is running on the other CPU:
No. Only if disable_irq() is buggy.
Andrea, I already _said_ that I agree with disable_irq() being buggy.
That's not the issue - and was addressed by your first patch (which then
had the lock-up problem, but that's a separate issue and can be simply
addressed). It's the second patch I still think was fairly ugly.
However, the later versions of that second patch are looking much nicer
and have the lockup problem addressed cleanly, so I'm looking at them
seriously now.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/