HID: logitech-hidpp: WARNING in kernfs_remove_by_name_ns from hidpp_ff_destroy on USB disconnect (G923)

Summary

Disconnecting a Logitech G923 wheel reliably triggers a WARNING. hidpp_ff_destroy()
calls device_remove_file(&hid->dev, &dev_attr_range), but it runs as the ff->destroy
callback, i.e. from input_ff_destroy() → input_dev_release() — the final kobject
put. On the USB-disconnect path the HID device's sysfs directory has already been
removed by then, so removing range fails.

Kernel

6.16.12-drmexec7-valve24.5-1-neptune-616-drm-exec-gf253f5da553e
SteamOS 3.8 (holo), Lenovo Legion Go (Ryzen Z1 Extreme)

Device: Logitech G923 Racing Wheel for Xbox One and PC, 046d:c26e
(the wheel enumerates as 046d:c26d and is switched to c26e via usb_modeswitch,
after which the in-tree hid-logitech-hidpp binds it).

Backtrace

------------[ cut here ]------------
kernfs: can not remove 'range', no directory
WARNING: CPU: 7 PID: 3976 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xd5/0xe0
CPU: 7 UID: 1000 PID: 3976 Comm: wine_sechost_se Not tainted 6.16.12-...
RIP: 0010:kernfs_remove_by_name_ns+0xd5/0xe0
Call Trace:
 hidpp_ff_destroy+0x3c/0x50 [hid_logitech_hidpp]
 input_ff_destroy+0x2e/0x60
 input_dev_release+0x1d/0x60
 device_release+0x34/0x90
 kobject_put+0x8d/0x200
 evdev_free+0x2d/0x50
 device_release+0x34/0x90
 kobject_put+0x8d/0x200

Note Not tainted — no out-of-tree modules were loaded.

Reproducer

1. Attach a G923 (in c26e/PC mode) so hid-logitech-hidpp binds and logs
   "Force feedback support loaded".
2. Unplug it.
3. WARNING appears every time.

Relevant code (6.16)

static void hidpp_ff_destroy(struct ff_device *ff)
{
	struct hidpp_ff_private_data *data = ff->private;
	struct hid_device *hid = data->hidpp->hid_dev;

	hid_info(hid, "Unloading HID++ force feedback.\n");
	device_remove_file(&hid->dev, &dev_attr_range);   /* <-- too late here */
	destroy_workqueue(data->wq);
	kfree(data->effect_ids);
}
...
	ff->destroy = hidpp_ff_destroy;
	error = device_create_file(&(hidpp->hid_dev->dev), &dev_attr_range);

History

Commit "HID: logitech-hidpp: do all FF cleanup in hidpp_ff_destroy()" (5.2/5.3,
fixing ff21a635dd1a) deliberately moved the range removal into
hidpp_ff_destroy() to avoid a race. That fixed the module-unload ordering, but
hidpp_ff_destroy runs at input_dev_release, which on the disconnect path is
after hid_device_remove() has already torn down the parent sysfs directory —
so the file removal now warns instead.

Possible fix

Remove the range attribute in the driver's remove() (or in a
hid_hw_stop()-adjacent path) rather than from the ff->destroy callback, or
guard the removal on the parent still being registered.

Severity

The WARNING itself is not fatal, but on this machine repeated
disconnect/reconnect cycles of the wheel end in a hard lock-up (no panic, empty
/sys/fs/pstore, journal cut mid-line). I cannot prove the two are the same
root cause, and I am not claiming they are — but the teardown path is
demonstrably inconsistent, and it is the only kernel warning present.

Also observed on disconnect

logitech-hidpp-device 0003:046D:C26E.000B: Failed to send command to device!   (x6)

i.e. the driver continues issuing HID++ commands to an already-removed device.

Start with the driver entry points named in the report: hidpp_ff_destroy(), the driver's remove() path, and hid_hw_stop(). Reproduce the G923 disconnect on the stated kernel and trace teardown ordering; done means repeated disconnects no longer emit the kernfs range warning or issue HID++ commands after removal.