remove special TIMEOUT handling from incoming queue

Moving events directly to the exec queue instead of the reordering
incoming queue, leaves holes in the sequence, that lead to timeouts for
all other events. Remove that part of the special handling.

(With netlink, events can't get out-of-order and the maximum timeout is 5
seconds and should not cause any trouble with the 10 sec timout for the
firmware class anyway. Events with timeouts are still prioritized for
execution, but don't bypass the incoming queue anymore.)

Many thanks to:
  Uberto Barbini <uberto@ubiland.net>

for his endless debugging and sending all the traces, that showed this
failure with his DVB device:
  UEVENT[1124474094] add@/module/stv0299
  UEVENT[1124474094] add@/module/ves1x93
  UEVENT[1124474094] add@/module/ttpci_eeprom
  UEVENT[1124474094] add@/module/saa7146
  UEVENT[1124474094] add@/module/video_buf
  UEVENT[1124474094] add@/module/saa7146_vv
  UEVENT[1124474094] add@/module/dvb_core
  UEVENT[1124474094] add@/module/dvb_ttpci
  UEVENT[1124474094] add@/bus/pci/drivers/dvb
  UEVENT[1124474094] add@/class/firmware/0000:00:14.0
  UDEV  [1124474094] add@/module/dvb_core
  UDEV  [1124474094] add@/module/saa7146_vv
  UDEV  [1124474094] add@/module/dvb_ttpci
  UDEV  [1124474094] add@/module/ves1x93
  UDEV  [1124474094] add@/module/ttpci_eeprom
  UDEV  [1124474094] add@/module/saa7146
  UDEV  [1124474094] add@/module/stv0299
  UDEV  [1124474094] add@/module/video_buf
  UDEV  [1124474094] add@/bus/pci/drivers/dvb
  UEVENT[1124474094] remove@/class/firmware/0000:00:14.0  <- event with TIMEOUT will leave a hole in the incoming
  UDEV  [1124474094] add@/class/firmware/0000:00:14.0        sequence, which will cause a wait for the alarm()
  UEVENT[1124474094] add@/class/i2c-adapter/i2c-1            that flushes the queue
  UEVENT[1124474094] add@/class/i2c-dev/i2c-1
  UDEV  [1124474094] remove@/class/firmware/0000:00:14.0  <- event also has TIMEOUT and is executed immediately
  UEVENT[1124474095] add@/class/dvb/dvb0.demux0
  UEVENT[1124474095] add@/class/dvb/dvb0.dvr0
  UEVENT[1124474095] add@/class/dvb/dvb0.video0
  UEVENT[1124474095] add@/class/dvb/dvb0.audio0
  UEVENT[1124474095] add@/class/dvb/dvb0.ca0
  UEVENT[1124474095] add@/class/dvb/dvb0.osd0
  UEVENT[1124474095] add@/class/dvb/dvb0.net0
  UEVENT[1124474095] add@/class/video4linux/video1
  UEVENT[1124474095] add@/class/dvb/dvb0.frontend0
  UDEV  [1124474099] add@/class/i2c-adapter/i2c-1         <- all others have 5 seconds delay cause of the missing event
  UDEV  [1124474099] add@/class/dvb/dvb0.ca0                 missing events
  UDEV  [1124474099] add@/class/dvb/dvb0.osd0
  UDEV  [1124474099] add@/class/video4linux/video1
  UDEV  [1124474099] add@/class/dvb/dvb0.frontend0
  UDEV  [1124474099] add@/class/dvb/dvb0.video0
  UDEV  [1124474099] add@/class/dvb/dvb0.audio0
  UDEV  [1124474099] add@/class/i2c-dev/i2c-1
  UDEV  [1124474099] add@/class/dvb/dv

My test program that simulates a similar sequence, runs without any delay
now. (With one of the next versions we will make netlink mandatory, then
we can remove the whole input queue crap with the reordering anyway.)

Signed-off-by: Kay Sievers <kay.sievers@suse.de>

1 files changed, 0 insertions, 9 deletions

diff --git a/udevd.c b/udevd.c
index 3a8ac639bd..96d4fbb3be 100644
--- a/udevd.c
+++ b/udevd.c
@@ -131,15 +131,6 @@ static void msg_queue_insert(struct uevent_msg *msg)
 			init_phase = 0;
 	}
 
-	/* don't delay messages with timeout set */
-	if (msg->timeout) {
-		info("seq %llu with timeout %u seconds will be execute without queuing, '%s' '%s'",
-		     msg->seqnum, msg->timeout, msg->action, msg->devpath);
-		list_add(&msg->node, &exec_list);
-		run_exec_q = 1;
-		return;
-	}
-
 	/* sort message by sequence number into list */
 	list_for_each_entry_reverse(loop_msg, &msg_list, node) {
 		if (loop_msg->seqnum < msg->seqnum)