Re: [PATCH] ipmi: ipmb: keep device alive across remove

[Chad Aldreda <ca@modelmiser.com>]

On Wed, 5 Aug 2026, Qing Ming wrote:
> Allocate ipmb_dev explicitly and hold a reference for each open file. Mark
> the device dead before deregistering the miscdevice, wake blocked readers,
> report a hangup to poll, and reject writes after removal.

Tested on mainline d48723711bae (v7.4-rc1-672), where this still applies,
in QEMU with KASAN, lockdep and kmemleak. There is no IPMB hardware
involved: a test-only I2C adapter module with target support binds the
driver and injects requests.

Without the patch, sysfs unbind, delete_device or removing the adapter
with /dev/ipmb-1 open gives slab-use-after-free reports on the next
poll(), read() and write(), and a read() or poll() blocked across an
unbind or delete_device is not woken.

With the patch there are no KASAN, lockdep or kmemleak reports. After
each of the three removals, poll() returns POLLERR|POLLHUP, write()
returns -ENODEV, read() with no requests queued returns -ENODEV, and a
blocked read() or poll() wakes up.

A blocking read() and poll() are still woken by a new request, the
request arrives intact, and an SMBus write completes. These also ran
clean: a write in flight across an unbind (the unbind waits for it, now
on file_mutex rather than the adapter bus lock, and the next write got
-ENODEV), an unbind and bind with the old file still open, closing with
three unread requests queued, probe failures from target registration
and from misc_register(), and 200 unbind/bind cycles against six
processes opening, polling, reading and writing while requests are
injected. The same stress run on the unpatched kernel produces KASAN
reports.

One side effect showed up in testing. ipmb_write() now holds file_mutex
across the transfer, and ipmb_open() takes file_mutex while misc_open()
holds misc_mtx, so a second open of the node during a slow transfer
stalls every misc device open in the system. With a 2 s transfer in the
stub, an open of /dev/cpu_dma_latency took about 1.6 s, against 0.00 s
without the patch. misc_deregister() also takes misc_mtx, and remove()
drops its reference after that, so for lifetime ipmb_open() seems not to
need file_mutex. An open racing removal could then still succeed, and
that file sees the same results as one opened just before removal. With
file_mutex replaced by READ_ONCE(ipmb_dev->dead) the open of
/dev/cpu_dma_latency took 0.00 s and the rest of the tests above stayed
clean. From reading the code only, poll() on the node also waits on
file_mutex during a transfer.

Not tested: real hardware, the i2c-protocol write path (only the SMBus
one ran), adapter removal with a write in flight, read() after removal
with requests still queued (from the code, these are still returned
while poll() reports only POLLERR|POLLHUP), and module unload (the
driver was built in).

The harness and this report were produced with an AI assistant (Claude
Opus 5.5), which also did the earlier runs, including the unpatched and
READ_ONCE() comparisons. I ran the final version on the patched kernel
myself and got the same results. The harness is available on request.

Tested-by: Chad Aldreda <ca@modelmiser.com>