Re: [PATCH 2/2] scsi: mpt3sas: add hwmon support

[Louis Sautier <sautier.louis@gmail.com>]

On 14/05/2026 03:02, sashiko-bot@kernel.org wrote:
> Could exposing this read to unprivileged users lead to excessive firmware
> requests and mutex contention?
> 
> Since the sysfs files are world-readable, any local user can read them in a
> tight loop. Every read directly calls mpt3sas_config_get_iounit_pg7(), which
> issues synchronous requests to the firmware over the PCIe bus and acquires
> the shared config_cmds.mutex:
> 
> _hwmon_read() ->
>     mpt3sas_config_get_iounit_pg7() ->
>         _config_request() ->
>             mutex_lock(&ioc->config_cmds.mutex)
> 
> Does this allow an unprivileged user to starve other storage subsystem
> components that rely on this mutex for administrative tasks or device
> discovery?
> 
> Could we implement a caching mechanism (for example, caching the readings
> for a short period using jiffies) to rate-limit these firmware requests?

My initial implementation had a 1-second jiffies-based cache; I
dropped it after seeing that drivers/nvme/host/hwmon.c follows the
same no-cache pattern.

The cover letter's contention figure came from a less direct
measurement and was too optimistic. I re-measured directly on
ioc->config_cmds.mutex, hammering the sysfs temperature file from
N concurrent unprivileged workers on a 9500-8i / SAS3816 while a
separate "administrative" reader runs in the foreground. The same
setup against the system's NVMe is included below for comparison:

hwmon: mpt3sas (/sys/class/hwmon/hwmon3/temp1_input)
nproc: 16

baseline (no concurrent readers): p50=14.6µs  p95=18.9µs

Foreground reader latency with N concurrent unprivileged hammers:

  N   agg r/s   p50 µs   p95 µs   max µs
  1     65244     38.0     60.2     60.8
  2     57722     57.0     60.1    120.5
  4     55026     90.8    115.5    152.9
  8     53688    207.2    247.9    300.1
 16     52188    345.8    390.3    444.8

hwmon: nvme (/sys/class/hwmon/hwmon2/temp1_input)
nproc: 16

baseline (no concurrent readers): p50=268.6µs  p95=289.4µs

Foreground reader latency with N concurrent unprivileged hammers:

  N   agg r/s   p50 µs   p95 µs   max µs
  1      3558    803.8    839.8   1008.3
  2      3549   1342.0   1443.6   1558.7
  4      3543   2154.8   2473.0   2756.6
  8      3518   4130.9   4459.6   4677.4
 16      3522   7394.6   8743.6   8804.3

Aggregate throughput is mutex-bound: every hwmon read takes
config_cmds.mutex, so contention is bounded. The worst
foreground p95 I observed was ~8.5 ms at N=nproc=96 on the
9305-24i (below).

Across the other two test boxes:
- 9305-24i / SAS3224 (nproc=96): mpt3sas baseline 31 µs, p95 at
  N=96 ~8.5 ms; same shape, ~2x slower per read than the more
  recent 9500-8i / SAS3816 above.
- 9211-4i / SAS2004: no mpt3sas sensors reported, no hwmon
  device registered, no contention surface (graceful-skip path
  in the cover letter).

If a maintainer thinks the cache should come back to bound this
independently of the attacker count, I am happy to re-add it.