On Mon, Jan 14, 2008 at 05:28:44PM +1100, Neil Brown wrote: > On Monday January 14, neilb@xxxxxxx wrote: > > > > Thanks. I'll see what I can some up with. > > How about this, against current -mm > > On both the read and write path for an rdev attribute, we > call mddev_lock, first checking that mddev is not NULL. > Once we get the lock, we check again. > If rdev->mddev is not NULL, we know it will stay that way as it only > gets cleared under the same lock. > > While in the rdev show/store routines, we know that the mddev cannot > get freed, do to the kobject relationships. > > rdev_size_store is awkward because it has to drop the lock. So we > take a copy of rdev->mddev before the drop, and we are safe... > > Comments? *cringe* I really don't like the entire scheme, to be honest. BTW, what happens if you try to add the same device to the same array after having it kicked out? If that comes before your delayed kobject_del(), the things will get nasty since sysfs will (rightfully) refuse to add another entry with the same name and parent while the old one is still there and for all sysfs knows is going to stay there... - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
