On Wed, Feb 25, 2026 at 10:35:06AM +0800, Shung-Hsi Yu wrote:
> Cc BPF mailing list and maintainers. Plus other in the referenced
> thread.
>
> Hi Harshit,
>
> On Tue, Feb 24, 2026 at 09:18:04AM -0300, Ricardo B. Marlière wrote:
> > On Tue Feb 24, 2026 at 4:53 AM -03, Harshit Mogalapalli wrote:
> > > On 24/02/26 13:08, Shung-Hsi Yu wrote:
> > >> This patchset backport the corresponding BPF selftests for commit
> > >> d946f3c98328 ("bpf: Check skb->transport_header is set in
> > >> bpf_skb_check_mtu"), which has already been included since 6.12.63.
> > >>
> > >> The BPF selftest added in commit 6cc73f35406c ("selftests/bpf: Test
> > >> bpf_skb_check_mtu(BPF_MTU_CHK_SEGS) when transport_header is not set")
> > >> additionally depends on network namespace support for BPF selftests
> > >> added by Bastien, otherwise the MTU in root networking namespace will be
> > >> set to 10, causing other BPF selftests to fail. Credit goes to Ricardo
> > >> Marlière for figuring out the dependency.
> > >
> > > Note:
> > > I have recently learnt that ideally we are supposed to run upstream
> > > latest kselftests on stable kernels as well. If a feature is not
> > > supported the kselftests are meant to be skipped.
>
> Thanks you for the bringing this up! This was also mentioned by Daniel
> (Borkmann), but my experience aligns with Ricardo's.
>
> > That is not true for BPF, from my (limited) experience.
>
> I do want running latest BPF selftests to work on stable thought, made
> some half-hearted attempts last April on trying bpf-next's BPF selftests
> (during 6.15 phase) run on stable/linux-6.14.y, but wasn't able to get
> pass the building phase.
>
> As far as I remember I ran into issue building bpf_testmod.ko (kernel
> module) of bpf-next against 6.14, and other similar issues related data
> structure or API changes. Pretty much the same set of problems we get
> when trying to build any driver in the latest kernel against stable
> kernels.
>
> Maybe it can work if BPF selftests that does not depends on
> bpf_testmod.ko, and build failures of BPF programs are simply ignored
> (not sure how feasible that is, probably would make Makefile much
> complicated), so for now I'm sticking with backporting BPF selftests to
> stable kernels.
If a kernel test module is involved, then yes, you are right, those
changes do need to be backported as mix/match of kernel modules to other
trees is not something that we support.
We only want this to be the rule for when we have purely userspace test
cases/code.
thanks,
greg k-h
