Re: [Devel] [PATCH vz10 5/5] fixup! samples/bpf: fix -Wduplicate-decl-specifier and -Wmissing-declarations

[Konstantin Khorenko <khorenko@virtuozzo.com>]

On 8/26/26 22:08, Eva Kurchatova (Virtuozzo) wrote:
> 
> On 8/18/26 20:00, Konstantin Khorenko wrote:
>> i have asked to send this patch to mainstream first.
>>
>> Please, add a link to the mainstream version of the patch to https://virtuozzo.atlassian.net/browse/VSTOR-127585
>>
>> --
>> Best regards,
>>
>> Konstantin Khorenko,
>> Virtuozzo Linux Kernel Team
>>
>> On 6/25/26 20:16, Eva Kurchatova wrote:
>>> BPF programs include arch-specific headers, which use address space
>>> qualifiers for percpu variables via __seg_gs / __seg_fs, however those
>>> are meaningless for BPF compiler and will raise a warning
>>>
>>> Fix this by redefining __seg_gs and __seg_fs to a no-op attribute
>>>
>>> Additionally, enable ms-extensions, as generated vmlinux.h uses these
>>> for structure layout inheritance, an acceptable practice in upstream
>>>
>>> https://virtuozzo.atlassian.net/browse/VSTOR-127585
>>> Feature: fix selftests
>>>
>>> Signed-off-by: Eva Kurchatova <eva.kurchatova@virtuozzo.com>
>>> ---
>>>   samples/bpf/Makefile | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>>> index 2b93779b9cbf..39b20bb69bcd 100644
>>> --- a/samples/bpf/Makefile
>>> +++ b/samples/bpf/Makefile
>>> @@ -339,9 +339,11 @@ CLANG_SYS_INCLUDES = $(call get_sys_includes,$(CLANG))
>>>   
>>>   $(obj)/xdp_router_ipv4.bpf.o: $(obj)/xdp_sample.bpf.o
>>>   
>>> +# Generated vmlinux.h uses ms-extensions to inherit struct layout
>>>   $(obj)/%.bpf.o: $(src)/%.bpf.c $(obj)/vmlinux.h $(src)/xdp_sample.bpf.h $(src)/xdp_sample_shared.h
>>>   	@echo "  CLANG-BPF " $@
>>>   	$(Q)$(CLANG) -g -O2 --target=bpf -D__TARGET_ARCH_$(SRCARCH) \
>>> +		-fms-extensions -Wno-microsoft-anon-tag \
>>>   		-Wno-compare-distinct-pointer-types -I$(srctree)/include \
>>>   		-I$(srctree)/samples/bpf -I$(srctree)/tools/include \
>>>   		-I$(LIBBPF_INCLUDE) $(CLANG_SYS_INCLUDES) \
>>> @@ -372,11 +374,13 @@ $(BPF_SKELS_LINKED): $(BPF_OBJS_LINKED) $(BPFTOOL)
>>>   # with native target, e.g., x64, arm64, etc. 'opt' does bpf CORE IR builtin
>>>   # processing (llvm12) and IR optimizations. 'llvm-dis' converts
>>>   # 'opt' output to IR, and finally 'llc' generates bpf byte code.
>>> +# Additionally, __seg_gs and __seg_fs are ignored in BPF code
>>>   $(obj)/%.o: $(src)/%.c
>>>   	@echo "  CLANG-bpf " $@
>>>   	$(Q)$(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(BPF_EXTRA_CFLAGS) \
>>>   		-I$(obj) -I$(srctree)/tools/testing/selftests/bpf/ \
>>>   		-I$(LIBBPF_INCLUDE) $(CLANG_SYS_INCLUDES) \
>>> +		-U__seg_gs -D__seg_gs= -U__seg_fs -D__seg_fs= \
>>>   		-D__KERNEL__ -D__BPF_TRACING__ -Wno-unused-value -Wno-pointer-sign \
>>>   		-D__TARGET_ARCH_$(SRCARCH) -Wno-compare-distinct-pointer-types \
>>>   		-Wno-gnu-variable-sized-type-not-at-end \
> 
> This patch was made at a point when RHEL hardening flags leaked into 
> kselftests build, and at `-Wall -Wextra -Werror`, many build failures 
> surfaced.
> 
> Today the build does not fail: the spec undefines _fortify_level and 
> _hardened_build for this package, so a full samples/bpf build exits 0 
> with 166 warnings and no errors, all 13 .bpf.o and 38 sample binaries 
> produced. Of those warnings, 104 are exactly the ones this patch removes.
> 
> Does it still make sense to keep it, send upstream and backport back, or 
> should this patch be dropped? I am not sure upstream will accept this 
> patch as it stands, it was originally purely solving VZ-specific CI 
> failures.

Not sure i understand this correctly: if we take ms kernel and compile selftests, will those warnings appear?
If yes - then mainstream will be happy to apply the fix(es).

If not, please explain what is the difference between ms vs rh - both here and in the jira bug.
> Please also review the 4-commit patch series from Aug 21, non-backported 
> commits starting from "[PATCH vz10 2/4] selftests/bpf: run the network 
> tests in their own netns" first, so I can send a batch to upstream.

i will review that series.

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel