From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Miao Date: Fri, 15 Jun 2012 09:18:30 +0000 Subject: Race condition that a serio driver would not be loaded Message-Id: MIME-Version: 1 Content-Type: multipart/mixed; boundary="e89a8f22bb3deded8204c27f4dc1" List-Id: To: linux-hotplug@vger.kernel.org --e89a8f22bb3deded8204c27f4dc1 Content-Type: text/plain; charset=UTF-8 Hi Kay & Greg, There's a problem with udev's default 80-drivers.rules, that a modprobe be only done when DRIVER!="?*". Here is a race condition that we recently identified where psmouse would not be correctly loaded, and thus causing the touchpad not usable. Below is my theory: 1. serio ports (e.g. AUX port for touchpad) are different than other devices that: - the kernel is using a dedicated kernel thread kseriod to handle the events - interrupts on serio port will trigger connect attempt, as the OS has no idea when a keyboard/mouse could be plugged into the computer 2. The AT keyboard driver atkbd.c is by default built-in to the kernel for speed up as there will be normally an AT keyboard present, however, as on a normal PC, the keyboard can be connected to either the keyboard PS/2 port (i.e. KBD port), or the mouse PS/2 port (i.e. AUX port), the atkbd driver will be probed each time an interrupt is generated on the AUX port, in case there is a plug. 3. When doing the probing, the serio1 device will be temporarily binded with atkbd, and this is in the context of kseriod 4. udev has the chance of being launched at the same time, the time that udev is launched, there will be a trigger to replay all uevents 5. that trigger will request uevents to be generated from the kernel, and if serio1 happens to be in the middle of a probing (most likely with atkbd), the uevent generated will have DRIVER=atkbd with it 6. psmouse is being built as a module, udev is following the rule below to load psmouse on demand: /lib/udev/rules.d/80-drivers.rules: ... DRIVER!="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -bv $env{MODALIAS}" 7. So if uevent for serio1 happens to be with DRIVER entry, this rule will _not_ be performed as DRIVER!="?*" is _not_ matched, thus modprobe will not load psmouse 8. One simple fix is to add one additional rule to 80-drivers.rules, so that serio events are treated special that modprobe will anyway be performed, e.g. SUBSYSTEM=="serio", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -bv $env{MODALIAS}" I'm using udev-173 to generate the attached diff, think the same theory applies to the latest udev as well. The fix is still under testing, as the race condition itself is rarely happening (chance will be more likely if manually generating activities on the touchpad during startup) but so far (50+ reboot) no further issue has been observed. --e89a8f22bb3deded8204c27f4dc1 Content-Type: application/octet-stream; name="fix-race-condition-of-serio-driver-module-not-loading.patch" Content-Disposition: attachment; filename="fix-race-condition-of-serio-driver-module-not-loading.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h3h1p6t20 ZGlmZiAtLWdpdCBhL3J1bGVzL3J1bGVzLmQvODAtZHJpdmVycy5ydWxlcyBiL3J1bGVzL3J1bGVz LmQvODAtZHJpdmVycy5ydWxlcwppbmRleCAwNGE4NmJkLi43NDBjNjdlIDEwMDY0NAotLS0gYS9y dWxlcy9ydWxlcy5kLzgwLWRyaXZlcnMucnVsZXMKKysrIGIvcnVsZXMvcnVsZXMuZC84MC1kcml2 ZXJzLnJ1bGVzCkBAIC0zLDYgKzMsNyBAQAogQUNUSU9OPT0icmVtb3ZlIiwgR09UTz0iZHJpdmVy c19lbmQiCiAKIERSSVZFUiE9Ij8qIiwgRU5We01PREFMSUFTfT09Ij8qIiwgUlVOKz0iL3NiaW4v bW9kcHJvYmUgLWJ2ICRlbnZ7TU9EQUxJQVN9IgorU1VCU1lTVEVNPT0ic2VyaW8iLCBFTlZ7TU9E QUxJQVN9PT0iPyoiLCBSVU4rPSIvc2Jpbi9tb2Rwcm9iZSAtYnYgJGVudntNT0RBTElBU30iCiBT VUJTWVNURU09PSJ0aWZtIiwgRU5We1RJRk1fQ0FSRF9UWVBFfT09IlNEIiwgUlVOKz0iL3NiaW4v bW9kcHJvYmUgLWJ2IHRpZm1fc2QiCiBTVUJTWVNURU09PSJ0aWZtIiwgRU5We1RJRk1fQ0FSRF9U WVBFfT09Ik1TIiwgUlVOKz0iL3NiaW4vbW9kcHJvYmUgLWJ2IHRpZm1fbXMiCiBTVUJTWVNURU09 PSJtZW1zdGljayIsIFJVTis9Ii9zYmluL21vZHByb2JlIC1idiAtLWFsbCBtc19ibG9jayBtc3By b19ibG9jayIK --e89a8f22bb3deded8204c27f4dc1--