From: Eric Miao <eric.miao@canonical.com>
To: linux-hotplug@vger.kernel.org
Subject: Race condition that a serio driver would not be loaded
Date: Fri, 15 Jun 2012 09:18:30 +0000 [thread overview]
Message-ID: <CAMPhdO-aTjNid2NwN-V3fos9nDn6nxLTPXU4O_YamJNnf4RYDQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]
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.
[-- Attachment #2: fix-race-condition-of-serio-driver-module-not-loading.patch --]
[-- Type: application/octet-stream, Size: 636 bytes --]
diff --git a/rules/rules.d/80-drivers.rules b/rules/rules.d/80-drivers.rules
index 04a86bd..740c67e 100644
--- a/rules/rules.d/80-drivers.rules
+++ b/rules/rules.d/80-drivers.rules
@@ -3,6 +3,7 @@
ACTION=="remove", GOTO="drivers_end"
DRIVER!="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -bv $env{MODALIAS}"
+SUBSYSTEM=="serio", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -bv $env{MODALIAS}"
SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="SD", RUN+="/sbin/modprobe -bv tifm_sd"
SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="MS", RUN+="/sbin/modprobe -bv tifm_ms"
SUBSYSTEM=="memstick", RUN+="/sbin/modprobe -bv --all ms_block mspro_block"
reply other threads:[~2012-06-15 9:18 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMPhdO-aTjNid2NwN-V3fos9nDn6nxLTPXU4O_YamJNnf4RYDQ@mail.gmail.com \
--to=eric.miao@canonical.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).