Re: [PATCH v2 1/4] HID: roccat: fix locking in roccat_connect() and roccat_disconnect()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] `roccat_report_event()` calls `mutex_lock()` while executing in atomic context.
--

commit 8cefeedf72bd07a9332b484733a5ce24fa525195
Author: Dmitry Antipov <dmantipov@yandex.ru>

HID: roccat: fix locking in roccat_connect() and roccat_disconnect()

This commit extends the critical section in roccat_connect() to avoid
exposing a partially initialized device in the devices list. It also
updates roccat_disconnect() to prevent racy access against
roccat_release().

> diff --git a/drivers/hid/hid-roccat.c b/drivers/hid/hid-roccat.c
> index 4f15eb9510396..5deb6da8d4f74 100644
> --- a/drivers/hid/hid-roccat.c
> +++ b/drivers/hid/hid-roccat.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but does roccat_report_event() call
mutex_lock() while executing in an atomic context?

The roccat_report_event() function is invoked by the driver's raw_event
handler, which is called synchronously by the HID core from the USB URB
completion handler. Since URB completion handlers execute in atomic context,
acquiring sleeping locks here triggers a 'scheduling while atomic' bug.

drivers/hid/hid-roccat.c:roccat_report_event() {
    ...
	mutex_lock(&device->readers_lock);
	mutex_lock(&device->cbuf_lock);
    ...
}

This appears to be reachable whenever a supported Roccat device sends
specific hardware events, such as when a user presses a profile switch
button on the mouse. Should this code use a spinlock or defer the work
instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914120240.1625442-1-dmantipov@yandex.ru?part=1