[lkml]   [2003]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ATM] first pass at fixing atm spinlock
In message <>,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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:34    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean