[Linux-ATM-General] [RFC][PATCH] Very basic sysfs support for ATM devices (updated)

Duncan Sands duncan.sands at math.u-psud.fr
Mon Feb 7 04:03:08 EST 2005


Hi Roman,

> Besides, I've encountered a problem with hotplug being called from
> atm_dev_register: the device actually becomes usable only when the
> driver sets .dev_data, which may happen after hotplug has been called.
> E.g. if I call br2684ctl in my hotplug script, and it happens to attempt
> to open a socket on the device before .dev_data is set, br2684ctl fails
> (rather disgracefully BTW, forgetting to cleanup nasX).  I had to work
> around it by adding a sleep for a couple of seconds to the hotplug
> script, and hoping that was enough for the driver to complete
> initializing atm_dev.  I suspect the only way to fix it is to split the
> atm_dev initialization into two stages, allocation and registration, as
> it is done for net_device.

this is a long-standing problem with ATM device initialisation: the device
becomes available before the struct atm_dev is initialised!  In theory a
driver's ATM methods could be called the moment atm_dev_register returns,
and before the driver has had a chance to fill in any fields.  That's why
all the ATM methods in the speedtouch driver check atm_dev->dev_data, and
return without doing anything if it is NULL: atm_dev->dev_data is only set
to a non-NULL value when the struct atm_dev has been fully initialised (this
is the reason for the memory barrier by the way).  When you say
"the device actually becomes usable only when the driver sets .dev_data",
I think that's a property of the speedtouch driver only.  With other drivers
it is probably worse: you get to open a connection even though the structure
is not initialized, and boom!  In the past, this race was only a theoretical
problem for SMP machines; but with your patch it hits everyone.

Ciao,

Duncan.



More information about the Usbatm mailing list