<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 5, 2018 at 8:02 AM, Peter Hutterer <span dir="ltr"><<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>></span> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I think there is some race conditions between the udev rules and the hwdb<br>
and I cannot rely that udev rules are applied consistently on a device.<br>
<br>
For reference, after building libinput run<br>
  sudo ./build/libinput-test-suite-<wbr>runner --filter-test=lid_update_hw_<wbr>on_key_multiple_keyboards<br>
run it repeatedly and at some point it will fail.<br>
<br>
The source of the issue is the udev properties for the test device<br>
*sometimes* get overwritten by the hwdb value of a rule with a lower lexical<br>
ordering. In other words: 90-something.hwdb+rules overwrites<br>
99-myrule.rules, that shouldn't happen (or at least not randomly).<br>
<br>
For more detail, the relevant parts are:<br>
<br>
90-foo.hwdb entry with a dmi match that assigns a property<br>
<br>
    libinput:name:*Lid Switch*:dmi:*:ct9:*<br>
     LIBINPUT_ATTR_LID_SWITCH_<wbr>RELIABILITY=reliable<br>
<br>
and the matching 90-foo.rules:<br>
    KERNELS=="input*", \<br>
      IMPORT{builtin}="hwdb 'libinput:name:$attr{name}:$<wbr>attr{[dmi/id]modalias}'"<br>
<br>
This assigns 'reliable' to the device.<br>
<br>
I also have per-device udev rules, 92-foo.rules, in this case:<br>
<br>
    ATTRS{name}=="litest Lid Switch Surface3*", \<br>
        ENV{ID_INPUT_SWITCH}="1", \<br>
        ENV{LIBINPUT_ATTR_LID_SWITCH_<wbr>RELIABILITY}="write_open"<br>
<br>
This overwrites 'reliable' with 'write_open'.<br>
<br>
On test-runner start, we install all the udev rules and hwdb files, run hwdb<br>
--update and then start the tests.<br>
<br>
In *most* cases, 'write_open' is correctly assigned to the device. In the<br>
failure cases, 'reliable' is assigned. Nothing changes in the udevadm test<br>
output and I've verified that the order appears to change, in the failure<br>
cases the 92-foo.rules applies before the hwdb overwrites it:<br>
<br>
    ATTRS{name}=="litest Lid Switch Surface3*",<br>
        ENV{ID_INPUT_SWITCH}="1",<br>
        ENV{BONGO}="litest",<br>
        ENV{LIBINPUT_ATTR_LID_SWITCH_<wbr>RELIABILITY}="write_open"<br>
<br>
    ATTRS{name}=="litest Lid Switch Surface3*",<br>
        ENV{FIRSTVAL}="$env{LIBINPUT_<wbr>ATTR_LID_SWITCH_RELIABILITY}"<br>
<br>
Running with this udev rule shows that FIRSTVAL is write_open but the real<br>
property is 'reliable'.<br>
<br>
This happens anywhere between 1 out of 3 and 1 out of 50, though it seems to<br>
be more common when creating/removing uinput devices like crazy.</blockquote><div><br></div><div>Here's a wild guess...</div><div><br></div><div>I wonder if the race condition is in ATTRS{}; attributes are not cached but read directly from sysfs, and for ATTRS udev has to go upwards the entire /sys hierarchy – for each and every rule, I believe.</div><div><br></div><div>So it could be that some rules do not match because by that time the device has already disappeared. What happens if you change the rules to rely entirely on ENV{} matches?</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div>
</div></div>