Re: atm_devs protection.

2000-10-18 Thread Mitchell Blank Jr
Werner Almesberger wrote: > Mitchell Blank Jr wrote: > > Yeah, a lot of the add/remove device ATM code (and, IMO, even the vcc > > open/close) code is pretty suspect. > > That's actually a bit of an understatement: Well, I was trying to be polite to the original author ;-) -Mitch - To unsubscri

Re: atm_devs protection.

2000-10-18 Thread Werner Almesberger
Mitchell Blank Jr wrote: > Yeah, a lot of the add/remove device ATM code (and, IMO, even the vcc > open/close) code is pretty suspect. That's actually a bit of an understatement: device removal and module unloading it were never really meant to work :-) About the only thing that might be okay rig

Re: atm_devs protection.

2000-10-18 Thread Rogier Wolff
Mitchell Blank Jr wrote: > Rogier Wolff wrote: > As far as module_unload, isn't that protected by lock_kernel? What am > I missing? Would "binding a socket to a VCC" also be protected by lock_kernel? If it isn't then, THAT's the problem. Roger. -- ** [EMAIL PROTECTE

Re: atm_devs protection.

2000-10-18 Thread Mitchell Blank Jr
Rogier Wolff wrote: > We're trying to make the module refcounting 'secure' against > concurrent SMP unloads. > > For example in net/atm/resources.c: Yeah, a lot of the add/remove device ATM code (and, IMO, even the vcc open/close) code is pretty suspect. If you want to look through and liberal