kernel/bpf/inode.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
From: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
Instead of FS_USERNS_MOUNT we should use recently introduced
FS_USERNS_DELEGATABLE cause it better expresses what we
really want to get there. Filesystem should not be allowed
to be mounted by an unprivileged user, but at the same time
we want to have sb->s_user_ns to point to the container's
user namespace, at the same time superblock can only
be created if capable(CAP_SYS_ADMIN) check is successful.
Tested and no regressions noticed.
No functional change intended.
Link: https://lore.kernel.org/linux-fsdevel/6dd181bf9f6371339a6c31f58f582a9aac3bc36a.camel@kernel.org [1]
Fixes: 6fe01d3cbb92 ("bpf: Add BPF token delegation mount options to BPF FS")
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Eduard Zingerman <eddyz87@gmail.com>
Cc: Song Liu <song@kernel.org>
Cc: Yonghong Song <yonghong.song@linux.dev>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: KP Singh <kpsingh@kernel.org>
Cc: Stanislav Fomichev <sdf@fomichev.me>
Cc: Hao Luo <haoluo@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Jeff Layton <jlayton@kernel.org>
Cc: Christian Brauner <brauner@kernel.org>
Cc: bpf@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
- RWB-tag from Jeff [1]
Reviewed-by: Jeff Layton <jlayton@kernel.org>
---
kernel/bpf/inode.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
index 9f866a010dad..d8dfdc846bd0 100644
--- a/kernel/bpf/inode.c
+++ b/kernel/bpf/inode.c
@@ -1009,10 +1009,6 @@ static int bpf_fill_super(struct super_block *sb, struct fs_context *fc)
struct inode *inode;
int ret;
- /* Mounting an instance of BPF FS requires privileges */
- if (fc->user_ns != &init_user_ns && !capable(CAP_SYS_ADMIN))
- return -EPERM;
-
ret = simple_fill_super(sb, BPF_FS_MAGIC, bpf_rfiles);
if (ret)
return ret;
@@ -1085,7 +1081,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,
};
static int __init bpf_init(void)
--
2.47.3On Thu, Feb 05, 2026 at 11:45:41AM +0100, Alexander Mikhalitsyn wrote:
> From: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
>
> Instead of FS_USERNS_MOUNT we should use recently introduced
> FS_USERNS_DELEGATABLE cause it better expresses what we
> really want to get there. Filesystem should not be allowed
> to be mounted by an unprivileged user, but at the same time
> we want to have sb->s_user_ns to point to the container's
> user namespace, at the same time superblock can only
> be created if capable(CAP_SYS_ADMIN) check is successful.
>
> Tested and no regressions noticed.
>
> No functional change intended.
>
> Link: https://lore.kernel.org/linux-fsdevel/6dd181bf9f6371339a6c31f58f582a9aac3bc36a.camel@kernel.org [1]
> Fixes: 6fe01d3cbb92 ("bpf: Add BPF token delegation mount options to BPF FS")
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Andrii Nakryiko <andrii@kernel.org>
> Cc: Martin KaFai Lau <martin.lau@linux.dev>
> Cc: Eduard Zingerman <eddyz87@gmail.com>
> Cc: Song Liu <song@kernel.org>
> Cc: Yonghong Song <yonghong.song@linux.dev>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Cc: KP Singh <kpsingh@kernel.org>
> Cc: Stanislav Fomichev <sdf@fomichev.me>
> Cc: Hao Luo <haoluo@google.com>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Jeff Layton <jlayton@kernel.org>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: bpf@vger.kernel.org
> Cc: linux-fsdevel@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
> - RWB-tag from Jeff [1]
> Reviewed-by: Jeff Layton <jlayton@kernel.org>
> ---
> kernel/bpf/inode.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
> index 9f866a010dad..d8dfdc846bd0 100644
> --- a/kernel/bpf/inode.c
> +++ b/kernel/bpf/inode.c
> @@ -1009,10 +1009,6 @@ static int bpf_fill_super(struct super_block *sb, struct fs_context *fc)
> struct inode *inode;
> int ret;
>
> - /* Mounting an instance of BPF FS requires privileges */
> - if (fc->user_ns != &init_user_ns && !capable(CAP_SYS_ADMIN))
> - return -EPERM;
Jeff's patch does:
if (user_ns != &init_user_ns &&
!(fc->fs_type->fs_flags & (FS_USERNS_MOUNT | FS_USERNS_DELEGATABLE))) {
errorfc(fc, "VFS: Mounting from non-initial user namespace is not allowed");
return ERR_PTR(-EPERM);
}
IOW, it only restricts the ability to end up in bpf_fill_super() if
FS_USERNS_DELEGATABLE is set. You still need to perform the permission
check in bpf_fill_super() though otherwise anyone can mount bpffs in an
unprivileged container now.
So either Jeff's patch needs to be changed to require
capable(CAP_SYS_ADMIN) when FS_USERNS_DELEGATABLE is set (which makes
sense to me in general) or the check needs to remain n bpf_fill_super().
@Jeff do you require capable(CAP_SYS_ADMIN) from within nfs? I think you
somehow must because otherwise what prevents a container from mounting
arbitrary servers?
> -
> ret = simple_fill_super(sb, BPF_FS_MAGIC, bpf_rfiles);
> if (ret)
> return ret;
> @@ -1085,7 +1081,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,
> };
>
> static int __init bpf_init(void)
> --
> 2.47.3
>
On Fri, 2026-02-06 at 13:32 +0100, Christian Brauner wrote:
> On Thu, Feb 05, 2026 at 11:45:41AM +0100, Alexander Mikhalitsyn wrote:
> > From: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
> >
> > Instead of FS_USERNS_MOUNT we should use recently introduced
> > FS_USERNS_DELEGATABLE cause it better expresses what we
> > really want to get there. Filesystem should not be allowed
> > to be mounted by an unprivileged user, but at the same time
> > we want to have sb->s_user_ns to point to the container's
> > user namespace, at the same time superblock can only
> > be created if capable(CAP_SYS_ADMIN) check is successful.
> >
> > Tested and no regressions noticed.
> >
> > No functional change intended.
> >
> > Link: https://lore.kernel.org/linux-fsdevel/6dd181bf9f6371339a6c31f58f582a9aac3bc36a.camel@kernel.org [1]
> > Fixes: 6fe01d3cbb92 ("bpf: Add BPF token delegation mount options to BPF FS")
> > Cc: Alexei Starovoitov <ast@kernel.org>
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Cc: Andrii Nakryiko <andrii@kernel.org>
> > Cc: Martin KaFai Lau <martin.lau@linux.dev>
> > Cc: Eduard Zingerman <eddyz87@gmail.com>
> > Cc: Song Liu <song@kernel.org>
> > Cc: Yonghong Song <yonghong.song@linux.dev>
> > Cc: John Fastabend <john.fastabend@gmail.com>
> > Cc: KP Singh <kpsingh@kernel.org>
> > Cc: Stanislav Fomichev <sdf@fomichev.me>
> > Cc: Hao Luo <haoluo@google.com>
> > Cc: Jiri Olsa <jolsa@kernel.org>
> > Cc: Jeff Layton <jlayton@kernel.org>
> > Cc: Christian Brauner <brauner@kernel.org>
> > Cc: bpf@vger.kernel.org
> > Cc: linux-fsdevel@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
> > - RWB-tag from Jeff [1]
> > Reviewed-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > kernel/bpf/inode.c | 6 +-----
> > 1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
> > index 9f866a010dad..d8dfdc846bd0 100644
> > --- a/kernel/bpf/inode.c
> > +++ b/kernel/bpf/inode.c
> > @@ -1009,10 +1009,6 @@ static int bpf_fill_super(struct super_block *sb, struct fs_context *fc)
> > struct inode *inode;
> > int ret;
> >
> > - /* Mounting an instance of BPF FS requires privileges */
> > - if (fc->user_ns != &init_user_ns && !capable(CAP_SYS_ADMIN))
> > - return -EPERM;
>
> Jeff's patch does:
>
> if (user_ns != &init_user_ns &&
> !(fc->fs_type->fs_flags & (FS_USERNS_MOUNT | FS_USERNS_DELEGATABLE))) {
> errorfc(fc, "VFS: Mounting from non-initial user namespace is not allowed");
> return ERR_PTR(-EPERM);
> }
>
> IOW, it only restricts the ability to end up in bpf_fill_super() if
> FS_USERNS_DELEGATABLE is set. You still need to perform the permission
> check in bpf_fill_super() though otherwise anyone can mount bpffs in an
> unprivileged container now.
>
> So either Jeff's patch needs to be changed to require
> capable(CAP_SYS_ADMIN) when FS_USERNS_DELEGATABLE is set (which makes
> sense to me in general) or the check needs to remain n bpf_fill_super().
>
> @Jeff do you require capable(CAP_SYS_ADMIN) from within nfs? I think you
> somehow must because otherwise what prevents a container from mounting
> arbitrary servers?
>
As Alexander pointed out, the mount_capable() check will still fail
without CAP_SYS_ADMIN.
--
Jeff Layton <jlayton@kernel.org>
Am Fr., 6. Feb. 2026 um 13:33 Uhr schrieb Christian Brauner
<brauner@kernel.org>:
>
> On Thu, Feb 05, 2026 at 11:45:41AM +0100, Alexander Mikhalitsyn wrote:
> > From: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
> >
> > Instead of FS_USERNS_MOUNT we should use recently introduced
> > FS_USERNS_DELEGATABLE cause it better expresses what we
> > really want to get there. Filesystem should not be allowed
> > to be mounted by an unprivileged user, but at the same time
> > we want to have sb->s_user_ns to point to the container's
> > user namespace, at the same time superblock can only
> > be created if capable(CAP_SYS_ADMIN) check is successful.
> >
> > Tested and no regressions noticed.
> >
> > No functional change intended.
> >
> > Link: https://lore.kernel.org/linux-fsdevel/6dd181bf9f6371339a6c31f58f582a9aac3bc36a.camel@kernel.org [1]
> > Fixes: 6fe01d3cbb92 ("bpf: Add BPF token delegation mount options to BPF FS")
> > Cc: Alexei Starovoitov <ast@kernel.org>
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Cc: Andrii Nakryiko <andrii@kernel.org>
> > Cc: Martin KaFai Lau <martin.lau@linux.dev>
> > Cc: Eduard Zingerman <eddyz87@gmail.com>
> > Cc: Song Liu <song@kernel.org>
> > Cc: Yonghong Song <yonghong.song@linux.dev>
> > Cc: John Fastabend <john.fastabend@gmail.com>
> > Cc: KP Singh <kpsingh@kernel.org>
> > Cc: Stanislav Fomichev <sdf@fomichev.me>
> > Cc: Hao Luo <haoluo@google.com>
> > Cc: Jiri Olsa <jolsa@kernel.org>
> > Cc: Jeff Layton <jlayton@kernel.org>
> > Cc: Christian Brauner <brauner@kernel.org>
> > Cc: bpf@vger.kernel.org
> > Cc: linux-fsdevel@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
> > - RWB-tag from Jeff [1]
> > Reviewed-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > kernel/bpf/inode.c | 6 +-----
> > 1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
> > index 9f866a010dad..d8dfdc846bd0 100644
> > --- a/kernel/bpf/inode.c
> > +++ b/kernel/bpf/inode.c
> > @@ -1009,10 +1009,6 @@ static int bpf_fill_super(struct super_block *sb, struct fs_context *fc)
> > struct inode *inode;
> > int ret;
> >
> > - /* Mounting an instance of BPF FS requires privileges */
> > - if (fc->user_ns != &init_user_ns && !capable(CAP_SYS_ADMIN))
> > - return -EPERM;
>
> Jeff's patch does:
>
> if (user_ns != &init_user_ns &&
> !(fc->fs_type->fs_flags & (FS_USERNS_MOUNT | FS_USERNS_DELEGATABLE))) {
> errorfc(fc, "VFS: Mounting from non-initial user namespace is not allowed");
> return ERR_PTR(-EPERM);
> }
Hi Christian,
>
> IOW, it only restricts the ability to end up in bpf_fill_super() if
> FS_USERNS_DELEGATABLE is set. You still need to perform the permission
> check in bpf_fill_super() though otherwise anyone can mount bpffs in an
> unprivileged container now.
Yeah, this is what mount_capable(struct fs_context *fc) does. I'm removing
FS_USERNS_MOUNT so know it checks capable(CAP_SYS_ADMIN), instead of
ns_capable(fc->user_ns, CAP_SYS_ADMIN).
No functional changes here.
>
> So either Jeff's patch needs to be changed to require
> capable(CAP_SYS_ADMIN) when FS_USERNS_DELEGATABLE is set (which makes
> sense to me in general) or the check needs to remain n bpf_fill_super().
>
> @Jeff do you require capable(CAP_SYS_ADMIN) from within nfs? I think you
> somehow must because otherwise what prevents a container from mounting
> arbitrary servers?
Same point here. We have this check in mount_capable(struct fs_context
*fc) already.
Kind regards,
Alex
>
> > -
> > ret = simple_fill_super(sb, BPF_FS_MAGIC, bpf_rfiles);
> > if (ret)
> > return ret;
> > @@ -1085,7 +1081,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,
> > };
> >
> > static int __init bpf_init(void)
> > --
> > 2.47.3
> >
Am Fr., 6. Feb. 2026 um 13:42 Uhr schrieb Alexander Mikhalitsyn
<alexander@mihalicyn.com>:
>
> Am Fr., 6. Feb. 2026 um 13:33 Uhr schrieb Christian Brauner
> <brauner@kernel.org>:
> >
> > On Thu, Feb 05, 2026 at 11:45:41AM +0100, Alexander Mikhalitsyn wrote:
> > > From: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
> > >
> > > Instead of FS_USERNS_MOUNT we should use recently introduced
> > > FS_USERNS_DELEGATABLE cause it better expresses what we
> > > really want to get there. Filesystem should not be allowed
> > > to be mounted by an unprivileged user, but at the same time
> > > we want to have sb->s_user_ns to point to the container's
> > > user namespace, at the same time superblock can only
> > > be created if capable(CAP_SYS_ADMIN) check is successful.
> > >
> > > Tested and no regressions noticed.
> > >
> > > No functional change intended.
> > >
> > > Link: https://lore.kernel.org/linux-fsdevel/6dd181bf9f6371339a6c31f58f582a9aac3bc36a.camel@kernel.org [1]
> > > Fixes: 6fe01d3cbb92 ("bpf: Add BPF token delegation mount options to BPF FS")
> > > Cc: Alexei Starovoitov <ast@kernel.org>
> > > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > > Cc: Andrii Nakryiko <andrii@kernel.org>
> > > Cc: Martin KaFai Lau <martin.lau@linux.dev>
> > > Cc: Eduard Zingerman <eddyz87@gmail.com>
> > > Cc: Song Liu <song@kernel.org>
> > > Cc: Yonghong Song <yonghong.song@linux.dev>
> > > Cc: John Fastabend <john.fastabend@gmail.com>
> > > Cc: KP Singh <kpsingh@kernel.org>
> > > Cc: Stanislav Fomichev <sdf@fomichev.me>
> > > Cc: Hao Luo <haoluo@google.com>
> > > Cc: Jiri Olsa <jolsa@kernel.org>
> > > Cc: Jeff Layton <jlayton@kernel.org>
> > > Cc: Christian Brauner <brauner@kernel.org>
> > > Cc: bpf@vger.kernel.org
> > > Cc: linux-fsdevel@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
> > > - RWB-tag from Jeff [1]
> > > Reviewed-by: Jeff Layton <jlayton@kernel.org>
> > > ---
> > > kernel/bpf/inode.c | 6 +-----
> > > 1 file changed, 1 insertion(+), 5 deletions(-)
> > >
> > > diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
> > > index 9f866a010dad..d8dfdc846bd0 100644
> > > --- a/kernel/bpf/inode.c
> > > +++ b/kernel/bpf/inode.c
> > > @@ -1009,10 +1009,6 @@ static int bpf_fill_super(struct super_block *sb, struct fs_context *fc)
> > > struct inode *inode;
> > > int ret;
> > >
> > > - /* Mounting an instance of BPF FS requires privileges */
> > > - if (fc->user_ns != &init_user_ns && !capable(CAP_SYS_ADMIN))
> > > - return -EPERM;
> >
> > Jeff's patch does:
> >
> > if (user_ns != &init_user_ns &&
> > !(fc->fs_type->fs_flags & (FS_USERNS_MOUNT | FS_USERNS_DELEGATABLE))) {
> > errorfc(fc, "VFS: Mounting from non-initial user namespace is not allowed");
> > return ERR_PTR(-EPERM);
> > }
>
> Hi Christian,
>
> >
> > IOW, it only restricts the ability to end up in bpf_fill_super() if
> > FS_USERNS_DELEGATABLE is set. You still need to perform the permission
> > check in bpf_fill_super() though otherwise anyone can mount bpffs in an
> > unprivileged container now.
>
> Yeah, this is what mount_capable(struct fs_context *fc) does. I'm removing
> FS_USERNS_MOUNT so know it checks capable(CAP_SYS_ADMIN), instead of
> ns_capable(fc->user_ns, CAP_SYS_ADMIN).
>
> No functional changes here.
>
> >
> > So either Jeff's patch needs to be changed to require
> > capable(CAP_SYS_ADMIN) when FS_USERNS_DELEGATABLE is set (which makes
> > sense to me in general) or the check needs to remain n bpf_fill_super().
> >
> > @Jeff do you require capable(CAP_SYS_ADMIN) from within nfs? I think you
> > somehow must because otherwise what prevents a container from mounting
> > arbitrary servers?
>
> Same point here. We have this check in mount_capable(struct fs_context
> *fc) already.
And of course, I would never send a patch like this without testing it
for unprivileged
user and without ensuring that it doesn't cause any obvious privilege
escalation ;-)
>
> Kind regards,
> Alex
>
> >
> > > -
> > > ret = simple_fill_super(sb, BPF_FS_MAGIC, bpf_rfiles);
> > > if (ret)
> > > return ret;
> > > @@ -1085,7 +1081,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,
> > > };
> > >
> > > static int __init bpf_init(void)
> > > --
> > > 2.47.3
> > >
Hi Alexander,
kernel test robot noticed the following build errors:
[auto build test ERROR on bpf-next/net]
[also build test ERROR on bpf-next/master bpf/master brauner-vfs/vfs.all linus/master v6.19-rc8 next-20260205]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Alexander-Mikhalitsyn/bpf-use-FS_USERNS_DELEGATABLE-for-bpffs/20260205-184845
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git net
patch link: https://lore.kernel.org/r/20260205104541.171034-1-alexander%40mihalicyn.com
patch subject: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20260206/202602060650.PATlrMmc-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260206/202602060650.PATlrMmc-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602060650.PATlrMmc-lkp@intel.com/
All errors (new ones prefixed by >>):
>> kernel/bpf/inode.c:1084:27: error: 'FS_USERNS_DELEGATABLE' undeclared here (not in a function); did you mean 'CFTYPE_NS_DELEGATABLE'?
1084 | .fs_flags = FS_USERNS_DELEGATABLE,
| ^~~~~~~~~~~~~~~~~~~~~
| CFTYPE_NS_DELEGATABLE
vim +1084 kernel/bpf/inode.c
1077
1078 static struct file_system_type bpf_fs_type = {
1079 .owner = THIS_MODULE,
1080 .name = "bpf",
1081 .init_fs_context = bpf_init_fs_context,
1082 .parameters = bpf_fs_parameters,
1083 .kill_sb = bpf_kill_super,
> 1084 .fs_flags = FS_USERNS_DELEGATABLE,
1085 };
1086
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Hi Alexander,
kernel test robot noticed the following build errors:
[auto build test ERROR on bpf-next/net]
[also build test ERROR on bpf-next/master bpf/master brauner-vfs/vfs.all linus/master v6.16-rc1 next-20260205]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Alexander-Mikhalitsyn/bpf-use-FS_USERNS_DELEGATABLE-for-bpffs/20260205-184845
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git net
patch link: https://lore.kernel.org/r/20260205104541.171034-1-alexander%40mihalicyn.com
patch subject: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260205/202602052225.8AVOJuNQ-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260205/202602052225.8AVOJuNQ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602052225.8AVOJuNQ-lkp@intel.com/
All errors (new ones prefixed by >>):
>> kernel/bpf/inode.c:1084:14: error: use of undeclared identifier 'FS_USERNS_DELEGATABLE'; did you mean 'CFTYPE_NS_DELEGATABLE'?
1084 | .fs_flags = FS_USERNS_DELEGATABLE,
| ^~~~~~~~~~~~~~~~~~~~~
| CFTYPE_NS_DELEGATABLE
include/linux/cgroup-defs.h:137:2: note: 'CFTYPE_NS_DELEGATABLE' declared here
137 | CFTYPE_NS_DELEGATABLE = (1 << 2), /* writeable beyond delegation boundaries */
| ^
1 error generated.
vim +1084 kernel/bpf/inode.c
1077
1078 static struct file_system_type bpf_fs_type = {
1079 .owner = THIS_MODULE,
1080 .name = "bpf",
1081 .init_fs_context = bpf_init_fs_context,
1082 .parameters = bpf_fs_parameters,
1083 .kill_sb = bpf_kill_super,
> 1084 .fs_flags = FS_USERNS_DELEGATABLE,
1085 };
1086
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Hi Alexander,
kernel test robot noticed the following build errors:
[auto build test ERROR on bpf-next/net]
[also build test ERROR on bpf-next/master bpf/master brauner-vfs/vfs.all linus/master v6.19-rc8 next-20260205]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Alexander-Mikhalitsyn/bpf-use-FS_USERNS_DELEGATABLE-for-bpffs/20260205-184845
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git net
patch link: https://lore.kernel.org/r/20260205104541.171034-1-alexander%40mihalicyn.com
patch subject: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
config: x86_64-rhel-9.4-ltp (https://download.01.org/0day-ci/archive/20260205/202602052226.GPe8h4sA-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260205/202602052226.GPe8h4sA-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602052226.GPe8h4sA-lkp@intel.com/
All errors (new ones prefixed by >>):
>> kernel/bpf/inode.c:1084:27: error: 'FS_USERNS_DELEGATABLE' undeclared here (not in a function); did you mean 'CFTYPE_NS_DELEGATABLE'?
1084 | .fs_flags = FS_USERNS_DELEGATABLE,
| ^~~~~~~~~~~~~~~~~~~~~
| CFTYPE_NS_DELEGATABLE
vim +1084 kernel/bpf/inode.c
1077
1078 static struct file_system_type bpf_fs_type = {
1079 .owner = THIS_MODULE,
1080 .name = "bpf",
1081 .init_fs_context = bpf_init_fs_context,
1082 .parameters = bpf_fs_parameters,
1083 .kill_sb = bpf_kill_super,
> 1084 .fs_flags = FS_USERNS_DELEGATABLE,
1085 };
1086
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Hi Alexander,
kernel test robot noticed the following build errors:
[auto build test ERROR on bpf-next/net]
[also build test ERROR on bpf-next/master bpf/master brauner-vfs/vfs.all linus/master v6.19-rc8 next-20260205]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Alexander-Mikhalitsyn/bpf-use-FS_USERNS_DELEGATABLE-for-bpffs/20260205-184845
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git net
patch link: https://lore.kernel.org/r/20260205104541.171034-1-alexander%40mihalicyn.com
patch subject: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
config: i386-buildonly-randconfig-002-20260205 (https://download.01.org/0day-ci/archive/20260206/202602060128.qfggT7Pd-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260206/202602060128.qfggT7Pd-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602060128.qfggT7Pd-lkp@intel.com/
All errors (new ones prefixed by >>):
>> kernel/bpf/inode.c:1084:14: error: use of undeclared identifier 'FS_USERNS_DELEGATABLE'; did you mean 'CFTYPE_NS_DELEGATABLE'?
1084 | .fs_flags = FS_USERNS_DELEGATABLE,
| ^~~~~~~~~~~~~~~~~~~~~
| CFTYPE_NS_DELEGATABLE
include/linux/cgroup-defs.h:137:2: note: 'CFTYPE_NS_DELEGATABLE' declared here
137 | CFTYPE_NS_DELEGATABLE = (1 << 2), /* writeable beyond delegation boundaries */
| ^
1 error generated.
vim +1084 kernel/bpf/inode.c
1077
1078 static struct file_system_type bpf_fs_type = {
1079 .owner = THIS_MODULE,
1080 .name = "bpf",
1081 .init_fs_context = bpf_init_fs_context,
1082 .parameters = bpf_fs_parameters,
1083 .kill_sb = bpf_kill_super,
> 1084 .fs_flags = FS_USERNS_DELEGATABLE,
1085 };
1086
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
> 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?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21708956860
AI-authorship-score: low
AI-authorship-explanation: The commit follows standard kernel contribution patterns with natural language and proper references, suggesting human authorship, though the undefined flag error could indicate incomplete context.
issues-found: 1
issue-severity-score: high
issue-severity-explanation: The commit uses FS_USERNS_DELEGATABLE which is not defined in the kernel, causing a build failure that prevents kernel compilation.
Am Do., 5. Feb. 2026 um 12:20 Uhr schrieb <bot+bpf-ci@kernel.org>:
>
> > 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.
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21708956860
>
> AI-authorship-score: low
> AI-authorship-explanation: The commit follows standard kernel contribution patterns with natural language and proper references, suggesting human authorship, though the undefined flag error could indicate incomplete context.
> issues-found: 1
> issue-severity-score: high
> issue-severity-explanation: The commit uses FS_USERNS_DELEGATABLE which is not defined in the kernel, causing a build failure that prevents kernel compilation.
On Thu, Feb 5, 2026 at 3:27 AM Alexander Mikhalitsyn
<alexander@mihalicyn.com> wrote:
>
> Am Do., 5. Feb. 2026 um 12:20 Uhr schrieb <bot+bpf-ci@kernel.org>:
> >
> > > 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.
I think it's better to go via bpf-next this after the merge window
to make sure it goes through full CI run with AI review, etc.
Am Do., 5. Feb. 2026 um 17:43 Uhr schrieb Alexei Starovoitov
<alexei.starovoitov@gmail.com>:
>
> On Thu, Feb 5, 2026 at 3:27 AM Alexander Mikhalitsyn
> <alexander@mihalicyn.com> wrote:
> >
> > Am Do., 5. Feb. 2026 um 12:20 Uhr schrieb <bot+bpf-ci@kernel.org>:
> > >
> > > > 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 Alexei,
>
> I think it's better to go via bpf-next this after the merge window
> to make sure it goes through full CI run with AI review, etc.
Yeah, thanks to Daniel's suggestion it went through full CI already.
Please, see https://github.com/kernel-patches/bpf/pull/10970#issue-3901410145
Kind regards,
Alex
On Thu, Feb 5, 2026 at 9:18 AM Alexander Mikhalitsyn
<alexander@mihalicyn.com> wrote:
>
> Am Do., 5. Feb. 2026 um 17:43 Uhr schrieb Alexei Starovoitov
> <alexei.starovoitov@gmail.com>:
> >
> > On Thu, Feb 5, 2026 at 3:27 AM Alexander Mikhalitsyn
> > <alexander@mihalicyn.com> wrote:
> > >
> > > Am Do., 5. Feb. 2026 um 12:20 Uhr schrieb <bot+bpf-ci@kernel.org>:
> > > >
> > > > > 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 Alexei,
>
> >
> > I think it's better to go via bpf-next this after the merge window
> > to make sure it goes through full CI run with AI review, etc.
>
> Yeah, thanks to Daniel's suggestion it went through full CI already.
> Please, see https://github.com/kernel-patches/bpf/pull/10970#issue-3901410145
No. It did not. AI was skipped and all of netdev tests too.
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@kernel.org>:
>>
>>> 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.
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.
Thanks,
Daniel
Am Do., 5. Feb. 2026 um 13:38 Uhr schrieb Daniel Borkmann
<daniel@iogearbox.net>:
>
> 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@kernel.org>:
> >>
> >>> 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
Thanks for suggestion ;-)
Kind regards,
Alex
>
> Thanks,
> Daniel
Am Do., 5. Feb. 2026 um 13:49 Uhr schrieb Alexander Mikhalitsyn
<alexander@mihalicyn.com>:
>
> Am Do., 5. Feb. 2026 um 13:38 Uhr schrieb Daniel Borkmann
> <daniel@iogearbox.net>:
> >
> > 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@kernel.org>:
> > >>
> > >>> 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
© 2016 - 2026 Red Hat, Inc.