On Wed, Jun 1, 2011 at 03:39, Tejun Heo <htejun@xxxxxxxxx> wrote: > 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. I don't think we ever open anything for writing in udev context, it should be all read-only. >> 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. >> 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). Right. > I've just ordered the same device and will investigate how it actually > behaves If that doesn't show it, I have one here, that does. You'll come visit in 3 weeks anyway. :) > but if the device is just saying media changed all the time, > I'm not sure what the kernel can do It does that with every open() here. > 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. Yeah, we don't want lists, if we can avoid them. They are a nightmare. > 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? Hmm, sure, we can do anything that software can do. :) I'll think about a strategy that could work. Not sure where to put such a 'counter' or how to distinguish 'weird' from 'broken' devices patterns. Should we possibly invent/misuse some open flag to use in udev context, that will suppress the events? Kay -- 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
