Hello, Kay, Markus. On Tue, May 31, 2011 at 05:46:24PM +0200, Kay Sievers wrote: > > * udev doesn't open device w/ O_EXCL, right? > > Cdrom_id uses O_EXCL if the disk is not mounted. If it's mounted we > obviously can't use O_EXCL and don't use it. Oh, correction. Write O_EXCL open - close sequence trigger immediate recheck because event checking is blocked over write O_EXCL open. > If it's a data disk, we call blkid which does not use O_EXCL. > > > * Does a MEDIA_CHANGE event trigger multiple opens? > > Yeah, it can run multiple things against the drive. If it's a data cd > it will run cdrom_id and blkid with the same event. But this can trigger chain events if the device is reporting media changed spuriously. > > I _think_ if udev > > opens only once, the event shouldn't be re-generated immediately. > > Yeah, but we can't assume only a single open() without making huge changes. Understood. > > It will happen on the next poll interval but it won't be a busy > > loop. > > This happens without the in-kernel polling enabled. Yes, it doesn't have much to do with polling per-se. The new check event is used during regular open path. Before, it wouldn't have generated a new event but with ->check_events() changes, GET_EVENT_STATUS_NOTIFICATION result carries more weight and event is generated if GET_EVENT_STATUS_NOTIFICATION says so (which was one of the goals of the conversion after all). I've just ordered the same device and will investigate how it actually behaves but if the device is just saying media changed all the time, I'm not sure what the kernel can do other than black listing it so that event is not generated for the device, which will solve the udev infinite looping but if we do that we'll just be pushing the problem to userland and solving the problem for only this device. I think the sensible thing to do is applying some form of back-off strategy so that udev doesn't fall into infinite loop no matter what the device says, which I think is better implemented from userland. Would that be difficult to implement from udev side? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
