From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (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 D5DBA31A807 for ; Wed, 27 May 2026 14:17:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779891442; cv=none; b=EkBZO9NflDx8DTjvYAz9DCEaBRGn8YKU2YIeU6CL8bu/hr9xnOzUEAdKIS3anjt+OFyxpzbwXUckKfd02epQOnOSVpc+BiU52lKSrfMiPrZya+5QPTIJJLjoMJydVZe+4vTphGHgkY1To2XqNFwS6dMpRteTrMbr2ieiWLrOCXk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779891442; c=relaxed/simple; bh=GqkBkA0ux+YD7JioYqk+V1T0qYPcj0feX93g4HGLcqs=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=hanNl0yABCcLErhwxVhASxqP/X/h3fdizAyszWifwpcEn9dWA5+rPuSw0OYBoB3KSvwETKJcQaFxW1U0OmTNey9wb16UQRdHcl93Fsl8bPfTMWKxg/BxqmJzYv3X8jul19t7AOqZDh/zgloXWD3S6SoLfD/I1sFzzlaX2Bzg+tc= 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=VjSpN2H1; arc=none smtp.client-ip=209.85.210.42 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="VjSpN2H1" Received: by mail-ot1-f42.google.com with SMTP id 46e09a7af769-7e603d0ee0aso3264541a34.2 for ; Wed, 27 May 2026 07:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779891440; x=1780496240; 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=/jshKEkryiFgJPhBjTFxZ1Zd5Ycopkm0kpYznZELan4=; b=VjSpN2H1vYnAC0Pgzom7GVsB3XVz28KFpb9juBqVY8H8SMiy9Og3a1KX0BtN4fvugK C+BYhlkR1N4YghXdNTSSv4vBd3vVhc135+FDmthcczhfNSvsvymCWzqwkwSmpgBl8t51 UT+9lluGRrBGVJvHBXgHWlCeOyxoSvJsPnOuw7Bi8Sp2Sxm/d3k4rV2GpeGFGaH/YdvO XKOniFD7vJcsjqf8y4sgz0BSswAMeDa6148D7qlqFnK3qGr32k2bn/XtQKTru5JIHWUJ gJIGCyS713JO3zjaoJFg7s8h3VA5QKRgiH9mUPrG/eZGzFpWISOm8Ns5xZiuZ1ERhnLm odTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779891440; x=1780496240; 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=/jshKEkryiFgJPhBjTFxZ1Zd5Ycopkm0kpYznZELan4=; b=kg8ts4SscoxFy89vLXaeBXVRIGPWFGBLiEKgbVddghYLWZd+d09OtxuF8eracZA61m +ehyacr0snJ2CiyJpZk2p5vioTzcIDtcklMUPpX3N+CJVljv1fhuYZeTg0+8DDiEy1HU +v7QC2VtpIP8VZe+22CJAhZTQGhV6bboq5vNU0GXLO1WTTifIwq2SVzSxCjQfQbIMdTh lW2HFOKFqAoytkckOQOgQB6Cvug1nIz2p7X2PH3W8K6CFqK+d8iJAuxskcLU4G2T/yI5 mczoJptgjrdJAWi8IdNSkJnhtNnvUmjUzv8+drbL85UjJAaLs2TCVNf4JXz/diCBsjhn hZ/g== X-Forwarded-Encrypted: i=1; AFNElJ/khoRPocezrMREk4mhiopDwX1m+xDQUFKRoVu2nNdz+SGSczn7jIPLbTN7lyqBzU3wvEJU1RsM6D7Y2a0=@vger.kernel.org X-Gm-Message-State: AOJu0YwXQbyPCxA9GRWwlD0+uKhlvSyzguWU7gRIf7c9hZQTrdX94Y1x uSkUsa+klVncNWIZ0xMUKSzffpRew8N+JGbFxwfAZgtmqA1kcc0dJLJI X-Gm-Gg: Acq92OHHeiT7r12VUFVLT8Caztxm/tGKr5OEpDjels4oOUreRG1JWacEvXZi3PGyY2M 0Z+nFWDXoCiggJsyQnDfYYX0dOLwPRV0b392sQoGw2AD8H/JEmA6EZLVlkSyIb9irP4Zchg/nFQ 9R8C4y6Jo1Pyj8XU9mK4nCg8pGkmNIRnXKriJyT2KTLc7WLXrYTLYP8i1Wij8sGI/T0GWDgtskL 6ynjtjWq4RAubBkzzzdcyWhN2AArOPcLqg8FTRfFTAuK+SJHdjN23PP0/OOm/+iwHigJ5a8UJ6b e2sHPOD5a9APxWFJD5nx+2FMzDGax8YGJ7uxdX+mdXp/h6mjHpapypSbL35bSvKns8md6LVg2gp BFOFn4fWXE8NeqVAAaT/yYwRdEk2BgZJOpDaREL7VFzWcK6Ex1py9x+yLUauvp6FR0HBsCshhC2 P4P9P+poGwjGNt7gRmgy1rsakqkPGFBBoOCJYouPRdsfSehJ3vmnsy1j5WWBJP75o1DVBiFNpAh 5JmoFH40A9g7uDtYg== X-Received: by 2002:a05:6830:61c6:b0:7d7:f146:8738 with SMTP id 46e09a7af769-7e5fee5ec6cmr15466189a34.12.1779891439617; Wed, 27 May 2026 07:17:19 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:72::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e60667af4csm11732221a34.27.2026.05.27.07.17.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2026 07:17:19 -0700 (PDT) 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: Wed, 27 May 2026 07:17:17 -0700 Message-Id: Cc: , , , , , , Subject: Re: [PATCH v4 1/3] libbpf: load vmlinux BTF in gen_loader mode for struct_ops From: "Alexei Starovoitov" To: , , , , , , , , , , X-Mailer: aerc References: <20260527-libbpf-load-vmlinux-btf-in-gen_loader-mode-v4-1-27daa15487a9@google.com> <556048bab0cc9bda9a7dfe2d041308d35eed943c9295aeabd69d34414e2a9f4c@mail.kernel.org> In-Reply-To: <556048bab0cc9bda9a7dfe2d041308d35eed943c9295aeabd69d34414e2a9f4c@mail.kernel.org> On Wed May 27, 2026 at 6:39 AM PDT, bot+bpf-ci wrote: >> commit 29cedaf6d7d80a7e880a2e639f40fbafcbaf2e65 >> Author: Siddharth Nayyar >> Date: Wed May 27 12:52:57 2026 +0000 >> >> libbpf: load vmlinux BTF in gen_loader mode for struct_ops >> >> During light skeleton generation (`bpftool gen skeleton -L`), libbpf >> runs in gen_loader mode. Previously, `bpf_object__load_vmlinux_btf()= ` >> completely bypassed loading the kernel vmlinux BTF (`obj->btf_vmlinu= x`) >> if `gen_loader` was active. >> >> However, BPF `struct_ops` maps (such as `sched_ext_ops` maps) requir= e >> resolving the kernel-side struct type IDs and member sizes at >> compile/skeleton generation time. Without loading `btf_vmlinux`, lib= bpf >> cannot query the kernel BTF types, causing light skeleton generation= for >> `struct_ops` to fail or omit crucial type information. >> >> Fix this by modifying the check to load `btf_vmlinux` even in >> `gen_loader` mode if the BPF object contains `struct_ops` maps. >> >> Signed-off-by: Siddharth Nayyar > > Alexei Starovoitov requested in v3 review that a selftest be added to > prove struct_ops light skeletons work end-to-end: > > "The selftest is mandatory to prove that." > https://lore.kernel.org/bpf/CAADnVQ+AA_fmRw7uRwdL2TMyMbpWeebOQKb=3D0wvp= KiQR6Ee5xQ@mail.gmail.com/ > > This requirement has not been addressed in v4. Should a selftest be added > to demonstrate that struct_ops light skeletons work correctly with this > change? thanks bot. pw-bot: cr