<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 6, 2018 at 1:21 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Feb 05, 2018 at 11:51:30AM +0200, Mantas Mikulėnas wrote:<br>
> On Mon, Feb 5, 2018 at 8:02 AM, Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>><br>
> wrote:<br>
><br>
> > 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_<br>
> > 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<br>
> > 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}:$<br>
> > 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<br>
> > 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<br>
> > to<br>
> > be more common when creating/removing uinput devices like crazy.<br>
><br>
><br>
> Here's a wild guess...<br>
><br>
> I wonder if the race condition is in ATTRS{}; attributes are not cached but<br>
> read directly from sysfs, and for ATTRS udev has to go upwards the entire<br>
> /sys hierarchy – for each and every rule, I believe.<br>
><br>
> So it could be that some rules do not match because by that time the device<br>
> has already disappeared. What happens if you change the rules to rely<br>
> entirely on ENV{} matches?<br>
<br>
</div></div>Thanks for the tip, unfortunately I couldn't verify it. I tried that<br>
yesterday but it's... difficult. Matching on ENV{NAME} turned out to be more<br>
volatile than I expected [1] but the main issue I have here is that NAME is<br>
set on the parent input device, not on the evdev node where everything else<br>
is set. There is no ENVS support to search up from the device, so I'm not<br>
sure I could coerce the rules and hwdb matching into the required hierarchy.<br></blockquote><div><br></div><div>Yeah, after some sleep I realized I'm probably *way* off.</div><div><br></div><div>(That said, there is IMPORT{parent}="fooenv".)</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div>
</div></div>