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

[Duncan Sands <duncan.sands@wanadoo.fr>]

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