Messages in this thread | | | Subject | Re: [ATM] first pass at fixing atm spinlock | Date | Mon, 17 Mar 2003 18:25:50 -0500 | From | chas williams <> |
| |
In message <20030317150144.F92155@sfgoth.com>,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 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/
| |