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 96061472794 for ; Wed, 1 Apr 2026 16:14:27 +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=1775060070; cv=none; b=tvGF+Noz2Hb7VWRNm0jS2ePaklEaP/kgJrAaDDiPVG3n8Dg/FLwf3cJg/pDE7g4q3NRF+dxL0kkcS9T9WlhwdnACV5a83hbQyv6dKpkH5sgjKYcrYJ35+YTX13kf9l61PyZ77Pdc27n+Josq4av4/6WEGIWN0kFBpT9hAP6h7KI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775060070; c=relaxed/simple; bh=KesfdfKX8Mxe1IEE1xhe+okYfFYHLBNjJ5eTc00DlJw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=vD3vaZWjaNdt7qXOHbCmeT+jPQEuKigisbTFY2isHpjKBg5v4ep7DaFPSeD6qw9dRizcF4Sg7BraYCbhYTKEUr0DXnEQRA84HgdAD8VbhfH7c18WPGw8ax2FHWj9W0WOSG+5pMTJQBt/+kym9rWWwq6gCdzr7smaL5sjgWJXgys= 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=YAbyL7jv; 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="YAbyL7jv" 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=AHOI1Om6nP3fo7AreNqy5mHx/yUsD5k2IB1FZRWvUOE=; b=YAbyL7jvGZwYcQA/DI/gqgthdy D1q1v3Fq8C0KHMiiAUErrtWhdlPr+bTrA7hOCf/CofIdnHDhVdOyd6XhhZVrCyyjlvuT8c7w1eWzt qjY5WER66AS+AmBgFT4JbJLxgggjdwC+jweeCmznMI6iFtgvrTHSXtUy7+wfB9KilciJuwWzOkRln q0e3m2SLbzHP8ZcAhKNdmFdmLmoP3DG85Ex4v0VD/JepNk5IFwr91FIKdwLvlzq2GaJCg12pysPbk NEQqGwDbDgZ7yEhFaRtRAvA+Jqvqj/OQFW2CKYu53ONZX7S7E1Nqz2elNKFz5KSbSRc81IjNFdZ6A 3IIZ7yYg==; 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 1w7yCy-0000000Ag46-32Hh; Wed, 01 Apr 2026 16:14:21 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 1203A3032C7; Wed, 01 Apr 2026 18:14:19 +0200 (CEST) Date: Wed, 1 Apr 2026 18:14:19 +0200 From: Peter Zijlstra To: Vincent Guittot Cc: jstultz@google.com, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org, mingo@kernel.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com Subject: Re: [PATCH 2/2] sched/debug: Fix avg_vruntime() usage Message-ID: <20260401161419.GY2872@noisy.programming.kicks-ass.net> References: <20260401132019.057895815@infradead.org> <20260401132355.196370805@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 Wed, Apr 01, 2026 at 04:13:06PM +0200, Vincent Guittot wrote: > On Wed, 1 Apr 2026 at 15:24, Peter Zijlstra wrote: > > > > John reported that stress-ng-yield could make his machine unhappy and > > managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix > > zero_vruntime tracking"). > > > > The commit in question changes avg_vruntime() from a function that is > > a pure reader, to a function that updates variables. This turns an > > unlocked sched/debug usage of this function from a minor mistake into > > a data corruptor. > > > > Fixes: af4cf40470c2 ("sched/fair: Add cfs_rq::avg_vruntime") > > Fixes: b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking") > > Reported-by: John Stultz > > Signed-off-by: Peter Zijlstra (Intel) > > Tested-by: K Prateek Nayak > > Tested-by: John Stultz > > --- > > kernel/sched/debug.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > --- a/kernel/sched/debug.c > > +++ b/kernel/sched/debug.c > > @@ -902,6 +902,7 @@ static void print_rq(struct seq_file *m, > > void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq) > > { > > s64 left_vruntime = -1, zero_vruntime, right_vruntime = -1, left_deadline = -1, spread; > > + u64 avruntime; > > struct sched_entity *last, *first, *root; > > struct rq *rq = cpu_rq(cpu); > > unsigned long flags; > > @@ -925,6 +926,7 @@ void print_cfs_rq(struct seq_file *m, in > > if (last) > > right_vruntime = last->vruntime; > > zero_vruntime = cfs_rq->zero_vruntime; > > + avruntime = avg_vruntime(cfs_rq); > > Minor comment: > Do you intentionally save zero_vruntime before callling avg_vruntime() > which will update zero_vruntime ? > That could make sense to take a snapshot before being modified by > print_cfs_rq() but I'm afraid the call to debugfs will anyway trigger > an update before we save and display the value Intentional might be a big word, but yeah, printing the same value twice seemed pointless. This way you can at least see where it came from or something. > Reviewed-by: Vincent Guittot Thanks!