Re: [Linux-ATM-General] Re: [ATM] first pass at fixing atm spinlock

Duncan Sands (duncan.sands@wanadoo.fr)
Wed, 19 Mar 2003 18:11:00 +0100


>> atm_dev_lock is now a
>> read/write lock that now protects the list of atm devices.
>
>Are you sure you're never sleeping while holding this lock while iterating
>device lists? I haven't checked but we do a fair number of things there
>(like the proc stuff) so we really need to track those down.

[I hope the following comments are not misplaced: I picked up this
thread half way through, and I didn't read the code...]

Presumably the only reason you want a spin lock is because drivers
may be walking the list in interrupt context when the time comes
to add/remove a member. My first comment is: what are drivers
doing walking this list anyway? Shouldn't it be private to the ATM
layer? Drivers can maintain their own list if they need one. My
second comment is that the ATM layer should never need to take
the spinlock itself when walking the list (I'm guessing it always
walks the list in process context). You could have the following
setup: list protected by a semaphore and a spinlock.

Deleting a member does the following:
acquire the semaphore
...
take the spinlock
delete the member
release the spinlock
...
release the semaphore

Adding a member does the following:
acquire the semaphore
...
take the spinlock
add the member
release the spinlock
...
release the semaphore

Walking the list in process context does:
acquire the semaphore
walk the list doing stuff
release the semaphore

Walking the list in interrupt context does:
acquire the spinlock
walk the list doing stuff that can't sleep
release the spinlock

Of course the semaphore could be used as a "big device lock",
not just a list lock.

Duncan.

-
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/