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

[Bradley Morgan]

On 21 August 2026 19:34:57 BST, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
wrote:
>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?
>

I wouldn't mind stepping up, what do you reckon?

Me and Bjorn?

>> --- 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.  
>
>

Thanks!