Re: [Bluez-devel] Oops involving RFCOMM and sysfs

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sun, Jan 06, 2008 at 11:54:43AM +0900, Tejun Heo wrote:
> That means sysfs_remove_dir() is called on parent while other operations
> are in progress on children, right?  sysfs has never allowed such things
> && AFAIK no one does that.  It's somewhat implied in the interface (such
> as recursive removing) but I fully agree it's problematic.  Things like
> these are why I think we need to unify/simplify locking as I wrote
> previously.

All it takes is kobject_rename() or kobject_move() called asynchronously 
wrt removal...  I don't see an explicit ban for that.

FWIW, what happens here *is* fishy, but I don't see an outright ban on
that in documentation - rfcomm_tty_open() does
                device_move(dev->tty_dev, rfcomm_get_device(dev));
when we get openers, rfcomm_tty_close() does
                device_move(dev->tty_dev, NULL);
when the number of openers hits zero.  Can happen repeatedly.

Note that device_move() with new parent being NULL is explicitly allowed
and handled, so...

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel