On Tue, Sep 30, 2014 at 5:24 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote: >> > commit e64fae5573e566ce4fd9b23c68ac8f3096603314 >> > Author: Kay Sievers <kay.sievers@xxxxxxxx> >> > Date: Wed Jan 18 05:06:18 2012 +0100 >> > >> > udevd: kill hanging event processes after 30 seconds >> > >> > Some broken kernel drivers load firmware synchronously in the module init >> > path and block modprobe until the firmware request is fulfilled. >> > <...> >> >> This was a workaround to avoid a deadlock between udev and the kernel. >> The 180 s timeout was already in place before this change, and was not >> motivated by firmware loading. Also note that this patch was not about >> "tracking device drivers", just about avoiding dead-lock. > > Thanks, can you elaborate on how a deadlock can occur if the kmod > worker is not at some point sigkilled? This was only relevant whet udev did the firmware loading. modprobe would wait for the kernel, which would wait for the firmware loading, which would wait for modprobe. This is no longer a problem as udev does not do firmware loading any more. > Is the issue that if there is no extra worker available and all are > idling on sleep / synchronous long work boot will potentially hang > unless a new worker becomes available to do more work? Correct. > If so I can > see the sigkill helping for hanging tasks but it doesn't necessarily > mean its a good idea to kill modules loading taking a while. Also > what if the sigkill is just avoided for *just* kmod workers? Depending on the number of devices you have, I suppose we could still exhaust the workers. >> The way I see it, the current status from systemd's side is: our >> short-term work-around is to increase the timeout, and at the moment >> it appears no long-term solution is needed (i.e., it seems like the >> right thing to do is to make sure insmod can be near instantaneous, it >> appears people are working towards this goal, and so far no examples >> have cropped up showing that it is fundamentally impossible (once/if >> they do, we should of course revisit the problem)). > > That again would be reactive behaviour, what would prevent avoiding the > sigkill only for kmod workers? Is it known the deadlock is immiment? > If the amount of workers for kmod that would hit the timeout is > considered low I don't see how that's possible and why not just lift > the sigkill. Making kmod a special case is of course possible. However, as long as there is no fundamental reason why kmod should get this special treatment, this just looks like a work-around to me. We already have a work-around, which is to increase the global timeout. If you still think we should do something different in systemd, it is probably best to take the discussion to systemd-devel to make sure all the relevant people are involved. Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
