Udev monitor monitors the whole input subsystem, but not all devices in the input subsystem have devnodes associated to them.
This MR makes the event processing ignore such devices.
All device handling assumes devices have devnodes, so here we just simply ignore all devices which do not have one. They are irrelevant.
Previously, udev bus thread aborted when an event for a device without a devnode was processed:
``` 10111.330:0068:0084:trace:hid:process_monitor_event Received action "remove" for udev device (null) 10111.330:0068:0084:warn:hid:bus_main_thread L"UDEV" bus wait returned status 0xc0000005 ```
Just plugging in and out a normal mouse was enough cause this.
This was because root input devices (which do not have devnodes) were handled too and `find_device_from_devnode()` choked on NULL argument.
From: Tuomas Räsänen tuomas.rasanen@opinsys.fi
--- dlls/winebus.sys/bus_udev.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c index 419de2e7af3..228d9d8316d 100644 --- a/dlls/winebus.sys/bus_udev.c +++ b/dlls/winebus.sys/bus_udev.c @@ -264,6 +264,12 @@ static struct base_device *find_device_from_devnode(const char *path) { struct base_device *impl;
+ if (!path) + { + FIXME("called find_device_from_devnode(NULL)\n"); + return NULL; + } + LIST_FOR_EACH_ENTRY(impl, &device_list, struct base_device, unix_device.entry) if (!strcmp(impl->devnode, path)) return impl;
From: Tuomas Räsänen tuomas.rasanen@opinsys.fi
Udev monitor monitors the whole input subsystem, but not all devices in the input subsystem have devnodes associated to them.
This commit makes the event processing ignore such devices.
All device handling assumes devices have devnodes, so here we just simply ignore all devices which do not have one.
Previously, udev bus thread aborted when an event for a device without a devnode was processed:
10111.330:0068:0084:trace:hid:process_monitor_event Received action "remove" for udev device (null) 10111.330:0068:0084:warn:hid:bus_main_thread L"UDEV" bus wait returned status 0xc0000005
Just plugging in and out a normal mouse was enough cause this.
This was because root input devices (which do not have devnodes) were handled too and find_device_from_devnode() choked on NULL argument. --- dlls/winebus.sys/bus_udev.c | 34 +++++++++++++++++++++++++++++----- 1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c index 228d9d8316d..48565ea4d6e 100644 --- a/dlls/winebus.sys/bus_udev.c +++ b/dlls/winebus.sys/bus_udev.c @@ -1717,6 +1717,8 @@ static void process_monitor_event(struct udev_monitor *monitor) struct base_device *impl; struct udev_device *dev; const char *action; + const char *devnode; + const char *syspath;
dev = udev_monitor_receive_device(monitor); if (!dev) @@ -1726,20 +1728,42 @@ static void process_monitor_event(struct udev_monitor *monitor) }
action = udev_device_get_action(dev); - TRACE("Received action %s for udev device %s\n", debugstr_a(action), - debugstr_a(udev_device_get_devnode(dev))); + syspath = udev_device_get_syspath(dev); + devnode = udev_device_get_devnode(dev); + TRACE("Received action %s for udev device %s (%p) devnode %s\n", + debugstr_a(action), debugstr_a(syspath), dev, debugstr_a(devnode)); + + if (!syspath) + { + FIXME("udev device %p does not have syspath!\n", dev); + goto out; + }
if (!action) - WARN("No action received\n"); - else if (strcmp(action, "remove")) + { + WARN("event for udev device %s does not have any action!\n", syspath); + goto out; + } + + if (!devnode) + { + // Pretty normal case, not all devices have associated + // devnodes. For example root input devices do not, but + // related/child mouse and event devices do. + TRACE("udev device %s does not have devnode, ignoring\n", syspath); + goto out; + } + + if (strcmp(action, "remove")) udev_add_device(dev, -1); else { - impl = find_device_from_devnode(udev_device_get_devnode(dev)); + impl = find_device_from_devnode(devnode); if (impl) bus_event_queue_device_removed(&event_queue, &impl->unix_device); else WARN("failed to find device for udev device %p\n", dev); }
+out: udev_device_unref(dev); }
Rémi Bernon (@rbernon) commented about dlls/winebus.sys/bus_udev.c:
{ struct base_device *impl;
- if (!path)
- {
FIXME("called find_device_from_devnode(NULL)\n");
return NULL;
- }
You're checking for the same condition in the next commit, so this one then becomes unnecessary. I'd also prefer to only check for this in the callers.
As a side note, FIXME is supposed to be used for things that are not implemented yet, not for bugs. It's better to use WARN or ERR (the latter in the case of a programming or irrecoverable error, the former in the case of an error that can genuinely happen under some circumstances).
Rémi Bernon (@rbernon) commented about dlls/winebus.sys/bus_udev.c:
TRACE("udev device %s does not have devnode, ignoring\n", syspath);
goto out;
- }
- if (strcmp(action, "remove")) udev_add_device(dev, -1); else {
impl = find_device_from_devnode(udev_device_get_devnode(dev));
}impl = find_device_from_devnode(devnode); if (impl) bus_event_queue_device_removed(&event_queue, &impl->unix_device); else WARN("failed to find device for udev device %p\n", dev);
+out: udev_device_unref(dev);
```suggestion:-31+0 if (!syspath) WARN("udev device %p does not have syspath!\n", dev); else if (!action) WARN("event for udev device %s does not have any action!\n", syspath); else if (!devnode) { /* Pretty normal case, not all devices have associated * devnodes. For example root input devices do not, but * related/child mouse and event devices do. */ TRACE("udev device %s does not have devnode, ignoring\n", syspath); } else if (strcmp(action, "remove")) udev_add_device(dev, -1); else { impl = find_device_from_devnode(devnode); if (impl) bus_event_queue_device_removed(&event_queue, &impl->unix_device); else WARN("failed to find device for udev device %p\n", dev); }
udev_device_unref(dev); ```
Rémi Bernon (@rbernon) commented about dlls/winebus.sys/bus_udev.c:
struct base_device *impl; struct udev_device *dev; const char *action;
- const char *devnode;
- const char *syspath;
We usually group variable declarations in Wine.
```suggestion:-2+0 const char *action, devnode, syspath; ```
On Mon Mar 25 09:11:09 2024 +0000, Rémi Bernon wrote:
You're checking for the same condition in the next commit, so this one then becomes unnecessary. I'd also prefer to only check for this in the callers. As a side note, FIXME is supposed to be used for things that are not implemented yet, not for bugs. It's better to use WARN or ERR (the latter in the case of a programming or irrecoverable error, the former in the case of an error that can genuinely happen under some circumstances).
I thought that it would be good idea to add this log statement regardless of the current usage of `find_device_from_devnode()`, to make it "future-proof": whenever this function gets called with NULL argument, it's always an error. Had it been there, I would have found the issue a bit faster. Now the log contained only `warn:hid:bus_main_thread L"UDEV" bus wait returned status 0xc0000005`. The code `0xc0000005` of course hinted that an invalid pointer is being used, but it was not immediately clear where.
And, yes, ERR would be then better than FIXME. I think I just mimiced some existing error condition, the FIXME usage does not seem to be entirely consistent.
On Mon Mar 25 09:11:09 2024 +0000, Rémi Bernon wrote:
if (!syspath) WARN("udev device %p does not have syspath!\n", dev); else if (!action) WARN("event for udev device %s does not have any action!\n", syspath); else if (!devnode) { /* Pretty normal case, not all devices have associated * devnodes. For example root input devices do not, but * related/child mouse and event devices do. */ TRACE("udev device %s does not have devnode, ignoring\n", syspath); } else if (strcmp(action, "remove")) udev_add_device(dev, -1); else { impl = find_device_from_devnode(devnode); if (impl) bus_event_queue_device_removed(&event_queue, &impl->unix_device); else WARN("failed to find device for udev device %p\n", dev); } udev_device_unref(dev);
I think the `!syspath` case deserves `ERR`: all devices in sysfs tree always have unique paths. If udev abstraction somehow fails to convey it, then something is really broken and basically all bets are off regarding current device state.
I think `!action` case is similar; it means that something has happened in the device setup but udev has failed to tell us what. That case was logged as WARN and I didn't want to touch that because it was not necessary in the context of this MR.
Anyways, point taken, I'll get rid of "on error goto out" -pattern (which I personally tend to prefer).