From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8678D337BAB for ; Fri, 21 Aug 2026 18:34:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787337299; cv=none; b=lH2GpOlNqGJN6tlb8krdVntDRSiOqHy8NMyC4M3Ibre26XbYeJNEUWMnrOsGNq5WzMMGf8xnhZ+88fIAqz1btzMlevCpYEGCF8hllo3ppq/WlPuehVRnTc8FK41LN6W9AvxXfVyR0bok3zjKrDspMRNeLymKrfaPye9LZdDlfMY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787337299; c=relaxed/simple; bh=rG/QuSwf9MK2ocaZ6f1ttGXICkCJH6CJ087bVDSLIG4=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=jJQDkla0rD+aNs2O3IQh4aTsA/mIxgGFukV9rXuIRbp5nvG+OpT5E9lN1g2nYf/etpqHdSsUVYERZDfvXJ41M6+cA8olQzkD4bqpw9S0PbJ09ol23EowSsgrr7CwCO78/by7lKKwsZigadgbzggPFgSrYQAZGtzBGDgD5Dx7XC8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=QvZCcPwb; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="QvZCcPwb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE1F71F000E9; Fri, 21 Aug 2026 18:34:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1787337298; bh=p7FpHGXGjs6xeSflVmg6HbSb5/C+jt37WbCCVF/R7uU=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=QvZCcPwb53q1TLcm6CuKoKeYG4x66lnLzmAI9BTjVu+zg8nMnQS5cQnku6V2+zIxX 2ZEYk/Fd3HY13OOmvF0/WpyGFpQ7QvC54OGVB3FB2RvQe05GCX1oh5GJtN0hF6QOET EHNMmcuyvcxiwNd48z51vSCXsWUad/JDGwJqL+Ss= Date: Fri, 21 Aug 2026 11:34:57 -0700 From: Andrew Morton To: drj19981414013@gmail.com Cc: DAI RENJIE via B4 Relay , Mark Brown , Kees Cook , linux-kernel@vger.kernel.org, Bjorn Helgaas , Bradley Morgan Subject: Re: [PATCH] resource: fix lost wakeup when waiting for a muxed region Message-Id: <20260821113457.8622c5d35c9aec838490b013@linux-foundation.org> In-Reply-To: <20260821-b4-resource-muxed-lost-wakeup-v1-1-37eb6473a76c@gmail.com> References: <20260821-b4-resource-muxed-lost-wakeup-v1-1-37eb6473a76c@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 21 Aug 2026 14:08:17 +0000 DAI RENJIE via B4 Relay wrote: > From: DAI RENJIE > > 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@vger.kernel.org > Assisted-by: Claude:claude-opus-5 > Signed-off-by: DAI RENJIE > --- > 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.