From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) (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 1939A7405A for ; Tue, 3 Feb 2026 03:54:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770090885; cv=none; b=lYs9qRvitj9dBr/9aCUq/s/VcbyGyykg2Crxj5N3AgmBK4vdeqLPxUodyDpSw4ZA6puhbGInW6Q667fZ0903Vj7LMBLbRNw2QZCLeyBIZoVQMwEDIdWBi/2GvdbY82avsvMhu/JtIXZ58kM07PKtCnEOuD5q58QsdpzphhZCcSE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770090885; c=relaxed/simple; bh=/WEK8p0oxOST6kYF5YAXc2M4vtj8l3lBWDyXrcaZmqo=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=qKAwIzR7izer6p2YqKlPVfwO8se3Rw8aZjlM0fj4KaIz2EdwXFwkOFNh9fkXhsfTDGVaakSE65/N2bHdCj3MUW6B/PXSlTxPQwMw/szj2biZCa8+mJ66aA8wEzQhepRbPdVTKCCUcQH1oFjK2UZVhsSE7ueotUe812+wOr8Y7Cg= 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=imJIDRot; arc=none smtp.client-ip=209.85.222.181 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="imJIDRot" Received: by mail-qk1-f181.google.com with SMTP id af79cd13be357-8c6b16bd040so580118385a.1 for ; Mon, 02 Feb 2026 19:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=etsalapatis-com.20230601.gappssmtp.com; s=20230601; t=1770090882; x=1770695682; darn=vger.kernel.org; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uIlRXifYi0mMeb+AiiEptACemMXQGCsICHEyW3xxh3Y=; b=imJIDRotc59NqeG4UHQNgNWW70jlBPTldIJ2pUKVQ35vISdjiJRvsLyq+iwFEVaZO5 44A9FwIY0UjivVOpGLIFghX68WfrGLLmHYQjC9jwJUQlSGC+WdtjNeSYMGmoltu1vDh6 BifWNtSnHLWVq9pK8r0fhdHlYf2IcLRtnwOn6/M6nCp88VZf28epDli80X0wBSbNh2+K LhKWcC+yJRsd543pXdOooAf3LDY3lO4Hoj0jgMlJXktOJglFePFKI+w5af2wQf+SxqPC 8TDPlIHLhSU2+UdRo9if2okuDzbBXAFr+1wYb5PfPiVD0AA2LjPe7s1Dav32w4JMMTZi e56A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770090882; x=1770695682; h=in-reply-to:references:subject:cc:to:from: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=uIlRXifYi0mMeb+AiiEptACemMXQGCsICHEyW3xxh3Y=; b=kufUJIFMW2I+CwC0vNI3kYR+bscL8jIx9pH0hPhMmvAm0Gf9jE7MZQ7RTDxAHH7yij Cx0FtTgDdlWMHyuu5T/nTmzRSHOXw8dtUz+BFUPpBHz26oH6RmZKEALc369M19cvIfjR YHofTbhEbn/bvzINU+ihlIDQ7dPTSPijPUQ5G++mlqf3W4nzTf62kE8Df2i9ABCDS0FG PfZd0FengeVbWJeyCZw8UT9LQWU6ITFpM1ldFSduP3Ykuf9xilRJy0H5HE+d61rqYjPW k7gmyyMAaPUWw3KK7BTA6nM42Wu8c/rCJlzPANEoWFg92lBjJdNDexXb9Xj4imzfXaFS 2Gfw== X-Forwarded-Encrypted: i=1; AJvYcCXx/W6esIUhGJ8M4Gcu0HZPQyKAVqIz+QnctuqwQ9eNUarVdL1DY+UUt/iR/k2oOofRRb9X5c48bBdgFDo=@vger.kernel.org X-Gm-Message-State: AOJu0YxfBT2+68KUTY+sUHY7XCnWuaJShHhm57mJrSeISecWofdMpjwE mDZrR//0C7cFjyBTXYHwgQQ5K6ivnOgtI0DnTUBy5BVwJoikzsIElSaKaRHKiSneD6RkpGj/e8g ZB5rr X-Gm-Gg: AZuq6aJRDDzu5Bs8VdXMndfVWX8kNKWg07gwsQy2FYUQAM5JPvIG0TuneP26jzkBrRT KWM+eDxs/vBNJ1stTfkUu1Qgv7fs3/VQ3AFoxzqPuWFK62BI81hec48enMbOhWWXfp2T1BFcqds 6e/Zu2ANOKZ/fyxUv2ftrT5u0nzdpYCV0tqN/dGQ9cBOtKDUkJeqmFlDZX5KfQ/UomMpz3OHJC+ nQeFQ95FhsgTmBBvprL6eGjjTyYYquiuo9zDQe+NHc+mz1ZZEBXZtQ4CSz69o/WN1Knk83K9Hje Pypjok2xQGQJ4D2JURW+xkqyHu7XlIllDuIZ2UWGFTHAuGp3QaXS91XNkAmg9SOfbbWshlZXmts 9XxnDpdNIXredki9SUnkXOv6plHK1sc6vKTa8W5/1ZKt8HgJUNc+M4BdeqYB9yVw6fm+A+mGfab f2cKq7Hl0xnDieZS0fxvaOqg== X-Received: by 2002:a05:620a:3195:b0:8c6:6e2b:ac1a with SMTP id af79cd13be357-8c9eb270195mr1635588985a.28.1770090881884; Mon, 02 Feb 2026 19:54:41 -0800 (PST) Received: from localhost ([140.174.219.137]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-894d36c85b9sm126061156d6.24.2026.02.02.19.54.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Feb 2026 19:54:41 -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: Mon, 02 Feb 2026 22:54:40 -0500 Message-Id: From: "Emil Tsalapatis" To: "zhidao su" , , , , Cc: , , Subject: Re: [PATCH] tools/sched_ext: Improve BPF verifier arena detection workaround X-Mailer: aerc 0.20.1 References: <20260203031954.915681-1-suzhidao@xiaomi.com> In-Reply-To: <20260203031954.915681-1-suzhidao@xiaomi.com> On Mon Feb 2, 2026 at 10:19 PM EST, zhidao su wrote: > Replace the BPF verifier workaround in scx_sdt scheduler with a more > elegant solution that: > > 1. Uses volatile cast instead of bpf_printk to generate LD.IMM instructio= n > without producing unnecessary output > 2. Adds conditional compilation based on __BPF_FEATURE_ADDR_SPACE_CAST > to eliminate the workaround entirely on modern toolchains > 3. Updates documentation to reflect broader compatibility concerns > > This eliminates the side effects of the previous hack while maintaining > compatibility across different kernel/BPF toolchain versions. > This code change is a bit of a non-sequitur (BPF_FEATURE_ADDR_SPACE_CAST is unrelated to the problem scx_arena_subprog_init solves) and causes=20 the scheduler to fail to load for me. Could you please explain the logic be= hind=20 this patch? Does it work on your machine and if so could you let me know wh= at toolchain and kernel you're using? > Signed-off-by: zhidao su > --- > tools/sched_ext/scx_sdt.bpf.c | 24 +++++++++++++++--------- > 1 file changed, 15 insertions(+), 9 deletions(-) > > diff --git a/tools/sched_ext/scx_sdt.bpf.c b/tools/sched_ext/scx_sdt.bpf.= c > index 31b09958e8d5..88ac3043a643 100644 > --- a/tools/sched_ext/scx_sdt.bpf.c > +++ b/tools/sched_ext/scx_sdt.bpf.c > @@ -64,15 +64,15 @@ 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 necessari= ly > - * do so while still using pointers from that arena. Insert a bpf_printk > - * statement that triggers at most once to generate an LD.IMM instructio= n > - * to access the arena and help the verifier. > + * Helper to ensure BPF verifier can track arena usage. > + * On older toolchains, the verifier may not automatically detect arena = usage > + * through indirect references, so we provide an explicit reference. > */ > +#if defined(__BPF_FEATURE_ADDR_SPACE_CAST) > +/* Modern toolchains don't need the workaround */ > +#define scx_arena_subprog_init() do { } while (0) > +#else > +/* Older toolchains need explicit arena reference for verifier */ > static volatile bool scx_arena_verify_once; > =20 > __hidden void scx_arena_subprog_init(void) > @@ -80,9 +80,15 @@ __hidden void scx_arena_subprog_init(void) > if (scx_arena_verify_once) > return; > =20 > - bpf_printk("%s: arena pointer %p", __func__, &arena); > + /* > + * Generate LD.IMM instruction to help BPF verifier track arena usage. > + * The volatile cast ensures the compiler doesn't optimize away the ref= erence. > + */ > + (void)*(volatile void **)&arena; > + > scx_arena_verify_once =3D true; > } > +#endif > =20 > =20 > private(LOCK) struct bpf_spin_lock alloc_lock;