From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 6D3232E738D for ; Fri, 29 May 2026 09:34:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780047261; cv=none; b=SDnp+TrHDX6hnW8cvxxaJ0yA5Br62H9k05/lYBI2sni4JB6d+/aB8YAmCiSvHpBIG/DkdzIt0eHfSFwlq1vmqHMGOt+3U3NeJ7mpByEPD25UpM4p8PJc6gGfDa+Gj9sBoqYfNBpUBVglwiwuujaHLDzaU1EHnbyfX+2uSi83Kpo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780047261; c=relaxed/simple; bh=sT+q/5tdSNTPp3VSoSEBDnyLkHT2GZLP+/eD/EpEbqs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=D5wCQsbckodfZ7pzsL4EPzA3AbATowY1rOMmT5YwIznnra2mvhpjTHJ0cCypsSxs0RgVBmcjW4I6QMKtECdF3n2TKpuFHgJ/2bIqpWvXCWMQ0qQokDxzS7LuA9y+dObMoQr8YEGmN7gqBDGwi0R85Ye1k/H0GltXRHezONyZK0o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=ToqeIiX6; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ToqeIiX6" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=k9KMFxGB98K+JIDROWRIlul6sWrdlDrseWy/xeCENRI=; b=ToqeIiX6sPGNxpIGUf8nDK8xY5 4W1qMsrxWKDr+B3jtr0JTU8ij6k2x1rIknxbelFKtI7mJBp0KAwBdNw+TQQYnbUurXbVMgd8L3EYg /bD1RhHUGYj4UBTnPEo4YQfF2oS4bpcRkR4Lcjv8+C3VY7nGUbK8fbHXI3CxxuSfNWD/fAO+1Qh5Y Zf8+xDb/4NYT1zQ05FNMZa1Xb4Ycr1uqzUHjQi+MdD4tUesESnnA8rYwArjyJefTiLEjXnxrsDYak +cGOIp3oriSP59g9cpW2nsaLH0vAbWLhKnO6vx2N646K8AqX1KMMg7vaG2yAc5d1kBf0rrHCj9DiX j+tllMNA==; Received: from 2001-1c00-8d85-4b00-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:4b00:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wStbF-00000005s12-00g5; Fri, 29 May 2026 09:33:53 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 6352B301CEB; Fri, 29 May 2026 11:33:52 +0200 (CEST) Date: Fri, 29 May 2026 11:33:52 +0200 From: Peter Zijlstra To: K Prateek Nayak Cc: John Stultz , Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , Thomas Gleixner , Daniel Lezcano , Suleiman Souhlal , kuyo chang , hupu , linux-kernel@vger.kernel.org, Mike Galbraith Subject: Re: [PATCH 1/6] sched/proxy: Remove superfluous clear_task_blocked_in() Message-ID: <20260529093352.GA3144646@noisy.programming.kicks-ass.net> References: <20260526111609.433880331@infradead.org> <20260526113322.120970670@infradead.org> 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-Disposition: inline In-Reply-To: On Fri, May 29, 2026 at 12:15:09PM +0530, K Prateek Nayak wrote: > Hello John, > > On 5/29/2026 4:50 AM, John Stultz wrote: > > However, even with the fix I poined out, I've unfortunately hit races > > with the ww_mutex selftest at the point of this patch in the series. > > Basically between commit > > 1b89b7b21bf5 ("sched/proxy: Remove superfluous clear_task_blocked_in()") > > and > > a8be1edac5a1 ("sched/proxy: Remove PROXY_WAKING") > > > > I'm currently tracing down exactly why the race is cropping up but I > > believe the chunk removed in this case is avoiding cases where we end > > up getting PROXY_WAKING set on a TASK_RUNNING task. I'm struggling to make sense of this... > This seems to be the failure path: > > /* Task p*/ > mutex_lock(mutex) > ... try_to_wake_up(p) > schedule_preempt_disabled() ttwu_runnable() > __schedule() __task_rq_lock() /* Wins */ > rq_lock() /* Waits */ if (task_on_rq_queued(p)) > /* > * p->is_blocked is still not set! > * proxy_needs_return() bails out early. > */ > ttwu_do_wakeup() > p->__state = TASK_RUNNING; > __tsk_rq_unlock(); > ... > /* p->__state = TASK_RUNNING */ > prev_state = p->__state; > if (prev_state && ...) { > /* > * Skipped since task is > * already TASK_RUNNING > */ > } > > /* p->is_blocked = 0; p->blocked_on = PROXY_WAKING */ > next = p; > > /* Returns from schedule_preempt_disabled() > set_task_blocked_on(p, mutex) > > !!! p->blocked_on == PROXY_WAKING && p->blocked_on != mutex !!! > --- > > Also proxy_needs_return() bails out too early - a wakeup from signal > should still clear p->blocked_on even if p->wake_cpu is same as > task_cpu(). esp. in the context of the full patch set. There was no migration, therefore there is no need for a return migration. We're in mutex_lock(), any exit path will clear blocked_on. I don't see why we should have proxy_needs_return() unconditionally take that lock and clear blocked_on.