From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 269A239658A for ; Wed, 29 Apr 2026 07:31:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777447911; cv=none; b=IlCQxEqwbUX84+CeQfGGb3t6RHKqsefsVd46nMVLrPQl4fDtRsjnfdogHvvyYGTGPyKJrta80QHW5nglUHoh/nroGz9qqHC0xC4u/Hqe7rM3Ha7tO844dM2yodmhLKno+R/E7kuPQW3lSD0pJejz67y+XmdZFe6m/QJROe0Z2GM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777447911; c=relaxed/simple; bh=TVPnymGTzn80whoEMrWR4et+YJG+fR3M4wB1eijy+lY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Dfg67g0ejiKoNcuK3xeG+7TJZkiq4qDh/T93zEoFnAhIaWm/4ZYwJoOVueFvUWlgHpNJu/S3mDCFofjbgetpswQUQQXsPecvKMU1DObd9Qbf31x8WKrZcvS4ikA+i4Q+UGIx330qylgqAKpuX2zJbP4t1eYpjL+TcNq937dRpfY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=QzG8M2G8; arc=none smtp.client-ip=209.85.214.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QzG8M2G8" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2ab077e3f32so53568615ad.3 for ; Wed, 29 Apr 2026 00:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777447909; x=1778052709; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=MuZY0HyUEY2Yo5ba8NxgCYjvK2iairvwC+YZKLAvjKw=; b=QzG8M2G8WfapbNFqFjRAbclooJUhkyQSXrCSyK+myKKvfVxPttQMRTjXEbdKiaV8ZS LuUm7zcPd+1/DqOps48joqvup7M6TYRtthxr3pkq3NJ43MpGqyHrsCaijhrmPvxK0dQB 1MsVtisBbLrhKcZizG/VZ57HygiHfCQamKhHh/5dT5wJLeUHh9RJ78MT+/3vOzLPM0i5 peHFIS+idzpq/dtxg8IW4cJ/40o6kH61CBaFKM8RPWYOVburScCQ0CGuF4E55jdz0I+8 0bDAxBy2xv38gJvgBkI0THk9oj2qOCqCRAUVQhXnOmkUHRuuXSdyGTfFO5AZSHAotfGP AOYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777447909; x=1778052709; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=MuZY0HyUEY2Yo5ba8NxgCYjvK2iairvwC+YZKLAvjKw=; b=frmzIPcJXEHGFR+f8W0RLlaf6kY5OzDUe015s9V+I+U+3x+EydjksnDO1Bx3+j1Sp3 BGftGEovNwaqnaKIw4mulGTyZlzomqxa8bDaQ0zbwoP22zBHROxJPn32iUUUKqq8fBN9 7ZC1ei0uVr4zbV1TFefHFIQ0YTf9s7mKY7RZC5gNj+fGsRlQX32mue2eojdMgdlSo23U guE+LBScWfUwgFitbAINem/jev65pxZj4rSFbBWZPrLDsVf88lfmqDAXbukbbDOG2FgT DcqX7AlzVNzvdN9oXeqcriswTZFEkekJBd57gUCBEHJ6/P43oMq9+XNZ1UbLY9k19Y1N q5KA== X-Forwarded-Encrypted: i=1; AFNElJ82uB8bI8qWHX4n3Pg84eh7tdnAcBzQf5W+R6hSD66EfFeWvmYPj5WsiajZliYCR/p5x2rUXtMY/g/PNh4=@vger.kernel.org X-Gm-Message-State: AOJu0YwiE0Ebjpp7xA1l/FKd9i7dCpM+E3E2NazK0B6JyJKdhhnwDKHV GO02yA148YeUpZ9pI4BZNLxNS0XNyHYZoXY/PXG7XXK7d6d6gty5sP3o X-Gm-Gg: AeBDietNG76fr9JB1gQuhv5Se/URMuEe8zc4j3PLW4oSx8bcAT9+iZt5xSHbTqwd8Nh ArUEnbLG8Lu7/hwMdQnNpW0JPqLypaX3pOCqplKj14QL5uavU6gsSfBh4EwWeBbCBVn0WpXNQ/W eowCox0lo4Mo7NDVOw6wo3/se/+Ca2PhhB5R2T2XfH2uVyyXeRTt9q5cBbSPEYOT3ABVQiMRQNF e/JOaj83oVRyMq0+FVGBtsXjG7CXY2SVEZDWQRnfY8FFpTvRk/Tcy68+vm6LgVgG7hGLm5tQ71l zCBa73YHfIJmbHn9c89DVaRUjInNo4qjQSxu774HPKdg2EXlLJGPObcoEZEDh5r3FQp3F4A605q iuI2x5P1zHzydmBBvk3aHEgv+ZEpfjgBkOz/IAvZVQ7QZe8NATtVQ6NXhUEK8yfroi5kyJDHjwT qOacOx/0RZJdG5fVPMZ8EvXF0IjUnGegi4rGTQ4SNGnC0bILkkTQuwvBn+EA== X-Received: by 2002:a17:903:120f:b0:2b2:5515:661c with SMTP id d9443c01a7336-2b97c4ca26cmr66383935ad.31.1777447909292; Wed, 29 Apr 2026 00:31:49 -0700 (PDT) Received: from DESKTOP-MOQC9AF.mioffice.cn ([43.224.245.246]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b988772e6dsm12579675ad.16.2026.04.29.00.31.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2026 00:31:48 -0700 (PDT) From: Zhan Xusheng X-Google-Original-From: Zhan Xusheng To: K Prateek Nayak , Peter Zijlstra Cc: Ingo Molnar , Vincent Guittot , Juri Lelli , Dietmar Eggemann , Valentin Schneider , Ben Segall , Steven Rostedt , Mel Gorman , linux-kernel@vger.kernel.org, Zhan Xusheng Subject: Re: [PATCH RESEND] sched/fair: Fix overflow in vruntime_eligible() Date: Wed, 29 Apr 2026 15:31:41 +0800 Message-ID: <20260429073141.163323-1-zhanxusheng@xiaomi.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <4870ea19-78d4-44b2-9f18-14c3f8782726@amd.com> References: <4870ea19-78d4-44b2-9f18-14c3f8782726@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-Transfer-Encoding: 8bit Hi Prateek, Hi Peter, On Wed, 29 Apr 2026, K Prateek Nayak wrote: > ... the worst case right side would be: > 57671680000000 * load /* load = ((1 << 28) + 2) */ > and yes that goes beyond 64-bits at 15481123719086080000000. > ... > cfs_rq[0]:/ > .sum_w_vruntime : 109061637539400 (46 bits) > .sum_weight : 14 > .sum_shift : 0 > ... > without any splat so I'm not sure if there is something that prevents > a possible crash since a weight of 104857600 should have definitely > made that entity_key() overflow. Thanks for running this. On root's sum_weight being 14 despite cg1 having se->load.weight = 104857600: sum_weight is incremented by __enqueue_entity() only for entities currently on_rq on this cfs_rq. In your snapshot only cg0 (weight 14) is on_rq on root; cg1's group_se is not, so it does not contribute to root's sum_weight -- even though its se->load.weight is 104857600. If a workload kept both group_ses on_rq on root simultaneously, root's sum_weight would be 14 + 104857600. I have not constructed a workload that reliably holds both on_rq long enough to observe a sum_shift bump; that is outside what I can test in my current environment. On the upper-bound analysis, I re-checked both of your derivations: - Peter's (slice + TICK_NSEC) * NICE_0_LOAD * NICE_0_LOAD * 100 evaluates to ~1.87e20 with HZ=1000 and the 64-bit NICE_0_LOAD shift of 20, using 100 * NICE_0_LOAD as the heavy-side sum_weight. - Your refinement uses load = (1 << 28) + 2, giving ~1.55e22. (1 << 28) corresponds to scale_load(MAX_SHARES) and is reachable via sched_setattr / non-cgroup paths, but is not reachable through cpu.weight alone, which caps load.weight at ~1.05e8 via sched_weight_from_cgroup(CGROUP_WEIGHT_MAX). Both bounds cross S64_MAX. Working backwards from the smaller bound: with Peter's puny.key ~1.78e12, the multiplication crosses S64_MAX once load exceeds ~5.2e6, which a single cpu.weight=10000 cgroup clears on its own (load.weight ~1.05e8). So in cgroup-only setups the overflow threshold on load is low; the reason your snapshot stayed well under it appears to be the on_rq pattern, not the weight cap. To be upfront about the patch's basis: - I do not have a reproducer. - I have not observed the WARN_ON() in __enqueue_entity(). - The patch came from static inspection of vruntime_eligible() after 556146ce5e94. The observation is that key * load overflows specifically when *both* key is large (the entity being checked is far from v0) and load is large (an unrelated heavy entity is on_rq). The v0-move change keeps individual (v_i - v0) * w_i terms in sum_w_vruntime bounded, but key and load in vruntime_eligible() refer to different entities, so v0 placement cannot simultaneously control both factors. Given the bounds above, I think the defensive check is justified as hardening against a provable overflow, with the acknowledgement that I have not triggered it in practice. I'm happy to respin with a commit message built on these analyses if that would help. Thanks, Zhan Xusheng