Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
From: Alexander Mikhalitsyn
Date: Thu Feb 05 2026 - 08:58:08 EST
Am Do., 5. Feb. 2026 um 13:49 Uhr schrieb Alexander Mikhalitsyn
<alexander@xxxxxxxxxxxxx>:
>
> Am Do., 5. Feb. 2026 um 13:38 Uhr schrieb Daniel Borkmann
> <daniel@xxxxxxxxxxxxx>:
> >
> > Hi Alexander,
> >
> > On 2/5/26 12:27 PM, Alexander Mikhalitsyn wrote:
> > > Am Do., 5. Feb. 2026 um 12:20 Uhr schrieb <bot+bpf-ci@xxxxxxxxxx>:
> > >>
> > >>> diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
> > >>> index 005ea3a2c..c350857b2 100644
> > >>
> > >> [ ... ]
> > >>
> > >>> @@ -1077,7 +1073,7 @@ static struct file_system_type bpf_fs_type = {
> > >>> .init_fs_context = bpf_init_fs_context,
> > >>> .parameters = bpf_fs_parameters,
> > >>> .kill_sb = bpf_kill_super,
> > >>> - .fs_flags = FS_USERNS_MOUNT,
> > >>> + .fs_flags = FS_USERNS_DELEGATABLE,
> > >>> };
> > >>
> > >> FS_USERNS_DELEGATABLE does not appear to be defined anywhere in the kernel
> > >> tree. A search of include/linux/fs.h shows only FS_USERNS_MOUNT is defined
> > >> (at line 2268), not FS_USERNS_DELEGATABLE.
> > >>
> > >> The commit message states this flag was "recently introduced", but it is not
> > >> present in this codebase. Will this cause a build failure due to an undefined
> > >> identifier?
> > >
> > > Yeah, this should be applied on top of
> > > https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h=vfs-7.0.misc&id=269c46e936f3b5f2b6b567ca124d5f5ea07a371c
> > > in vfs/vfs-7.0.misc I think.
>
> Hi Daniel,
>
> > If this goes via Christian's vfs tree, it would make sense at least to open a
> > test PR against https://github.com/kernel-patches/bpf to run this through the
> > BPF CI with the vfs branch + your patch on top to make sure the tests don't
> > break.
>
> Sure, https://github.com/kernel-patches/bpf/pull/10970#issue-3901410145
All looks good, except
x86_64 llvm-21 / test (sched_ext, false, 360) / sched_ext on x86_64 with llvm-21
which seems unrelated.
>
> Thanks for suggestion ;-)
>
> Kind regards,
> Alex
>
> >
> > Thanks,
> > Daniel