From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 16F33401A35 for ; Wed, 6 May 2026 09:59:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778061557; cv=none; b=XFATBXXQv3TN/ljn25vUmPFS5zquiyg6R0vbj+xI4Dm1uVmg7u/dPeRNk5sQI4Uh6VvysyX6eK/eGUpsZZp8mbOARliresMDYcgrQOYtTU1MA/KvnHsQd9tMKX8R8Pmbc9bmiemUGRInZD8MWilmwfLYkoTWsGepSWCTvWRD1z8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778061557; c=relaxed/simple; bh=I9FxDfaL+IcqesmFcg4TmE5+Rpo61viS6ENBQO4ueWQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Bw4+AMWx78n7VNYATFg86htHYGpilMShmWXRU2NdF0FaxT6XlH0ljp/7NSWWhg6+K0ahu6uwOLQtDPtQXRjXBK+sxzRJCeD6N7h70j56CIsfMj0CG9AicpgLJGnTHAaeyqRBf3fljbHOwkcVFG8kLgvWp8XS8JX8h4GMFbmjyf8= 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=Y/0DSAbS; arc=none smtp.client-ip=90.155.92.199 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="Y/0DSAbS" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=haoDuq7wsYpHufitk2UmdmkO4k156YAOXWnTBbj3Pfw=; b=Y/0DSAbScG8hJmCvy1blgLHUvR kvcxesu8dJFnTCAnHdJAL1/j7LEhzA/yu0jtsq+Pgti46YKqe+T8DkyBX3fZwgQZuTaqyMi/B8qgD /sZxkrF/z1yNm+3ZBrOSS9C2SV8eRh+rKl+Wum92hRIUqdrdyzuT8Dpe+7jj1oKMqcdasWEW9xNcb 3xwXs75sZE5qfqnX0N3jtv08NXGzRDZ+VJxBPusZW6rt0z6zLnu5Y255NxrxRLp6IIB6Tn322qI0G W/RYt0eyVeBmrTBtmp4GwKUxSe8cCKx7hp744MMDAdWwY6wDY1odxUKMQNh9smOpWA+yAgwgjCBun x205gaRg==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wKYwq-00000000tLX-3ybI; Wed, 06 May 2026 09:54:03 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 019E6302EC2; Wed, 06 May 2026 11:53:44 +0200 (CEST) Date: Wed, 6 May 2026 11:53:43 +0200 From: Peter Zijlstra To: John Stultz Cc: K Prateek Nayak , LKML , Vineeth Pillai , Sonam Sanju , Sean Christopherson , Kunwu Chan , Tejun Heo , Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , Thomas Gleixner , Daniel Lezcano , Suleiman Souhlal , kuyo chang , hupu , kernel-team@android.com Subject: Re: [PATCH v2 1/2] sched: proxy-exec: Close race causing workqueue work being delayed Message-ID: <20260506095343.GO1026330@noisy.programming.kicks-ass.net> References: <20260430215103.2978955-2-jstultz@google.com> <20260501132143.GC1026330@noisy.programming.kicks-ass.net> <63c830c3-fe6d-4822-81db-9fdd1597282e@amd.com> <20260501185900.GF1026330@noisy.programming.kicks-ass.net> <46ce422c-e796-4280-8165-b7c163928c68@amd.com> <7482ee30-5a50-41bb-9545-67cca5bd4cf2@amd.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, May 05, 2026 at 08:58:38PM -0700, John Stultz wrote: > On Mon, May 4, 2026 at 9:37 PM K Prateek Nayak wrote: > > On 5/5/2026 9:02 AM, John Stultz wrote: > > > but I'm not sure this is what Peter is looking for. > > > > Well this was just an option in case we don't want to backport super > > invasive changes. > > > > That said, we can easily do the following on top to fit what Peter > > originally suggested (although it'll probably require a bit effort to > > integrate with the sleeping owner bits): > > > ... > > > > Attached is full diff as proxy.diff on top of tip:sched/core for > > convenience. I'll let Peter comment further if he likes this > > approach or not :-) > > Thanks again for sharing this! > > So, I believe I've now got my full stack working ontop of your > proxy.diff file here (though as you pointed out there may be some > dragons left in the sleeping owner patch, but I *think* its ok). > > That said, I'm still not confident Peter won't still want his approach > (since it seems he's scheming to use is_blocked for se.sched_delayed > as well. That and I'm a bit shy after sinking so much time into the > last approach he didn't like :), so I've *also* worked up my full > series with Peter's approach (his change slots in after we get the > ttwu return migration in place). Sorry ;-) > So I'm totally fine if Peter agrees to take your version as a near > term fix for 7.1-rc. But if he'd rather not, I'll try to move forward > with his approach combined with the next chunk of patches. > > That said, trying to keep this full jenga tower of patches ontop of > both sides of your dualing banjos here is non-trivial, and I also do > need to get a solution for devices using the full stack on 6.18 and > 6.12 android trees very soon, which I'd like to keep closely aligned > with upstream. > > So having a clear direction to go forward would be helpful. :) > > Peter: Do you have guidance here? So yeah, I think you were feeling me right, I wanted to very much be able to use that is_blocked for sched_delayed too -- its always bothered me a little something to have to use se.sched_delayed in the core code. That said, I think Prateek agrees that once we get return migration into ttwu(), this all becomes simpler. And I think his insight that we can use is_blocked && !blocked_on to replace PROXY_WAKING is still valid on top of all that. Given this is all still very much an 'under construction' area, I don't think we need to rush fixes now. We can just slap 'BROKEN' on things and continue merging things for the next cycle.