chas williams wrote:
> 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.
Great!
> >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.
I'm really not sure it's that safe. At the very least the drivers all
need to make sure that their ->close() excludes their interrupt/bh work
from happening. That would probably be possible but it seems that it
would be better to just build a robust refcount system at the lower layer.
This should make it quite a bit easier to ensure that the drivers are safe.
Also remember that some drivers have a common area that incoming PDUs
get put in (especially for AAL0 traffic) so there might be stuff in there
even after a close.
So I think you're right that it's possible to get by without vcc refcounting
I think the best method would be to implement an atm_vcc_{find,hold,release}
that uses the sock's refcount so we can cleanly and 100% safely take a
reference to a vcc from a bh.
> >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.
Great - now we just have to do the same thing for vcc's :-)
-Mitch
-
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/
This archive was generated by hypermail 2b29 : Sun Mar 23 2003 - 22:00:26 EST