On Wed, 2006-03-15 at 09:34 +0100, Oliver Neukum wrote:
> > hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
> > acm_tty_unregister if=cee8896c dev=cee88980 ref=2
> > class_device_del call sysfs_remove_link class_dev=c9a6aec4 ref=2
> > dentry=c8f7a2b4
> > class_device_del call sysfs_remove_link class_dev->dev=cee88980 ref=1
> > dentry=ceaaa1a4 class_name=tty:ttyACM0
> > sysfs_hash_and_remove dir=ceaaa1a4 d_inode=6b6b6b6b
>
> sysfs_hash_and_remove() is called for a freed dentry. This is from the second
> call in class_device_del().
This is becoming clearer:
1. usb device is disconnected (usb/core/hub.c:usb_disconnect)
2. usb_disconnect calls usb_disconnect recursively for child devices
3. usb_disconnect calls drivers/base/core.c:device_unregister() for dev
4. device_unregister() -> device_del() -> device_remove_file()
void device_remove_file(struct device * dev, struct device_attribute * attr)
{
if (get_device(dev)) {
sysfs_remove_file(&dev->kobj, &attr->attr);
put_device(dev);
}
}
The sysfs entry is deleted, which appears to release dev->kobj->dentry
even though dev->kobj is still valid with references.
Later acm_tty_close() -> tty_unregister_device() and dev->kobj->dentry
is touched while trying to release the tty class device symlinks.
--
Should driver core defer sysfs_remove_file until
last dev->kobj reference is dropped?
--
Paul
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
