From nobody Sun Feb 8 09:13:05 2026 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (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 F16133783DA for ; Tue, 3 Feb 2026 06:57:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.175 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770101875; cv=none; b=CnC6bLHvio5E7v+tEYgY2HvsPNnS2/P05cZS7tpF2Nhqwch4zsVnkwmkRngle3kWwLfb7rxXDrXU7mJ20FcOF9eFuSpdkqDstWUo4/t8OZeQEQLhE4CrNvi+XInMV/YXZIdzya+6pnaN/6oeID7xGucFb9NctZBvMhKHWtGugo0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770101875; c=relaxed/simple; bh=vvEVKjJCtQo4nmuo3z04CydsrpGhwrX7+I/UCM695oM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YRXGr3as/d4HCC/EcXxT/pH6ihQs6weYystvlJhN6ni1CidNGpLodZq+nSkP6OEcD5lIpHQNEguXkKPwQSGluGDGe3UuWG4oMhgi//PxGMr9uauCHZt+frKRwSjjFpFt74F4nwZaVyeeTcGOzt3Zw9PfK+BYvPFstrL4wtsLnXE= 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=WTuWdVns; arc=none smtp.client-ip=209.85.210.175 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="WTuWdVns" Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-81df6a302b1so5024357b3a.2 for ; Mon, 02 Feb 2026 22:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770101873; x=1770706673; 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=NtxdwbyBhJCjJN9Ud01S5+F/PCx615rL1edEy0Sb+qY=; b=WTuWdVnsGSWxQ/9VPCNab2hJR40pbylDlf3ZOmLWrM7NmL4KPnki5dpiW6uoRrG3si 1wUaETx/ri4k4KjWkyQN+ui2geX9Y7k4xmDId5xep9wblxS1pdDzAk+Q5y5XF1Hka8oe Q0PdG5o4wBG48fqvO+B0TXahilQ6/a2V/FfVL2fAPfyIWrPQMNHnXagqnm4zw6k5YbMR /o6otGib6LPSaWUKFdfeaXgUXzGXj6X333lGGXyek0Y9QzORDr5A7lWtVNvnAdd28hUn qZJSfTPrpXPickXyFnTiGiThxR3W5eYIrJS1vDqLiE1Dl5D6BODUwxaOzq63jBRBVNIk Y+/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770101873; x=1770706673; 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=NtxdwbyBhJCjJN9Ud01S5+F/PCx615rL1edEy0Sb+qY=; b=Y6IFgdjteFXlb9+A0aJY0kKsziqS81750iBAtz73f1nHmuXvRzQk6MGI0GTR5RAo9b NFLI1N6UO49+/ykrYQCAzu37rbMbXSxtHa8sz+32kHgNXsog6WKZSOWMCso7bL9LMYOu Ustf6XaezFkYBiwZRdFTl+NU54rB98ZaZ80UViz2h22WZQW6iFeE2+sXfL5AlUKLIqc+ B2f5Up7V+F8c3ppDtsFvYpTD5APVit0JJrL+1GdB5waS+yvAmK9mjdMPzrZFiB3k+rJ9 w5IB7px5r8aqIuj5C+5CAucfN4PQh/LmIhVSc4CpTSTM9Gvd7mtyT9GaApUQ9tkfHJI6 2nGA== X-Forwarded-Encrypted: i=1; AJvYcCXhPCrmVu9neO0HR8RQ+Xwf6DcnFcmCEKkgNTFeo1d679Iw+hJldvkwBNHciomfE363CgEROLT6tNLvoAQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzIuKybO3EJeeRDlrYgZSMuZ+46v1nPpvQ5DkTDqElOzkFBrZuz hn2TcRunl64ktlKy+wLO8JgXKlIzV4+AJdeRN9dcu0FhY5YUOWvtFBJW+7UFGr2p X-Gm-Gg: AZuq6aLlxSAO3wS4CBD0POneE3YMGOY6itT0MlZVFXf0IIYGR1gKRfZE6nWwv2FLDNX Uhj6cULFCBhZQbX/qfyBJC7buS2zBQVLW7w7yzJ6jafzW2gHuemqVOFza+ubwlQHRSfqVdITvp7 cFeT0iQTf5D1f/K6w6vDXF4Iik6Yxt15lAnNqyuoXiq9gWsw9vHOkeUgkV/LLIm0wAM67p3dHma +5qx9C2L4CeDxvO2ewd529yLjgTQRAtmLBDqV8wuf23Mj+yZq96emHVuhGx7eTzmR5b3EvkHj5C UvqblB8KQBR4LXRQ4yw4Yxny6IwU3p1DOYErw475PLemHjAxGeST5puqLlbBCveHXE9qjaVfveU gb5a1VYoZSe4dhj2BCjUXoEvHPT31RDO0TE/bLwecfa+LUwer7jOwHJoWfTs98v0tAaA3nXpm6/ MkwqkXfwi6XqPEeqwnNITYIS6hOfGUmE+/VWL14nrG/NQha3hxeBRy2FTpzzjnSFg= X-Received: by 2002:a05:6a00:1d9e:b0:7ef:3f4e:9176 with SMTP id d2e1a72fcca58-823ab72e98dmr15316865b3a.49.1770101873258; Mon, 02 Feb 2026 22:57:53 -0800 (PST) Received: from mi-HP-ProDesk-680-G6-PCI-Microtower-PC.mioffice.cn ([43.224.245.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82379c32944sm18114225b3a.57.2026.02.02.22.57.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 22:57:52 -0800 (PST) From: zhidao su X-Google-Original-From: zhidao su To: soolaugust@gmail.com Cc: arighi@nvidia.com, changwoo@igalia.com, emil@etsalapatis.com, linux-kernel@vger.kernel.org, sched-ext@lists.linux.dev, tj@kernel.org, void@manifault.com, zhidao su Subject: [PATCH] tools/sched_ext: Improve BPF verifier arena detection workaround Date: Tue, 3 Feb 2026 14:57:21 +0800 Message-ID: <20260203065721.46089-1-suzhidao@xiaomi.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Replace bpf_printk() with volatile access in scx_sdt scheduler's BPF verifier workaround to eliminate console output while maintaining the required LD.IMM instruction generation for arena detection. This addresses the side effect issue of the previous hack while preserving the essential functionality needed by the BPF verifier. Signed-off-by: zhidao su --- tools/sched_ext/scx_sdt.bpf.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/tools/sched_ext/scx_sdt.bpf.c b/tools/sched_ext/scx_sdt.bpf.c index 31b09958e8d5..13d3060c99ff 100644 --- a/tools/sched_ext/scx_sdt.bpf.c +++ b/tools/sched_ext/scx_sdt.bpf.c @@ -64,14 +64,10 @@ DEFINE_SDT_STAT(select_busy_cpu); static __u64 zero =3D 0; =20 /* - * XXX Hack to get the verifier to find the arena for sdt_exit_task. - * As of 6.12-rc5, The verifier associates arenas with programs by - * checking LD.IMM instruction operands for an arena and populating - * the program state with the first instance it finds. This requires - * accessing our global arena variable, but scx methods do not necessarily - * do so while still using pointers from that arena. Insert a bpf_printk - * statement that triggers at most once to generate an LD.IMM instruction - * to access the arena and help the verifier. + * Workaround to help BPF verifier track arena usage. + * The verifier needs to see an explicit reference to the arena variable + * to properly track arena memory usage. This generates the required + * LD.IMM instruction without producing unnecessary output. */ static volatile bool scx_arena_verify_once; =20 @@ -80,7 +76,11 @@ __hidden void scx_arena_subprog_init(void) if (scx_arena_verify_once) return; =20 - bpf_printk("%s: arena pointer %p", __func__, &arena); + /* + * Use volatile access to generate LD.IMM instruction without + * producing console output like bpf_printk does. + */ + (void)*(volatile void **)&arena; scx_arena_verify_once =3D true; } =20 --=20 2.43.0