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 E4A9D1A6806 for ; Tue, 28 Apr 2026 17:35:28 +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=1777397731; cv=none; b=etNrnxwY5ofsEWU9tmlbnkSN/XOSWX8RGA0H9Wlf/RXxHhZ8MVxrjjq1/qc7tNqo8TURlKC5a61sP/8luWM72mPJ2FYoUj0WWj3kmfQnCnUi1RaJgsgfud+IhVRDqQHThjveU04LBt61W2NhNpiW4yKDmmKQnYd5H8YsMIjyAEo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777397731; c=relaxed/simple; bh=wGAoYy8H5hWXiAjrB4sMsqog8DYconUn9/dZn6/J/Po=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UZiCDGqEPCNuOp72fJ0BlURKHZPtco2S/tNDDvm6eWsFPecS/HaKHyFjofBIeWwJKUdLhFhtKYjhAF/lDEbYwHFGrC463c567Xj2TSSTQe46bxX1nB5EP5+Ma1kktfrbD67eWPao06JY1OxE74C1g+3b5gT2gBVmRfXTv84sayw= 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=ZVRzWvJZ; 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="ZVRzWvJZ" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=0cGbnl9npcwFj2XoqujSrepjSfemgKeDVlZkdqcS6Ak=; b=ZVRzWvJZUY6ytOLR4NPOSnD6iO SChOtAaWgGb6yW5sghHQ7xJ39hLU/gwBo78463Naw0dqejQeDN1/8QJyBxawDYdeOsy9uzQ1DCvaO tcdv/bElKbUrkOLfHaKrbJjb/cQ8cRidtPqCHXoLm6vGq9LSSWUwnudsBR3MuIw3bdCCQWwoZOl+/ ZHoXs9spy/f5HESlpHX/rDWyJrwGZQru3waS4fC2mcldV6APcURc1PRGwsmyG6tOUHETrMFSrLaY0 /TCG3ayO4BLpiu4RY9Q6+YFvytdkYF38sDgVymFusOL9nMIIdRxVWpX7wWhA3bSzs12Iln25ijT1B DqmueTIg==; 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 desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHmLC-00000003ksF-1p0e; Tue, 28 Apr 2026 17:35:22 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 0D5A53008E2; Tue, 28 Apr 2026 19:35:21 +0200 (CEST) Date: Tue, 28 Apr 2026 19:35:21 +0200 From: Peter Zijlstra To: K Prateek Nayak Cc: Zhan Xusheng , Ingo Molnar , Vincent Guittot , Juri Lelli , linux-kernel@vger.kernel.org, Zhan Xusheng , Dietmar Eggemann , Valentin Schneider , Ben Segall , Steven Rostedt , Mel Gorman Subject: Re: [PATCH RESEND] sched/fair: Fix overflow in vruntime_eligible() Message-ID: <20260428173521.GK3126523@noisy.programming.kicks-ass.net> References: <20260415145742.10359-1-zhanxusheng@xiaomi.com> <20260428144951.121765-1-zhanxusheng@xiaomi.com> <57e94d7e-b8fb-49bc-a914-8a7401e43af3@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=us-ascii Content-Disposition: inline In-Reply-To: <57e94d7e-b8fb-49bc-a914-8a7401e43af3@amd.com> On Tue, Apr 28, 2026 at 09:47:11PM +0530, K Prateek Nayak wrote: > (+ scheduler folks) > > Hello Zhan, > > On 4/28/2026 8:19 PM, Zhan Xusheng wrote: > > After commit 556146ce5e94 ("sched/fair: Avoid overflow in > > enqueue_entity()"), place_entity() can shift cfs_rq->zero_vruntime > > towards a newly enqueued heavy entity. This can make (vruntime - > > zero_vruntime) very large for other entities and cause key * load in > > vruntime_eligible() to overflow s64, flipping the eligibility result. > > So the commit in question moves the zero_vruntime only when the > load > sum_weight. > > You seem to have found a case where the entity_key() is already large > enough that moving the zero_vruntime farther will make the eligibility > check overflow which we were hoping will not be the case. > > Do you have a reproducer that fails pick_eevdf() after introduction of > commit 556146ce5e94? Also, do you see any splats in the dmesg since we > have a defensive WARN_ON() to catch an overflow. Right, either a reproducer or a trace showing the values leading up to this are the absolute minimum you need to provide. That is, you need a definite description of how you got there, otherwise you cannot judge the solution is sound. Anyway... let me construct a worst case. So if you have this cgroup crap on, then you can have an entity of weight 2, and vlag should then be bounded by: (slice+TICK_NSEC) * NICE_0_LOAD, which is around 44 bits as per the comment on entity_key(). The other end is 100*NICE_0_LOAD, so lets wake that, then you get: {key, weight}[] := { puny: { (slice + TICK_NSEC) * NICE_0_LOAD, 2 }, max: { 0, 100*NICE_0_LOAD }, } The avg_vruntime() would end up being very close to 0 (which is zero_vruntime), so no real help making that more accurate. vruntime_eligible(puny) ends up with: avg = 2 * puny.key (+ 0) weight = 2 + 100 * NICE_0_LOAD avg >= puny.key * weight And that is: (slice + TICK_NSEC) * NICE_0_LOAD * NICE_0_LOAD * 100 and yes, I suppose that can exceed 64bit :-( Can someone double check that? I have a silly head-ache and could easily have made mistake. Not sure what the best solution is either. I think we can show avg cannot overflow, and if this multiplication overflows, then it must be larger, so perhaps the proposed patch is the best option. Dunno, need clear head :/