Re: [PATCH] resource: fix lost wakeup when waiting for a muxed region

[Andrew Morton]

On Fri, 21 Aug 2026 14:08:17 +0000 DAI RENJIE via B4 Relay <devnull+drj19981414013.gmail.com@xxxxxxxxxx> wrote:

> From: DAI RENJIE <drj19981414013@xxxxxxxxx>
> 
> A task waiting for a muxed region can sleep forever in TASK_UNINTERRUPTIBLE
> even though the region it waits for is already free.
> __request_region_locked() queues itself on muxed_resource_wait and drops
> resource_lock before setting TASK_UNINTERRUPTIBLE, while __release_region()
> wakes the queue after dropping the same lock.  A wakeup landing in between
> finds TASK_RUNNING, does not match TASK_NORMAL and is discarded; callers
> hold a muxed region only across a bounded transaction, so no further
> release is coming.  The task is unkillable and its caller never returns.
> 
> The window is one store wide, but an interrupt is enough to hold the waiter
> in it, and the machine this was seen on runs PREEMPT_DYNAMIC in its
> voluntary default.  Since v6.11 spd5118 exports the DDR5 sensors of AMD
> boards through i2c-piix4, which takes a muxed region per SMBus transaction;
> a third of the in-tree users of request_muxed_region() are hwmon drivers,
> so reading a world-readable attribute is all an unprivileged user needs to
> drive the contention.  The blocked task sleeps holding the i2c adapter bus
> lock, and 27 more piled up behind it.
> 
> Fix it by setting the task state before dropping resource_lock, as
> prepare_to_wait() does: the releasing side needs resource_lock to unlink
> the resource, so it cannot reach the wakeup before the state is published.
> 
> Fixes: 8b6d043b7ee2 ("resource: shared I/O region support")

16 years ago.

> Cc: stable@xxxxxxxxxxxxxxx
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: DAI RENJIE <drj19981414013@xxxxxxxxx>
> ---
> Reproduced by building a kernel with the two orderings selectable at
> runtime and a 2ms delay inside the window.  Switching only that knob, a
> two-thread barriered reproducer loses the wakeup 200 times out of 200
> before the fix and 0 out of 200 after it; without the delay it goes 20000
> times through the wait path and loses none.
> ---
>  kernel/resource.c | 2 +-

Bjorn, please consider a MAINTAINERS entry?

> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -1350,8 +1350,8 @@ static int __request_region_locked(struct resource *res, struct resource *parent
>  		}
>  		if (conflict->flags & flags & IORESOURCE_MUXED) {
>  			add_wait_queue(&muxed_resource_wait, &wait);
> -			write_unlock(&resource_lock);
>  			set_current_state(TASK_UNINTERRUPTIBLE);
> +			write_unlock(&resource_lock);
>  			schedule();
>  			remove_wait_queue(&muxed_resource_wait, &wait);
>  			write_lock(&resource_lock);

Yup, that's a basic waitqueue usage bug.