Tim Waugh (tim@cyberelk.demon.co.uk)
Thu, 16 Apr 1998 20:33:06 +0100 (BST)
On Thu, 16 Apr 1998, Andrea Arcangeli wrote:
> The bug is that you exchanged lp_schedule() with lp_yield(). lp_schedule()
> is called so since it _must_ schedule() in _some_ way inside it.
> lp_yield() can schedule() only if need_resched is 1.
Must it? Okay, I can change that.
> As second it' s not smart to schedule() if _then_ we will have to
> sleep_on() in parport_claim_or_block().
No, but equally it's not smart to do a release followed immediately by a
claim if the other guy has a wakeup function registered (on a uniprocessor
machine at least), as they will wake up only to find that the port is
already claimed.
Driver 1 Driver 2
(sleeping, waiting for wakeup)
(yield:)
release
wakeup 2 (becomes runnable)
claim (succeeds)
...
(run out of time) (gets processor)
"Cool, I've been woken up by parport!"
claim (fails)
Have I got that right?
> With the current implementation it can happen that while we are adding the
> pardevice to the waiters list (at the end of parport_claim()) another CPU
> could run parport_release(). The other CPU could run "port->cad = NULL;"
> while the first CPU has just passed the test:
Your patch looks correct to me. Thanks,
Tim.
*/
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:17:38 EST