Latest BPF selftests on stable kernels (was 'Re: [PATCH stable 6.12 0/5] Backport selftest for "bpf: Check skb->transport_header is set in bpf_skb_check_mtu"')

Latest BPF selftests on stable kernels (was 'Re: [PATCH stable 6.12 0/5] Backport selftest for "bpf: Check skb->transport_header is set in bpf_skb_check_mtu"')

[Shung-Hsi Yu]

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.

Thanks,
Shung-Hsi

> > https://lore.kernel.org/all/a45eaddb-9e17-4e82-8a78-a1d1f6e3d735@linuxfoundation.org/
> >
> > Thanks,
> > Harshit
[...]

Re: Latest BPF selftests on stable kernels (was 'Re: [PATCH stable 6.12 0/5] Backport selftest for "bpf: Check skb->transport_header is set in bpf_skb_check_mtu"')

[Greg KH]

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

Re: Latest BPF selftests on stable kernels (was 'Re: [PATCH stable 6.12 0/5] Backport selftest for "bpf: Check skb->transport_header is set in bpf_skb_check_mtu"')

[Shung-Hsi Yu]

On Wed, Feb 25, 2026 at 06:32:40AM -0800, Greg KH wrote:
> 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 for the confirmation regarding kernel test module.

For the record most BPF selftests probably doesn't depends on
bpf_testmod.ko, I don't think I have state that clear enough in the
exchange. So with some work running a subset of latest BPF selftest on
stable kernel may be possible, just that I have no idea the effort
required. 

Thanks,
Shung-Hsi