Re: udev queue error

[Tejun Heo <htejun@xxxxxxxxx>]

Hello,

On Wed, Jun 01, 2011 at 04:10:31AM +0200, Kay Sievers wrote:
> > 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.

I see, so it's the multiple open(2)s then.  Not that that's a wrong
thing to do.

> > 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. :)

Heh, yeah, crappy devices are all around us. :)

> > 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?

I don't think that would be welcome by many people.  Besides, I think
that would be more fragile than implementing proper back-off.  It just
takes one extra open() to trigger the looping and operations hanging
off from a udev event may cause that to happen outside of udev proper,
so it's not straight forward to determine who needs to set such flag.

I _think_ what we really need is a timer based throttling.  e.g. one
token is generated every, say, three seconds and can accumulate upto 5
and each media changed event checking consumes a token and should wait
if there's no token left.  Dunno how difficult it owuld be to
implement this tho.

Thank you.

-- 
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