fms-extensions and bpf

fms-extensions and bpf

[Alexei Starovoitov]

Hi All,

The kernel is now built with -fms-extensions and it is
using them in various places.
To stop-the-bleed and let selftests/bpf pass
I applied the short term fix:

https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=835a50753579aa8368a08fca307e638723207768

Long term I think we can try to teach bpftool
to emit __diag_push("-fms-extensions"..)
at the top of vmlinux.h.
Not sure whether it's working though.

Also,
Quentin,
pls think of a way to silence warns during bpftool build,
which is now noisy due to:
In file included from skeleton/pid_iter.bpf.c:3:
.../tools/testing/selftests/bpf/tools/build/bpftool/vmlinux.h:64057:3:
warning: declaration does not declare anything
[-Wmissing-declarations]
 64057 |                 struct ns_tree;
       |                 ^~~~~~~~~~~~~~

Re: fms-extensions and bpf

[Quentin Monnet]

2025-12-03 20:29 UTC-0800 ~ Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Hi All,
> 
> The kernel is now built with -fms-extensions and it is

[...]

> Quentin,
> pls think of a way to silence warns during bpftool build,
> which is now noisy due to:
> In file included from skeleton/pid_iter.bpf.c:3:
> .../tools/testing/selftests/bpf/tools/build/bpftool/vmlinux.h:64057:3:
> warning: declaration does not declare anything
> [-Wmissing-declarations]
>  64057 |                 struct ns_tree;
>        |                 ^~~~~~~~~~~~~~
> 

I see them too. We can trivially turn off these warnings when building
the BPF programs:

    diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
    index 586d1b2595d1..ad4e10cb59d5 100644
    --- a/tools/bpf/bpftool/Makefile
    +++ b/tools/bpf/bpftool/Makefile
    @@ -224,6 +224,7 @@ endif
     
     $(OUTPUT)%.bpf.o: skeleton/%.bpf.c $(OUTPUT)vmlinux.h $(LIBBPF_BOOTSTRAP)
            $(QUIET_CLANG)$(CLANG) \
    +               -Wno-missing-declarations \
                    -I$(or $(OUTPUT),.) \
                    -I$(srctree)/tools/include/uapi/ \
                    -I$(LIBBPF_BOOTSTRAP_INCLUDE) \

Probably better, we can tell clang to use the MS extensions so that it
doesn't consider these declarations as missing:

    diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
    index 586d1b2595d1..a8d5b32f1c6b 100644
    --- a/tools/bpf/bpftool/Makefile
    +++ b/tools/bpf/bpftool/Makefile
    @@ -224,6 +224,8 @@ endif
     
     $(OUTPUT)%.bpf.o: skeleton/%.bpf.c $(OUTPUT)vmlinux.h $(LIBBPF_BOOTSTRAP)
            $(QUIET_CLANG)$(CLANG) \
    +               -fms-extensions \
    +               -Wno-microsoft-anon-tag \
                    -I$(or $(OUTPUT),.) \
                    -I$(srctree)/tools/include/uapi/ \
                    -I$(LIBBPF_BOOTSTRAP_INCLUDE) \

I'm happy to repost the latter as a patch, if it seems good to you.

Quentin

Re: fms-extensions and bpf

[Song Liu]

On Wed, Dec 3, 2025 at 8:30 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> Hi All,
>
> The kernel is now built with -fms-extensions and it is
> using them in various places.
> To stop-the-bleed and let selftests/bpf pass
> I applied the short term fix:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=835a50753579aa8368a08fca307e638723207768
>
> Long term I think we can try to teach bpftool
> to emit __diag_push("-fms-extensions"..)
> at the top of vmlinux.h.
> Not sure whether it's working though.

Something like the following works for me. But I am not sure
whether it is the best solution.

Thanks,
Song

diff --git i/tools/bpf/bpftool/btf.c w/tools/bpf/bpftool/btf.c
index 946612029dee..606886b79805 100644
--- i/tools/bpf/bpftool/btf.c
+++ w/tools/bpf/bpftool/btf.c
@@ -798,6 +798,9 @@ static int dump_btf_c(const struct btf *btf,
        printf("#define __bpf_fastcall\n");
        printf("#endif\n");
        printf("#endif\n\n");
+       printf("#pragma clang diagnostic push\n");
+       printf("#pragma clang diagnostic ignored \"-Wmissing-declarations\"\n");
+       printf("\n");

        if (root_type_cnt) {
                for (i = 0; i < root_type_cnt; i++) {
@@ -823,6 +826,8 @@ static int dump_btf_c(const struct btf *btf,
                        goto done;
        }

+       printf("\n");
+       printf("#pragma clang diagnostic pop\n");
        printf("#ifndef BPF_NO_PRESERVE_ACCESS_INDEX\n");
        printf("#pragma clang attribute pop\n");
        printf("#endif\n");

Re: fms-extensions and bpf

[Alexei Starovoitov]

On Mon, Dec 15, 2025 at 3:46 PM Song Liu <song@kernel.org> wrote:
>
> On Wed, Dec 3, 2025 at 8:30 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > Hi All,
> >
> > The kernel is now built with -fms-extensions and it is
> > using them in various places.
> > To stop-the-bleed and let selftests/bpf pass
> > I applied the short term fix:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=835a50753579aa8368a08fca307e638723207768
> >
> > Long term I think we can try to teach bpftool
> > to emit __diag_push("-fms-extensions"..)
> > at the top of vmlinux.h.
> > Not sure whether it's working though.
>
> Something like the following works for me. But I am not sure
> whether it is the best solution.

Great. Pls submit an official patch targeting bpf tree,
since without the fix the vmlinux_6_19.h won't be usable in older setups.

> Thanks,
> Song
>
> diff --git i/tools/bpf/bpftool/btf.c w/tools/bpf/bpftool/btf.c
> index 946612029dee..606886b79805 100644
> --- i/tools/bpf/bpftool/btf.c
> +++ w/tools/bpf/bpftool/btf.c
> @@ -798,6 +798,9 @@ static int dump_btf_c(const struct btf *btf,
>         printf("#define __bpf_fastcall\n");
>         printf("#endif\n");
>         printf("#endif\n\n");
> +       printf("#pragma clang diagnostic push\n");
> +       printf("#pragma clang diagnostic ignored \"-Wmissing-declarations\"\n");

what about pragma GCC ? gcc-bpf is gaining traction...
will pragma clang or pragma GCC work for both?

> +       printf("\n");

here...

>
>         if (root_type_cnt) {
>                 for (i = 0; i < root_type_cnt; i++) {
> @@ -823,6 +826,8 @@ static int dump_btf_c(const struct btf *btf,
>                         goto done;
>         }
>
> +       printf("\n");

and here... I would skip printing these two empty lines.

> +       printf("#pragma clang diagnostic pop\n");
>         printf("#ifndef BPF_NO_PRESERVE_ACCESS_INDEX\n");
>         printf("#pragma clang attribute pop\n");
>         printf("#endif\n");

Re: fms-extensions and bpf

[Song Liu]

On Mon, Dec 15, 2025 at 5:24 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Mon, Dec 15, 2025 at 3:46 PM Song Liu <song@kernel.org> wrote:
> >
> > On Wed, Dec 3, 2025 at 8:30 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > Hi All,
> > >
> > > The kernel is now built with -fms-extensions and it is
> > > using them in various places.
> > > To stop-the-bleed and let selftests/bpf pass
> > > I applied the short term fix:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=835a50753579aa8368a08fca307e638723207768
> > >
> > > Long term I think we can try to teach bpftool
> > > to emit __diag_push("-fms-extensions"..)
> > > at the top of vmlinux.h.
> > > Not sure whether it's working though.
> >
> > Something like the following works for me. But I am not sure
> > whether it is the best solution.
>
> Great. Pls submit an official patch targeting bpf tree,
> since without the fix the vmlinux_6_19.h won't be usable in older setups.
>
> > Thanks,
> > Song
> >
> > diff --git i/tools/bpf/bpftool/btf.c w/tools/bpf/bpftool/btf.c
> > index 946612029dee..606886b79805 100644
> > --- i/tools/bpf/bpftool/btf.c
> > +++ w/tools/bpf/bpftool/btf.c
> > @@ -798,6 +798,9 @@ static int dump_btf_c(const struct btf *btf,
> >         printf("#define __bpf_fastcall\n");
> >         printf("#endif\n");
> >         printf("#endif\n\n");
> > +       printf("#pragma clang diagnostic push\n");
> > +       printf("#pragma clang diagnostic ignored \"-Wmissing-declarations\"\n");
>
> what about pragma GCC ? gcc-bpf is gaining traction...
> will pragma clang or pragma GCC work for both?

Turns out "#pragma GCC diagnostic" works for both.

However, I think we cannot use this in the long term, because it
effectively removes the anonymous member from the enclosing
struct. For example, if I add

struct __test_ms_extensions {
       int ms_extensions_id;
};

struct task_struct {
        /* ... */
        struct __test_ms_extensions;
};

We cannot access ms_extensions_id from BPF program:

        task = bpf_get_current_task_btf();
        /* the following doesn't work */
        ms_extensions_id = task->ms_extensions_id;

I think there are two options moving forward:

1. Ask the users to add "-fms-extensions  -Wno-microsoft-anon-tag"
    to the makefile.
2. Teach bpftool to unfold the anonymous member struct/union. For
    example, the above code will be like the following in vmlinux.h:

        struct task_struct {
                /* ... */
                int ms_extensions_id;
        };

Thanks,
Song

Re: fms-extensions and bpf

[Alan Maguire]

On 16/12/2025 07:50, Song Liu wrote:
> On Mon, Dec 15, 2025 at 5:24 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> On Mon, Dec 15, 2025 at 3:46 PM Song Liu <song@kernel.org> wrote:
>>>
>>> On Wed, Dec 3, 2025 at 8:30 PM Alexei Starovoitov
>>> <alexei.starovoitov@gmail.com> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> The kernel is now built with -fms-extensions and it is
>>>> using them in various places.
>>>> To stop-the-bleed and let selftests/bpf pass
>>>> I applied the short term fix:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=835a50753579aa8368a08fca307e638723207768
>>>>
>>>> Long term I think we can try to teach bpftool
>>>> to emit __diag_push("-fms-extensions"..)
>>>> at the top of vmlinux.h.
>>>> Not sure whether it's working though.
>>>
>>> Something like the following works for me. But I am not sure
>>> whether it is the best solution.
>>
>> Great. Pls submit an official patch targeting bpf tree,
>> since without the fix the vmlinux_6_19.h won't be usable in older setups.
>>
>>> Thanks,
>>> Song
>>>
>>> diff --git i/tools/bpf/bpftool/btf.c w/tools/bpf/bpftool/btf.c
>>> index 946612029dee..606886b79805 100644
>>> --- i/tools/bpf/bpftool/btf.c
>>> +++ w/tools/bpf/bpftool/btf.c
>>> @@ -798,6 +798,9 @@ static int dump_btf_c(const struct btf *btf,
>>>         printf("#define __bpf_fastcall\n");
>>>         printf("#endif\n");
>>>         printf("#endif\n\n");
>>> +       printf("#pragma clang diagnostic push\n");
>>> +       printf("#pragma clang diagnostic ignored \"-Wmissing-declarations\"\n");
>>
>> what about pragma GCC ? gcc-bpf is gaining traction...
>> will pragma clang or pragma GCC work for both?
> 
> Turns out "#pragma GCC diagnostic" works for both.
> 
> However, I think we cannot use this in the long term, because it
> effectively removes the anonymous member from the enclosing
> struct. For example, if I add
> 
> struct __test_ms_extensions {
>        int ms_extensions_id;
> };
> 
> struct task_struct {
>         /* ... */
>         struct __test_ms_extensions;
> };
> 
> We cannot access ms_extensions_id from BPF program:
> 
>         task = bpf_get_current_task_btf();
>         /* the following doesn't work */
>         ms_extensions_id = task->ms_extensions_id;
> 
> I think there are two options moving forward:
> 
> 1. Ask the users to add "-fms-extensions  -Wno-microsoft-anon-tag"
>     to the makefile.
> 2. Teach bpftool to unfold the anonymous member struct/union. For
>     example, the above code will be like the following in vmlinux.h:
> 
>         struct task_struct {
>                 /* ... */
>                 int ms_extensions_id;
>         };
>

One approach we could take here is add an option to btf_dump__new()
such as

bool force_anon_struct_members;

...and for the moment have bpftool use it by default. Then when libbpf's
dump function encounters such named nested structures with no member name
it anonymizes them. With this approach we end up with definitions like:

struct ns_tree {
        u64 ns_id;
        atomic_t __ns_ref_active;
        struct ns_tree_node ns_unified_node;
        struct ns_tree_node ns_tree_node;
        struct ns_tree_node ns_owner_node;
        struct ns_tree_root ns_owner_root;
};

struct proc_ns_operations;

struct ns_common {
        u32 ns_type;
        struct dentry *stashed;
        const struct proc_ns_operations *ops;
        unsigned int inum;
        refcount_t __ns_ref;
        union {
                struct  {
                        u64 ns_id;
                        atomic_t __ns_ref_active;
                        struct ns_tree_node ns_unified_node;
                        struct ns_tree_node ns_tree_node;
                        struct ns_tree_node ns_owner_node;
                        struct ns_tree_root ns_owner_root;
                };
                struct callback_head ns_rcu;
        };
};

i.e. the embedded struct ns_tree is anonymized.
 
So we end up preserving type access, size etc; the only thing missing is
the name for the nested "struct ns_tree". We could add an option to bpftool
to relax this restriction if needed for users specifying -fms-extension.

Not sure though if this might create any issues for CO-RE accesses to the
fields? i.e. does the fact that the vmlinux.h representation diverges from
the actual BTF have any subtle implications? I don't think so but just in case..

I have a working patch for the above which I can send out if it sounds like the
right approach. Thanks!

Alan
 
> Thanks,
> Song
> 

Re: fms-extensions and bpf

[Song Liu]

On Tue, Dec 16, 2025 at 5:08 AM Alan Maguire <alan.maguire@oracle.com> wrote:
[...]
> i.e. the embedded struct ns_tree is anonymized.
>
> So we end up preserving type access, size etc; the only thing missing is
> the name for the nested "struct ns_tree". We could add an option to bpftool
> to relax this restriction if needed for users specifying -fms-extension.
>
> Not sure though if this might create any issues for CO-RE accesses to the
> fields? i.e. does the fact that the vmlinux.h representation diverges from
> the actual BTF have any subtle implications? I don't think so but just in case..
>
> I have a working patch for the above which I can send out if it sounds like the
> right approach. Thanks!

This feels like the best option to keep backward compatibility. Please send
the patch so we can test and discuss more.

Thanks,
Song

Re: fms-extensions and bpf

[Alan Maguire]

On 16/12/2025 16:52, Song Liu wrote:
> On Tue, Dec 16, 2025 at 5:08 AM Alan Maguire <alan.maguire@oracle.com> wrote:
> [...]
>> i.e. the embedded struct ns_tree is anonymized.
>>
>> So we end up preserving type access, size etc; the only thing missing is
>> the name for the nested "struct ns_tree". We could add an option to bpftool
>> to relax this restriction if needed for users specifying -fms-extension.
>>
>> Not sure though if this might create any issues for CO-RE accesses to the
>> fields? i.e. does the fact that the vmlinux.h representation diverges from
>> the actual BTF have any subtle implications? I don't think so but just in case..
>>
>> I have a working patch for the above which I can send out if it sounds like the
>> right approach. Thanks!
> 
> This feels like the best option to keep backward compatibility. Please send
> the patch so we can test and discuss more.
> 

Sure; sent [1]. Thanks!

Alan

[1] https://lore.kernel.org/bpf/20251216171854.2291424-1-alan.maguire@oracle.com/