Re: [ATM] first pass at fixing atm spinlock

[chas williams]

In message <[e-mail]>,Mitchell Blank Jr writes:
>Note that this patch also has lots of other stuff (he driver, ipv6 stuff)

that ipv6 stuff crept in there (due to a bad merge on my part).  i believe
i have that right now.

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

fairly certain.  the only dangerous thing proc.c is snprintf().  i didnt
want to spend a lot of time on proc.c doing it the 'right' way (using
atm_dev_hold/release) since it will be change to a seq interface.

>sock/vcc combo can't go away while a processor's bh still is using a reference
>to the vcc.  I think this has been the result of many of the reported SMP
>crashes (it's probably not that hard to trigger; just close an ATM socket
>that's receiving a flood of traffic)

i dont know.  i believe all of the adapters do a synchronous close.  after
the close finishes, no more traffic should arrive for a particular vcc.
the bottom halfs (halves?) should not have references to vcc after a close()
for it finishes.

>You really need something like atm_dev_release_last() that waits for the
>reference count to hit "1" (via a completion or something) and then does
>the release stuff.

atm_dev_deregister() does that.  if a driver need to remove the atm
device (i suppose its being unplugged) it could close the vcc's and 
call atm_dev_register() which will wait the ref count to drop to 0.