On Fri, 2002-09-27 at 23:21, Andre Hedrick wrote:
> Glad we agree on the lock issue, thanks for confirming the point!
Great!
> There is an issue of interrupt acknowledgement and when one can pre-empt.
> I would like to resolve the issue, but I need a global caller/notifier api
> from you so I can block IO in a safe spot on the 'data transfer' state
> bar. Yeah, blah blah on underfined terms.
Well, I do not know what the problem is (or what the hell you are
talking about, to be honest). You really should not have any problems
with preemption over regular SMP issues. If your code has a problem
with other code running concurrently, then it should already hold a lock
and thus be non-preemptive?
Also note we do not preempt interrupt handlers (obviously).
If you have a critical section in which you do not want to be preempted,
do a:
preempt_disable();
/* critical section ... */
preempt_enable();
This would have to be code that is in user-context and does not already
hold a lock. There are very few explicit places that need this. You
would be the first block driver, I believe.
Whatever this issue is, note it is entirely separate from the above
locking issue. I also want to iterate that the locking problem
(rescheduling while holding a lock) is a problem on UP even. Yes, think
about it. Assuming the lock really needs to be held, it is protecting a
critical region. If we reschedule, we can enter that region (or another
one of the same data protected hopefully by the same lock). On SMP, we
would deadlock. But on UP we will just silently corrupt the data.
I.e., we can race on UP here.
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 : Mon Sep 30 2002 - 22:00:34 EST