From nobody Thu Apr 2 01:47:57 2026 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) (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 B53333EBF3E for ; Thu, 12 Feb 2026 08:01:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770883281; cv=none; b=HRICimd0YqqG76fjTiRi2s7NS9CEXqmRhJAaXwUhByGsyI5P44JHsZ4zQmz8bq1yguFwqig4pLU1eP1v1Bv/dDEEyRNBeRMWj4bHf6KwzCZmN77Ml1rHivejED3B5saq9PT52mia0tjL49/bYq81Niw8Xb6BpzeMdzxtRtHipsw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770883281; c=relaxed/simple; bh=+vzH530sTdqU5xEc/BGzzYyDHpW5+TaB9palnwIC/GY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ba+TU+ajQARZKFn9fKNKXS/0/ANli9JGsj7raUZr0uHmaAnsJTnKcTKXsO3TVyhzPTQUyVQA6lTY45yyl2EQ358WX4tG3MAjh3gP6X5m2XZvp0Kazy8/XbfXA5sqcsEENVpbyy110zhnJva4nBIF2PLYd0T2Bkye2DMWgFFyOmM= 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=Av9ao3xl; arc=none smtp.client-ip=209.85.214.172 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="Av9ao3xl" Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-2aaecf9c325so12131425ad.1 for ; Thu, 12 Feb 2026 00:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770883280; x=1771488080; 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=1MkyqrSYfmNUespOsUS7xNw2GSdROVuy7jYaCG5T90c=; b=Av9ao3xlaiTeYD5p1sgX/8cBJpWABJmhm1n9uNGWOkb4CGpqHg8FFWQpufX3qlznt+ YDU/aUpP4bT7sVHdnMhRkjxbNgg9mPR2aNo6ePKIVOQERsPG8EEwJyk9IItsl5MueaC4 MzgqaOrnkjHaj0W2kP37GIBR21KPuTuYzK2YCyZ6D3840clbN/Cb6CvvcNBw5ZzTFji4 atdbXBG+iC+xYp8FXBdozUffL2UZHNYUR8WEDSD//h5h45zOKWK9RvKW5Trc7NoRNkLU t3+nJpQqjvk0ddMxIiqh6g7RwOj6XPtFIRAJJyBMWsjcFLSR8qoCj/wgDUGFQ0eiL1X5 Q7zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770883280; x=1771488080; 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=1MkyqrSYfmNUespOsUS7xNw2GSdROVuy7jYaCG5T90c=; b=E7V0GTJIwo6mR5TBi2GFvbenEhEumx7NgZDZFV5hqZjCKRPamm0lErCyXHJK2dPkm2 jNNVxjD5nn2YFTRVD/EjXY1G+Z6WXZhzdlbIya7KDnTAg/XiRS2AQl72z+48xKjffFmP 78ZVz0mxjD0+uRP69ZbcIg+Nq13G15scfxeMXYkd5m0cj8wVcPRpqoWWnhuih6WI09fg VUVGb83q5pWXN2iSmcRehOl5Q/2M6ehl+DGS21izzczgBSRNhcJb83f1YgIFXhDaJEAW d2ah7SSicS3jc5EIr/lVt4rOzkoFyJ+0oa3IH0kykIGwUjAejYYAbRiOyzrVUZ7gC3Va s5/w== X-Forwarded-Encrypted: i=1; AJvYcCXNrFrPtJUjHdeEvl/vQHuiDxC02BYavj0VgTeoyzht/MVlEoQZvq6O/QjOmKxssT5ZAMVCbUEW6oHzeDY=@vger.kernel.org X-Gm-Message-State: AOJu0Yxjs65CPX32R2OHcQ7I6IwvHXULr5bhxIMqD+zkjJw2S1eDo69c dgpLjTG4/LJTFeoa3Y0tUMVjuSGCc5U6uz3Jz5fsD9tUtCP48us9GNnFQxMVVQ== X-Gm-Gg: AZuq6aJkVyxfe9PMSDgIfnVTgd1u0Cg0FL+n9YKpZuTtsuNjvLasinjFqR77oI8wYWd hVlqGlBb9XoiuLCc/oqLPgKozpzRTjspyjGxLIeD8e/xSxPzC7JLI5i51PtmxiVja6b3TFjZS59 /QxdbyTmZPNiPBfNrnXFgakNZufX5491iVujf+6WQv38zW6nkWjQHTbzuaXo9ZQUHTIQAAPB+hk Ilr4m9eCkAa24cCO7Qd5vA++UAJoIGNGtogfJJ3LcXfpxCbemc4VPoVIc+yY+/RvdhN9w4hGNNJ nwwDlhda/MkoCVCjfIpN0UEwfdPuoAMZ4rhicEP/B+9TWR5ee+8D7V0+2IGLWFxCQxc93lYlgUB JVVwl9YbpbsIrFf+sJOFtZcQk42riRNrFlzXWATSNe4PLrge9cvorpfVGUVNgYYaXXIafqZc3Wy IjqvQBHuCu0LsFHT5dgu90sj7utHiwNHiivHdtnAf6N+su1sKItWPcnZIiO6H1P/M2wayqVMTWl Kk= X-Received: by 2002:a17:902:ce02:b0:2aa:d327:beff with SMTP id d9443c01a7336-2ab3a635b09mr16938035ad.6.1770883279916; Thu, 12 Feb 2026 00:01:19 -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 d9443c01a7336-2ab2997c0fesm46034755ad.78.2026.02.12.00.01.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Feb 2026 00:01:19 -0800 (PST) From: zhidao su X-Google-Original-From: zhidao su To: Tejun Heo Cc: scx@lists.linux.dev, linux-kernel@vger.kernel.org, emil@etsalapatis.com, zhidao su Subject: [PATCH v2] tools/sched_ext: Improve BPF verifier arena detection workaround Date: Thu, 12 Feb 2026 16:00:58 +0800 Message-ID: <20260212080058.197924-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 inline assembly in scx_sdt scheduler's BPF verifier workaround to eliminate console output while ensuring the required LD.IMM instruction generation for arena detection. The BPF verifier associates arenas with programs by checking LD.IMM instruction operands for an arena map. The previous workaround using bpf_printk() achieved this but polluted the kernel log. A simple volatile access cast ((void)*(volatile void **)&arena) was found to be unreliable, as some compiler versions (e.g., Clang 18) optimized it away, resulting in missing LD.IMM instructions and verifier failures. This patch uses an empty inline assembly block with the arena address as an input constraint. This forces the compiler to generate an LD_IMM64 instruction for the arena address to satisfy the constraint, guaranteeing detection by the verifier without any runtime side effects. Signed-off-by: zhidao su --- v2: - Replaced volatile pointer cast with inline assembly to prevent compiler optimization (Clang) from eliminating the arena reference. - Updated commit message to reflect the change and the reason for it. 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..a8a611d1bc75 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 + * track arena usage. This is a robust alternative to bpf_printk 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); + /* + * Generate an LD.IMM instruction to the arena to help the verifier track= arena usage. This is a robust alternative to bpf_printk + * that produces no output. + */ + asm volatile ("" : : "r"(&arena)); scx_arena_verify_once =3D true; } =20 --=20 2.43.0