OpenVZ / Virtuozzo kernel development (devel@openvz.org)
 help / color / mirror / Atom feed
From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: "Eva Kurchatova (Virtuozzo)" <eva.kurchatova@virtuozzo.com>
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH vz10 5/5] fixup! samples/bpf: fix -Wduplicate-decl-specifier and -Wmissing-declarations
Date: Fri, 25 Sep 2026 11:33:53 +0200	[thread overview]
Message-ID: <6e049938-4de0-4ad7-a4df-b8a9f3f104a6@virtuozzo.com> (raw)
In-Reply-To: <1579c047-2822-4fce-91a5-c950ccf07c08@virtuozzo.com>

ping
1. task for sending this patch to mainstream, link to the https://virtuozzo.atlassian.net/browse/VSTOR-127585
2. sending the patch to ms

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

On 8/27/26 16:29, Eva Kurchatova (Virtuozzo) wrote:
> 
> On 8/27/26 15:42, Konstantin Khorenko wrote:
>> 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.
> 
> Yes, these warnings will appear, but the current fix only suffices for 
> an x86_64 host, where `__seg_gs`, etc attributes are used within the 
> arch-specific kernel headers. If this kselftest was built on, say arm64, 
> different warnings would likely surface which were out of scope. In 
> general this patch is more of a workaround than the solution to the 
> original problem: Arch-specific headers are used while compiling into 
> BPF bytecode. That is why I originally only envisioned it as a fix for 
> compile failures in Virtiozzo CI. Around the time of the submission of 
> this patch, I tried to work on a more advanced solution, that would use 
> arch-generic headers to build BPF programs. But soon that proved 
> unsuccessful given that arch-specific headers directly alter the kernel 
> structure and memory layout, which the BPF programs must understand.
> 
> 
>>> 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.
> 
> 
> I will improve this patch description, and send it within batch of other 
> BPF fixes you are currently reviewing when they are ready. Thanks.
> 

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

      reply	other threads:[~2026-09-25  9:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260625181637.1555685-1-eva.kurchatova@virtuozzo.com>
     [not found] ` <20260625181637.1555685-3-eva.kurchatova@virtuozzo.com>
2026-08-18 16:41   ` [Devel] [PATCH vz10 3/5] fixup! vhost/vsock: only refuse connection when guest has never been ready Konstantin Khorenko
2026-08-19  9:01     ` Andrey Drobyshev
2026-08-18 16:53   ` Konstantin Khorenko
     [not found] ` <20260625181637.1555685-4-eva.kurchatova@virtuozzo.com>
2026-08-18 16:56   ` [Devel] [PATCH vz10 4/5] fixup! vhost/vsock: re-scan TX virtqueue on device start Konstantin Khorenko
     [not found] ` <20260625181637.1555685-5-eva.kurchatova@virtuozzo.com>
2026-08-18 17:00   ` [Devel] [PATCH vz10 5/5] fixup! samples/bpf: fix -Wduplicate-decl-specifier and -Wmissing-declarations Konstantin Khorenko
2026-08-26 16:49     ` Konstantin Khorenko
2026-08-26 20:08     ` Eva Kurchatova (Virtuozzo)
2026-08-27 12:42       ` Konstantin Khorenko
2026-08-27 14:29         ` Eva Kurchatova (Virtuozzo)
2026-09-25  9:33           ` Konstantin Khorenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6e049938-4de0-4ad7-a4df-b8a9f3f104a6@virtuozzo.com \
    --to=khorenko@virtuozzo.com \
    --cc=devel@openvz.org \
    --cc=eva.kurchatova@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox