Re: [PATCH] hwmon: corsair-psu: fix and readd locking of command buffer

[Wilken Gottwalt <wilken.gottwalt@posteo.net>]

On Wed, 13 May 2026 07:05:41 -0700
Guenter Roeck <linux@roeck-us.net> wrote:

> On 5/13/26 06:43, Guenter Roeck wrote:
> > On 5/13/26 06:32, Wilken Gottwalt wrote:
> >> Fix removed locking mechanism. The locking mechanism does protect
> >> chained commands (set rail + get value), which are two separate calls
> >> to the low level access function. The hwmon (temps for example) and
> >> debugfs (uptimes for example) subsystem can trigger that chain of
> >> commands in parallel. The serialization in the hw monioring core alone
> >> is not enough.
> >>
> >> Fixes: 4207069edbf0 ("hwmon: (corsair-psu) Rely on subsystem locking")
> >> Signed-off-by: Wilken Gottwalt <wilken.gottwalt@posteo.net>
> > 
> > You'll need to explain why using the subsystem lock for debugfs
> > accesses does not work.
> > 
> 
> Clarifying: "Why using hwmon_lock() / hwmon_unlock() in the debugfs functions
> would be insufficient".

Yes, I understand that. You gave me an idea for a nice "hack" that would
demonstrate the problem. I will try it and look if it really happens.
Though, my thought process is, that debugfs and hwmon are two subsystems
which do not run in the same thread context. Each one of them would
trigger a call to corsairpsu_request(), one comming from a *_show callback
of the debufs and one comming from a hwmon_ops.read callback.
corsairpsu_request() often calls corsairpsu_usb_cmd() twice, one for
setting the rail, the second for reading a value of the rail. The mutex
protects that chain of calls. I really don't think that the debugfs
callbacks are serailized against the hwmon callbacks. I could create a
nice demonstration if I passthrough a little hint via function parameters
from where a callback is triggered. Do you understand, what I mean?

greetings,
Wilken