From 69348b66ff4163a2fbf974bde649e5bc963462b4 Mon Sep 17 00:00:00 2001 From: Kay Sievers Date: Mon, 29 Aug 2005 01:19:02 +0200 Subject: [PATCH] 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 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 --- udevd.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/udevd.c b/udevd.c index 3a8ac639b..96d4fbb3b 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) -- 2.30.2