Re: udev queue error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel]     [Linux DVB]     [Asterisk Internet PBX]     [DCCP]     [Netdev]     [X.org]     [Util Linux NG]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux