[Bug 14495] udev sends multiple add/remove events in quick succession

[bugzilla-daemon at bugzilla.ubuntu.com]

Please do not reply to this email.  You can add comments at
http://bugzilla.ubuntu.com/show_bug.cgi?id=14495
Ubuntu | hal





------- Additional Comments From ben.collins at ubuntu.com  2005-10-01 00:02 UTC -------
(In reply to comment #96)
> ...
> Second, the kernel should not fire multiple (identical) events for just one
> "source event" (the physical insertion of the card). If the kernel cannot
> prevent that, nothing that comes after it will be able to.

I disagree with this. The kernel is not sending multiple identical events. It is
sending valid events in valid order. Add, remove, add, remove, add, remove, add.
Those are not abnormal. True, the kernel is sending them without reason, since
there was only one insertion, but there is nothing invalid about the events at all.

Having said that, userspace programs need to be able to cope with valid events,
no matter how fast they come in. Nowhere in the hotplug layer does it say "User
space only has to be able to accept X number of events for device Y during a
period of N". The hotplug layer in the kernel can sit there and pump out events
constantly till the sun goes down, and userspace should be able to handle it.

In this case, what we have is that two different events (add and remove) for the
same device eventually end up being handled by two different code paths, with no
synchronization. Since these two events have everything to do with each other,
they should have some simple locking.

Maybe the pmount handler and the umount handler (scripts I assume?) can lock a
file in /var/run/hal/ that is named based on the device, they would grab the
lock before executing and release the lockfile afterwards, with a 15 second
timeout so there is no deadlock possible. That should be workable for breezy, I
would think.

-- 
Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.