Andrea Arcangeli (arcangeli@mbox.queen.it)
Mon, 31 Aug 1998 12:47:49 +0200 (CEST)
On Mon, 31 Aug 1998, Philip Blundell wrote:
>>I don' t want to think if it could happen a deadlock. The patch is the
>>strightforward way to use spinlock. It' s not overkill. Think why don' t
>>you use 1 only spinlock all over the kernel and why spinlock spinlocks
>>exists in first place.
>
>You said it was "necessary" though, which implies it was fixing a problem
>rather than just improving or tidying up code. Is that the case, and if so
>what was the problem?
I think that with the current code it' s impossible that a deadlock
happnes, since currently every spinlock is used with the
spin_[un]lock_irqsave version and there is an unlock after every lock. It
works as it' s true that 2.0.x works in SMP machines.
The point is that I think that the spinlock code is misused. There is one
only spinlock used for completly disconnected section of code. We use the
same lock to assure integrity of the pardevice list at insmod/rmmod time.
The same lock is used to assure the integrity of the waitlist (that has
_nothing_ to do with the pardevice list) and that is modifyed at runtime
not at insmod time). Yes, for the end user is only an improvement but it
looks me the right implementation and I consider the old one a misuse of
the spinlock code.
I thought about spinlocks also in the past but I had not time to do the
diff.
Andrea[s] Arcangeli
-- 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:18:11 EST