From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Date: Wed, 01 Jun 2011 04:42:06 +0000 Subject: Re: udev queue error Message-Id: <20110601044206.GB23067@mtj.dyndns.org> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org Hello, On Wed, Jun 01, 2011 at 04:10:31AM +0200, Kay Sievers wrote: > > Oh, correction. =A0Write O_EXCL open - close sequence trigger immediate > > recheck because event checking is blocked over write O_EXCL open. >=20 > 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 >=20 > 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? >=20 > 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. >=20 > 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. --=20 tejun