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 AD4E63ED11F for ; Thu, 2 Apr 2026 14:43:20 +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=1775141004; cv=none; b=VIum0aYPjZyoUBfbzkxme1T2ZDKLrOcGlh8+Rc2KY7XXvZFH1hlKCR6TvfU62gQiaplOBCx4NbOvEHdEhGgRiPsjoZ/A8OzDK9tBWG3BM6OCqSzYHv4uNs+gnz66XcBumUqwbDH/bvRo1XYZ7nqgOICiCdXVdwAtdr4TCwuBd0Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775141004; c=relaxed/simple; bh=j3CQZC4JHVMrR3FKP3DCRxYFTc1hYF58JUXIbf6ijQc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QyRvxdoSZEFkhknqhZrwCh1URNhjIqMg89w4dtSI2o5EPpF4DKHJyP8AG4cxttZyMWB1BOZwsLggfnDBehhipeuW1iC+1ceO3K8FeUV7LuyEg/149fQyd4RpuqExLC7ok9ffgSZ34/ZJx33eZRouKW1ihpUfSh09iSHcW+xNdho= 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=Ia5iwyJU; 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="Ia5iwyJU" 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=FDO971UcHNbuRNVt3hAPi/86+4icWoN5ORFynNYZEX8=; b=Ia5iwyJUlKDHmJjodoEnLf0LSv MSKQy4hy5FVoMCSGegOMyUYVRKmM+tbsATWCX18/4ZTKWXABgY4pWPnEHiMXh2SVD1bM4PSajHqN+ OgOP1/0cpqCjSlmVUhG8GbpB8mXQwp5XbU1qsxT+HFIsMguLOEUNRylBWFhb+iJ4M4wqrFM4mPgSQ Owyd3V5BTovXRLyLoAUTnpWOMxhUGOLLmMVwvPr9BGEZbAOi07fVi+58v4S+dMfKbMolLaX7jN+cn 9MYvWe7a1L6uKKwTO/a2S5DkNuratjhS3Z9FaCki7BXuKBot/Xf5yWHAFa5gtebtNQIxL8TwnV9J9 tO0m+CSA==; 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.98.2 #2 (Red Hat Linux)) id 1w8JGC-0000000CS5L-28z5; Thu, 02 Apr 2026 14:43:04 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 624313032D8; Thu, 02 Apr 2026 16:43:02 +0200 (CEST) Date: Thu, 2 Apr 2026 16:43:02 +0200 From: Peter Zijlstra To: John Stultz Cc: LKML , Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Mel Gorman , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , K Prateek Nayak , Thomas Gleixner , Daniel Lezcano , Suleiman Souhlal , kuyo chang , hupu , kernel-team@android.com Subject: Re: [PATCH v26 10/10] sched: Handle blocked-waiter migration (and return migration) Message-ID: <20260402144302.GU3738010@noisy.programming.kicks-ass.net> References: <20260324191337.1841376-1-jstultz@google.com> <20260324191337.1841376-11-jstultz@google.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=us-ascii Content-Disposition: inline In-Reply-To: <20260324191337.1841376-11-jstultz@google.com> So with that other issue cured, I'm back to staring at this thing.... On Tue, Mar 24, 2026 at 07:13:25PM +0000, John Stultz wrote: > +static bool proxy_deactivate(struct rq *rq, struct task_struct *donor) > { > unsigned long state = READ_ONCE(donor->__state); > > @@ -6598,17 +6610,140 @@ static bool __proxy_deactivate(struct rq *rq, struct task_struct *donor) > return try_to_block_task(rq, donor, &state, true); > } > > @@ -6741,7 +6900,17 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf) > /* Handle actions we need to do outside of the guard() scope */ > switch (action) { > case DEACTIVATE_DONOR: > - return proxy_deactivate(rq, donor); > + if (proxy_deactivate(rq, donor)) > + return NULL; > + /* If deactivate fails, force return */ > + p = donor; > + fallthrough; I was going to reply to Prateek's email and was going over the whole ttwu path because of that, and that got me looking at this. What happens here if donor is migrated; the current CPU no longer valid and we fail proxy_deactivate() because of a pending signal?