* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 10:45 [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs Alexander Mikhalitsyn
@ 2026-02-05 11:20 ` bot+bpf-ci
2026-02-05 11:27 ` Alexander Mikhalitsyn
2026-02-05 17:58 ` kernel test robot
` (4 subsequent siblings)
5 siblings, 1 reply; 18+ messages in thread
From: bot+bpf-ci @ 2026-02-05 11:20 UTC (permalink / raw)
To: alexander, ast
Cc: daniel, andrii, martin.lau, eddyz87, song, yonghong.song,
john.fastabend, kpsingh, sdf, haoluo, jolsa, jlayton, brauner,
bpf, linux-fsdevel, linux-kernel, aleksandr.mikhalitsyn, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]
> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 11:20 ` bot+bpf-ci
@ 2026-02-05 11:27 ` Alexander Mikhalitsyn
2026-02-05 12:38 ` Daniel Borkmann
2026-02-05 16:43 ` Alexei Starovoitov
0 siblings, 2 replies; 18+ messages in thread
From: Alexander Mikhalitsyn @ 2026-02-05 11:27 UTC (permalink / raw)
To: bot+bpf-ci
Cc: ast, daniel, andrii, martin.lau, eddyz87, song, yonghong.song,
john.fastabend, kpsingh, sdf, haoluo, jolsa, jlayton, brauner,
bpf, linux-fsdevel, linux-kernel, aleksandr.mikhalitsyn,
martin.lau, clm, ihor.solodrai
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.
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 11:27 ` Alexander Mikhalitsyn
@ 2026-02-05 12:38 ` Daniel Borkmann
2026-02-05 12:49 ` Alexander Mikhalitsyn
2026-02-05 16:43 ` Alexei Starovoitov
1 sibling, 1 reply; 18+ messages in thread
From: Daniel Borkmann @ 2026-02-05 12:38 UTC (permalink / raw)
To: Alexander Mikhalitsyn, bot+bpf-ci
Cc: ast, andrii, martin.lau, eddyz87, song, yonghong.song,
john.fastabend, kpsingh, sdf, haoluo, jolsa, jlayton, brauner,
bpf, linux-fsdevel, linux-kernel, aleksandr.mikhalitsyn,
martin.lau, clm, ihor.solodrai
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 12:38 ` Daniel Borkmann
@ 2026-02-05 12:49 ` Alexander Mikhalitsyn
2026-02-05 13:57 ` Alexander Mikhalitsyn
0 siblings, 1 reply; 18+ messages in thread
From: Alexander Mikhalitsyn @ 2026-02-05 12:49 UTC (permalink / raw)
To: Daniel Borkmann
Cc: bot+bpf-ci, ast, andrii, martin.lau, eddyz87, song, yonghong.song,
john.fastabend, kpsingh, sdf, haoluo, jolsa, jlayton, brauner,
bpf, linux-fsdevel, linux-kernel, aleksandr.mikhalitsyn,
martin.lau, clm, ihor.solodrai
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 12:49 ` Alexander Mikhalitsyn
@ 2026-02-05 13:57 ` Alexander Mikhalitsyn
0 siblings, 0 replies; 18+ messages in thread
From: Alexander Mikhalitsyn @ 2026-02-05 13:57 UTC (permalink / raw)
To: Daniel Borkmann
Cc: bot+bpf-ci, ast, andrii, martin.lau, eddyz87, song, yonghong.song,
john.fastabend, kpsingh, sdf, haoluo, jolsa, jlayton, brauner,
bpf, linux-fsdevel, linux-kernel, aleksandr.mikhalitsyn,
martin.lau, clm, ihor.solodrai
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 11:27 ` Alexander Mikhalitsyn
2026-02-05 12:38 ` Daniel Borkmann
@ 2026-02-05 16:43 ` Alexei Starovoitov
2026-02-05 17:17 ` Alexander Mikhalitsyn
1 sibling, 1 reply; 18+ messages in thread
From: Alexei Starovoitov @ 2026-02-05 16:43 UTC (permalink / raw)
To: Alexander Mikhalitsyn
Cc: bot+bpf-ci, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Jeff Layton,
Christian Brauner, bpf, Linux-Fsdevel, LKML,
aleksandr.mikhalitsyn, Martin KaFai Lau, Chris Mason,
Ihor Solodrai
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.
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 16:43 ` Alexei Starovoitov
@ 2026-02-05 17:17 ` Alexander Mikhalitsyn
2026-02-05 17:24 ` Alexei Starovoitov
0 siblings, 1 reply; 18+ messages in thread
From: Alexander Mikhalitsyn @ 2026-02-05 17:17 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: bot+bpf-ci, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Jeff Layton,
Christian Brauner, bpf, Linux-Fsdevel, LKML,
aleksandr.mikhalitsyn, Martin KaFai Lau, Chris Mason,
Ihor Solodrai
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 17:17 ` Alexander Mikhalitsyn
@ 2026-02-05 17:24 ` Alexei Starovoitov
0 siblings, 0 replies; 18+ messages in thread
From: Alexei Starovoitov @ 2026-02-05 17:24 UTC (permalink / raw)
To: Alexander Mikhalitsyn
Cc: bot+bpf-ci, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Jeff Layton,
Christian Brauner, bpf, Linux-Fsdevel, LKML,
aleksandr.mikhalitsyn, Martin KaFai Lau, Chris Mason,
Ihor Solodrai
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 10:45 [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs Alexander Mikhalitsyn
2026-02-05 11:20 ` bot+bpf-ci
@ 2026-02-05 17:58 ` kernel test robot
2026-02-05 21:06 ` kernel test robot
` (3 subsequent siblings)
5 siblings, 0 replies; 18+ messages in thread
From: kernel test robot @ 2026-02-05 17:58 UTC (permalink / raw)
To: Alexander Mikhalitsyn, ast
Cc: llvm, oe-kbuild-all, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Jeff Layton, Christian Brauner, bpf, linux-fsdevel, linux-kernel,
Alexander Mikhalitsyn
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 10:45 [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs Alexander Mikhalitsyn
2026-02-05 11:20 ` bot+bpf-ci
2026-02-05 17:58 ` kernel test robot
@ 2026-02-05 21:06 ` kernel test robot
2026-02-05 21:43 ` kernel test robot
` (2 subsequent siblings)
5 siblings, 0 replies; 18+ messages in thread
From: kernel test robot @ 2026-02-05 21:06 UTC (permalink / raw)
To: Alexander Mikhalitsyn, ast
Cc: oe-kbuild-all, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Jeff Layton,
Christian Brauner, bpf, linux-fsdevel, linux-kernel,
Alexander Mikhalitsyn
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 10:45 [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs Alexander Mikhalitsyn
` (2 preceding siblings ...)
2026-02-05 21:06 ` kernel test robot
@ 2026-02-05 21:43 ` kernel test robot
2026-02-05 22:58 ` kernel test robot
2026-02-06 12:32 ` Christian Brauner
5 siblings, 0 replies; 18+ messages in thread
From: kernel test robot @ 2026-02-05 21:43 UTC (permalink / raw)
To: Alexander Mikhalitsyn, ast
Cc: llvm, oe-kbuild-all, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Jeff Layton, Christian Brauner, bpf, linux-fsdevel, linux-kernel,
Alexander Mikhalitsyn
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 10:45 [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs Alexander Mikhalitsyn
` (3 preceding siblings ...)
2026-02-05 21:43 ` kernel test robot
@ 2026-02-05 22:58 ` kernel test robot
2026-02-06 12:32 ` Christian Brauner
5 siblings, 0 replies; 18+ messages in thread
From: kernel test robot @ 2026-02-05 22:58 UTC (permalink / raw)
To: Alexander Mikhalitsyn, ast
Cc: oe-kbuild-all, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Jeff Layton,
Christian Brauner, bpf, linux-fsdevel, linux-kernel,
Alexander Mikhalitsyn
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-05 10:45 [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs Alexander Mikhalitsyn
` (4 preceding siblings ...)
2026-02-05 22:58 ` kernel test robot
@ 2026-02-06 12:32 ` Christian Brauner
2026-02-06 12:42 ` Alexander Mikhalitsyn
2026-02-06 12:45 ` Jeff Layton
5 siblings, 2 replies; 18+ messages in thread
From: Christian Brauner @ 2026-02-06 12:32 UTC (permalink / raw)
To: Alexander Mikhalitsyn
Cc: ast, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Jeff Layton,
bpf, linux-fsdevel, linux-kernel, Alexander Mikhalitsyn
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?
> -
> 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
>
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-06 12:32 ` Christian Brauner
@ 2026-02-06 12:42 ` Alexander Mikhalitsyn
2026-02-06 12:44 ` Alexander Mikhalitsyn
2026-02-09 11:11 ` Christian Brauner
2026-02-06 12:45 ` Jeff Layton
1 sibling, 2 replies; 18+ messages in thread
From: Alexander Mikhalitsyn @ 2026-02-06 12:42 UTC (permalink / raw)
To: Christian Brauner
Cc: ast, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Jeff Layton,
bpf, linux-fsdevel, linux-kernel, Alexander Mikhalitsyn
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
> >
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-06 12:42 ` Alexander Mikhalitsyn
@ 2026-02-06 12:44 ` Alexander Mikhalitsyn
2026-02-09 11:11 ` Christian Brauner
1 sibling, 0 replies; 18+ messages in thread
From: Alexander Mikhalitsyn @ 2026-02-06 12:44 UTC (permalink / raw)
To: Christian Brauner
Cc: ast, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Jeff Layton,
bpf, linux-fsdevel, linux-kernel, Alexander Mikhalitsyn
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
> > >
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-06 12:42 ` Alexander Mikhalitsyn
2026-02-06 12:44 ` Alexander Mikhalitsyn
@ 2026-02-09 11:11 ` Christian Brauner
1 sibling, 0 replies; 18+ messages in thread
From: Christian Brauner @ 2026-02-09 11:11 UTC (permalink / raw)
To: Alexander Mikhalitsyn
Cc: ast, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Jeff Layton,
bpf, linux-fsdevel, linux-kernel, Alexander Mikhalitsyn
On Fri, Feb 06, 2026 at 01:42:17PM +0100, Alexander Mikhalitsyn wrote:
> 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.
Ah right, I remember. We require global CAP_SYS_ADMIN if FS_USERNS_MOUNT
isn't set. That's great. Thanks!
I can route Jeff's patch as fix since the original change technically
regressed nfs a while ago.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] bpf: use FS_USERNS_DELEGATABLE for bpffs
2026-02-06 12:32 ` Christian Brauner
2026-02-06 12:42 ` Alexander Mikhalitsyn
@ 2026-02-06 12:45 ` Jeff Layton
1 sibling, 0 replies; 18+ messages in thread
From: Jeff Layton @ 2026-02-06 12:45 UTC (permalink / raw)
To: Christian Brauner, Alexander Mikhalitsyn
Cc: ast, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, bpf,
linux-fsdevel, linux-kernel, Alexander Mikhalitsyn
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>
^ permalink raw reply [flat|nested] 18+ messages in thread