From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (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 12CF722F01 for ; Fri, 6 Feb 2026 16:03:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770393830; cv=none; b=G8378NppFXc3iDV7DAoxWusXN500NsY01ucKDbfOGxQDIWdsegINbrNrL16zznWV/1ZoBGfdOsW9BArXLQLbOM2fE46cpxIuO6MCYDVW3fT0vaiqBZj1pTuXEK5a/sz6GXpQlAdvJ9ibvcEH8G+OwMoa+dSFGFrlsIyP0U0wy8I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770393830; c=relaxed/simple; bh=TbrawEUsDjR3mpknDdoOmynywFBENFZE9bKHznZcqpE=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=bXutNFHV+vajqCgQV47l07qGip0VKHmEXUDOeZGAIyDYx4wgEuPsUUj8/BZKYTrtSldu/zyc7Utpr2ALGAvpw8axfI36oIYgA+/fyeZ7vLc7xcmhRPqISf4otVhZq11hmVkN+i4meQsd2yKepHIUU6W+csHragRi7PgL6rgfgFY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=etsalapatis.com; spf=pass smtp.mailfrom=etsalapatis.com; dkim=pass (2048-bit key) header.d=etsalapatis-com.20230601.gappssmtp.com header.i=@etsalapatis-com.20230601.gappssmtp.com header.b=UxGwkuEx; arc=none smtp.client-ip=209.85.222.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=etsalapatis.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=etsalapatis.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=etsalapatis-com.20230601.gappssmtp.com header.i=@etsalapatis-com.20230601.gappssmtp.com header.b="UxGwkuEx" Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-8c69ffb226eso121160985a.1 for ; Fri, 06 Feb 2026 08:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=etsalapatis-com.20230601.gappssmtp.com; s=20230601; t=1770393829; x=1770998629; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rEX6o9ONgTf923ExD7WYIz+0S7kT8YvB8ztho8evgKI=; b=UxGwkuExVRxk28XbFggKi2MaBUSS1HgWhHgVjrJI9befxbH+Siq1D0gZX34MSKDsCd /U/0KiVT5kvsSx8/elHHalecQyl5v9eq7Rt/ccmLXcw9aux5Ina+n9ZmD5OrTgVtz/Ub RFvyLdXCrtqW1EXv1KMQPRfAM/vGiaXJLHd4Dx4+O4sP50HPyvIjL3fiD43d4ez+6ZSJ k/YX3351GxxVvEuNUZk/GC3yT4HZY3+Ycct8yPLWBNfupa8n4xiF7/gLt7erKW6aujMw dVGjDh76DQvN5XLmrXRIJZbOi75EWITO7NC3QXPVTtM9+LKpCksOF3hdboSy3dXCtfq2 bVrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770393829; x=1770998629; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=rEX6o9ONgTf923ExD7WYIz+0S7kT8YvB8ztho8evgKI=; b=AGbILddMmI/CLoSsxBCCSb3f0f9q+jLpl7TN7t6rRijFuUteKHBWkwGwNXljPiEU/Q Gq/YjWqD2QCpMl5brkH8eYPDO7aFEC9okR7YuOvhwyn/DbRnnLI9fMTtFkAjx2xKQtYc L3looGvjYC+/FNgWndfguRu4FZkNIclk1ad/K2nMsMRMwe7+GuLRuLZbI8NksMbUaxPw JrFiLZtzaE90lvRND6GjPLwEjb6jbcZGPUu7d14da5pFyoNfpZ5o8aQ4sHz6usuCrznv xQyC0txsmcfpV1vXdIw3KgVb2fNm03EKzTSRNW9Fj31vgnGiEerU8YJupPqNX+WUm23S zzyQ== X-Forwarded-Encrypted: i=1; AJvYcCXfSUeGr3lXo/L906VtOekb6friwrK4S1NhQTOxlsO3j0y1ijX6ViGcyYNa65qVjxj2rzpQegbrx5PA6XM=@vger.kernel.org X-Gm-Message-State: AOJu0YwS1wGtnhTEerF34+ZW2rgtNN3crgF0b2ncz9VY+qQrXFII//OU naejh/BgViAsGztoIyBRqy2NE22lXKa+XEJa1VHuFzDPgMIm0oY5SqOSGA0ukjxKk4k= X-Gm-Gg: AZuq6aLlVaIUaVVglbh3tZzLUCh3jgXFdUxmmb0ty8LgA+sMgX1lWZ+zXTB14rCrtqT 9nMiYQWEQi/Spg63zDJLA62kNyM/l7BsR1qdbq717ZzRuhlLcTyUqdTiK50gwQkR+/lfmYsRi6m 2qzZseRDXe/h9eEfmRf/JIVXQrVWcphgsQhdbceg9zKgLBTAi6pyQ1PH1OGTYnatlQW2uoEd0Qm vmV+fzxg+iFKxhLWa5Y8feZc5PfcymDknK3vNGsIXgoyqASCxPsppwXFPA+xMznEtKbYaYujPlz 6YvDrlHN1jnIlXSmhSAHRUxdR2ICGHhVkbQ7ucmUC14K95FZWCeoPFYcDn5J89D/1CcqFfGwj65 AVCpBnzYybBurT606ReSXYGri70MkmxCUhBngrrLU3s8RyJjbPW/ZiQ3rSj9rsu43MW8egn+W0h scYQIPsHNP1Ug= X-Received: by 2002:a05:620a:4589:b0:8ca:3562:c0fd with SMTP id af79cd13be357-8caeef2fb03mr467050285a.5.1770393828689; Fri, 06 Feb 2026 08:03:48 -0800 (PST) Received: from localhost ([140.174.219.137]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8caf9fdf745sm182467185a.40.2026.02.06.08.03.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Feb 2026 08:03:48 -0800 (PST) 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 Date: Fri, 06 Feb 2026 11:03:47 -0500 Message-Id: Cc: , , , , , Subject: Re: [PATCH] tools/sched_ext: Improve BPF verifier arena detection workaround From: "Emil Tsalapatis" To: "Andrea Righi" , "zhidao su" X-Mailer: aerc 0.20.1 References: <20260206041808.170926-1-suzhidao@xiaomi.com> In-Reply-To: On Fri Feb 6, 2026 at 2:03 AM EST, Andrea Righi wrote: > Hi, > > On Fri, Feb 06, 2026 at 12:18:08PM +0800, zhidao su wrote: >> 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. >>=20 >> This addresses the side effect issue of the previous hack while >> preserving the essential functionality needed by the BPF verifier. >>=20 >> Signed-off-by: zhidao su > > Adding Emil in cc. > This still doesn't pass verification for me. @suzhidao is this working for = you? If so please let me know your setup so I can replicate this. I am running this on for-6.20. >> --- >> tools/sched_ext/scx_sdt.bpf.c | 18 +++++++++--------- >> 1 file changed, 9 insertions(+), 9 deletions(-) >>=20 >> 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 necessar= ily >> - * do so while still using pointers from that arena. Insert a bpf_print= k >> - * statement that triggers at most once to generate an LD.IMM instructi= on >> - * 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 variabl= e >> + * 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; > > Makes sense to me. > > If we want to be extra picky we can do something like this: > > volatile void *arena_ref =3D &arena; > (void)arena_ref; > > In this way we take the address of the arena map descriptor and store it > in a volatile void * variable, so the compiler can't optimize away and we > never read the content of the map descriptor, we only use its address. So= , > we're not reinterpreting the bytes of the struct as another type (no type > punning, no strict-aliasing violation). Even if it's probably just a > theoretical thing. > >> scx_arena_verify_once =3D true; >> } >> =20 >> --=20 >> 2.43.0 >>=20 > > Thanks, > -Andrea