Re: udev queue error

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


Hello, Kay.

On Thu, Jun 09, 2011 at 02:36:54PM +0200, Kay Sievers wrote:
> On Thu, Jun 9, 2011 at 13:54, Tejun Heo <htejun@xxxxxxxxx> wrote:
> > Maybe we can tag events which were generated during open(2) with the
> > pid of the opener so that udev can reliably filter them?  I think it
> > would be nice if we can somehow make it uni-directional (ie. no extra
> > information from userland to kernel during open
> 
> It's a cool idea.
> 
> But I fear in reality it gets messy pretty fast. We would need to
> track and remember all pids from tools executed by udev rules.
> 
> With the fully async/queued nature of these events, we might not even
> have read the events from the kernel after the event and the called
> tools have long finished their work.
> 
> We could use the session id or process group, but that sounds like
> asking for trouble.

I've been playing with the device a bit and this thing really is an
abomination and reports new media whenever asked. :(

I've been trying to come up with a way to work around the problem.
The only thing we can do from kernel is somehow suppressing event
generation on open (or mark it to be ignored) - be it timing or opener
based; however, there's no way to acheive that in a race-free way.

* Kernel must check whether media is changed upon open.

* If at least one MEDIA_CHANGE event is not generated after device
  indicated the event, we risk losing events.  ie. Media change can
  race against open() and userland may end up with stale information.
  The race window is quite short compared to usual tray actions tho.

I think it would be better to avoid penalizing sane devices and let
timer-based throttling take care of crazy ones.  I don't know how udev
handles it from userland but does it need to keep track of all the
separate events?  Can't it just track the pending states (ie. one bit
for each event) and throttle propagation accordingly?

Also, another thing is that as userland is now in charge of tray
locking, maybe it's safe to ignore MEDIA_CHANGE while the device is
known to be locked from userland?  But, then again, I would be
surprised if there isn't a device which is crazy enough to avoid such
safe guard and still trigger weird behavior.  :(

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


[Linux DVB]     [Video Technology]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Devices]     [Fedora Women]     [ALSA Devel]     [Linux USB]

Add to Google Powered by Linux