Re: fms-extensions and bpf

[Alan Maguire <alan.maguire@oracle.com>]

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
>