Re: [Devel] [PATCH vz10 3/5] fixup! vhost/vsock: only refuse connection when guest has never been ready

Re: [Devel] [PATCH vz10 3/5] fixup! vhost/vsock: only refuse connection when guest has never been ready

[Konstantin Khorenko]

Andrey, can you please clarify - do we really need this patch?

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

On 6/25/26 20:16, Eva Kurchatova wrote:
> From: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> 
> Commit 4ff28534c799 ("ms/vhost/vsock: Refuse the connection immediately
> when guest isn't ready") added a check which immediately returns
> EHOSTUNREACH when the guest isn't ready yet.  Namely, we check that guest
> hasn't enabled the RX vq yet, i.e. virtio-vsock has never beed enabled.
> 
> However, the check also affects the transient state when backend is
> temporarily set to NULL during VHOST_VSOCK_SET_RUNNING(0).  Notably,
> this is the case with qemu-update operation, during which we perform
> VHOST_RESET_OWNER.  In this case sendmsg()/connect() on otherwise healthy
> connection gets EHOSTUNREACH.
> 
> Gate the fast-fail on a sticky started_once bit set in
> vhost_vsock_start() and never cleared.  Once the guest has brought
> up virtio-vsock at least once, a NULL backend means a transient stop
> window and the packet must be queued for vhost_vsock_start() to drain
> on re-attach.
> 
> Fixes: 4ff28534c799 ("ms/vhost/vsock: Refuse the connection immediately when guest isn't ready")
> https://virtuozzo.atlassian.net/browse/VSTOR-131956
> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> ---
>  drivers/vhost/vsock.c | 31 ++++++++++++++-----------------
>  1 file changed, 14 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
> index d4c3f94308db..f652f47956d7 100644
> --- a/drivers/vhost/vsock.c
> +++ b/drivers/vhost/vsock.c
> @@ -59,6 +59,7 @@ struct vhost_vsock {
>  
>  	u32 guest_cid;
>  	bool seqpacket_allow;
> +	bool started_once;	/* latched in vhost_vsock_start(); never cleared */
>  	bool cpr_paused;	/* between stop and next start; queues sends */
>  };
>  
> @@ -289,24 +290,17 @@ vhost_transport_send_pkt(struct sk_buff *skb, struct net *net)
>  		return -ENODEV;
>  	}
>  
> -	/* Fast-fail if the guest hasn't enabled the RX vq yet. Queuing the packet
> -	 * and making the caller wait is pointless: even if the guest manages to init
> -	 * within the timeout, it'll immediately reply with RST, because there's no
> -	 * listener on the port yet.
> -	 *
> -	 * vhost_vq_get_backend() without vq->mutex is acceptable here: locking
> -	 * the mutex would be too expensive in this hot path, and we already have
> -	 * all the outcomes covered: if the backend becomes NULL right after the check,
> -	 * vhost_transport_do_send_pkt() will check it under the mutex anyway.
> +	/*
> +	 * Fast-fail only when the guest has never enabled virtio-vsock.
> +	 * Once it has, a NULL backend means a transient SET_RUNNING(0)
> +	 * window (e.g. VHOST_RESET_OWNER); the packet must be
> +	 * queued for vhost_vsock_start() to drain on re-attach.
>  	 */
> -	/* cpr_paused: queue across CPR; else NULL backend means not ready. */
> -	if (unlikely(!data_race(vhost_vq_get_backend(&vsock->vqs[VSOCK_VQ_RX])))) {
> -		smp_rmb();	/* pairs with smp_wmb() in start/drop_backends */
> -		if (!READ_ONCE(vsock->cpr_paused)) {
> -			rcu_read_unlock();
> -			kfree_skb(skb);
> -			return -EHOSTUNREACH;
> -		}
> +	if (unlikely(!READ_ONCE(vsock->started_once)) &&
> +	    !data_race(vhost_vq_get_backend(&vsock->vqs[VSOCK_VQ_RX]))) {
> +		rcu_read_unlock();
> +		kfree_skb(skb);
> +		return -EHOSTUNREACH;
>  	}
>  
>  	if (virtio_vsock_skb_reply(skb))
> @@ -637,6 +631,9 @@ static int vhost_vsock_start(struct vhost_vsock *vsock)
>  	 */
>  	vhost_vq_work_queue(&vsock->vqs[VSOCK_VQ_RX], &vsock->send_pkt_work);
>  
> +	/* See vhost_transport_send_pkt(); never cleared. */
> +	WRITE_ONCE(vsock->started_once, true);
> +
>  	mutex_unlock(&vsock->dev.mutex);
>  	return 0;
>  

Re: [Devel] [PATCH vz10 3/5] fixup! vhost/vsock: only refuse connection when guest has never been ready

[Andrey Drobyshev]

On 8/18/26 7:41 PM, Konstantin Khorenko wrote:
> Andrey, can you please clarify - do we really need this patch?
> 
> --
> Best regards,
> 
> Konstantin Khorenko,
> Virtuozzo Linux Kernel Team
> 

No we don't.  On branch-rh10-6.12.0-211.39.1.16.x.vz10-ovz we have:

780730eefdcb ("vhost/vsock: suppress EHOSTUNREACH fast-fail during CPR
pause")
9727608ea5ec ("vhost/vsock: always initialize vhost_vsock->cpr_paused
field")

With those applied, my old patch is redundant.

Andrey

> On 6/25/26 20:16, Eva Kurchatova wrote:
>> From: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
>>
>> Commit 4ff28534c799 ("ms/vhost/vsock: Refuse the connection immediately
>> when guest isn't ready") added a check which immediately returns
>> EHOSTUNREACH when the guest isn't ready yet.  Namely, we check that guest
>> hasn't enabled the RX vq yet, i.e. virtio-vsock has never beed enabled.
>>
>> However, the check also affects the transient state when backend is
>> temporarily set to NULL during VHOST_VSOCK_SET_RUNNING(0).  Notably,
>> this is the case with qemu-update operation, during which we perform
>> VHOST_RESET_OWNER.  In this case sendmsg()/connect() on otherwise healthy
>> connection gets EHOSTUNREACH.
>>
>> Gate the fast-fail on a sticky started_once bit set in
>> vhost_vsock_start() and never cleared.  Once the guest has brought
>> up virtio-vsock at least once, a NULL backend means a transient stop
>> window and the packet must be queued for vhost_vsock_start() to drain
>> on re-attach.
>>
>> Fixes: 4ff28534c799 ("ms/vhost/vsock: Refuse the connection immediately when guest isn't ready")
>> https://virtuozzo.atlassian.net/browse/VSTOR-131956
>> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
>> ---
>>  drivers/vhost/vsock.c | 31 ++++++++++++++-----------------
>>  1 file changed, 14 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
>> index d4c3f94308db..f652f47956d7 100644
>> --- a/drivers/vhost/vsock.c
>> +++ b/drivers/vhost/vsock.c
>> @@ -59,6 +59,7 @@ struct vhost_vsock {
>>  
>>  	u32 guest_cid;
>>  	bool seqpacket_allow;
>> +	bool started_once;	/* latched in vhost_vsock_start(); never cleared */
>>  	bool cpr_paused;	/* between stop and next start; queues sends */
>>  };
>>  
>> @@ -289,24 +290,17 @@ vhost_transport_send_pkt(struct sk_buff *skb, struct net *net)
>>  		return -ENODEV;
>>  	}
>>  
>> -	/* Fast-fail if the guest hasn't enabled the RX vq yet. Queuing the packet
>> -	 * and making the caller wait is pointless: even if the guest manages to init
>> -	 * within the timeout, it'll immediately reply with RST, because there's no
>> -	 * listener on the port yet.
>> -	 *
>> -	 * vhost_vq_get_backend() without vq->mutex is acceptable here: locking
>> -	 * the mutex would be too expensive in this hot path, and we already have
>> -	 * all the outcomes covered: if the backend becomes NULL right after the check,
>> -	 * vhost_transport_do_send_pkt() will check it under the mutex anyway.
>> +	/*
>> +	 * Fast-fail only when the guest has never enabled virtio-vsock.
>> +	 * Once it has, a NULL backend means a transient SET_RUNNING(0)
>> +	 * window (e.g. VHOST_RESET_OWNER); the packet must be
>> +	 * queued for vhost_vsock_start() to drain on re-attach.
>>  	 */
>> -	/* cpr_paused: queue across CPR; else NULL backend means not ready. */
>> -	if (unlikely(!data_race(vhost_vq_get_backend(&vsock->vqs[VSOCK_VQ_RX])))) {
>> -		smp_rmb();	/* pairs with smp_wmb() in start/drop_backends */
>> -		if (!READ_ONCE(vsock->cpr_paused)) {
>> -			rcu_read_unlock();
>> -			kfree_skb(skb);
>> -			return -EHOSTUNREACH;
>> -		}
>> +	if (unlikely(!READ_ONCE(vsock->started_once)) &&
>> +	    !data_race(vhost_vq_get_backend(&vsock->vqs[VSOCK_VQ_RX]))) {
>> +		rcu_read_unlock();
>> +		kfree_skb(skb);
>> +		return -EHOSTUNREACH;
>>  	}
>>  
>>  	if (virtio_vsock_skb_reply(skb))
>> @@ -637,6 +631,9 @@ static int vhost_vsock_start(struct vhost_vsock *vsock)
>>  	 */
>>  	vhost_vq_work_queue(&vsock->vqs[VSOCK_VQ_RX], &vsock->send_pkt_work);
>>  
>> +	/* See vhost_transport_send_pkt(); never cleared. */
>> +	WRITE_ONCE(vsock->started_once, true);
>> +
>>  	mutex_unlock(&vsock->dev.mutex);
>>  	return 0;
>>  
> 

Re: [Devel] [PATCH vz10 3/5] fixup! vhost/vsock: only refuse connection when guest has never been ready

[Konstantin Khorenko]

On 6/25/26 20:16, Eva Kurchatova wrote:
> From: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> 
> Commit 4ff28534c799 ("ms/vhost/vsock: Refuse the connection immediately
> when guest isn't ready") added a check which immediately returns
> EHOSTUNREACH when the guest isn't ready yet.  Namely, we check that guest
> hasn't enabled the RX vq yet, i.e. virtio-vsock has never beed enabled.

s/beed/been/

> 
> However, the check also affects the transient state when backend is
> temporarily set to NULL during VHOST_VSOCK_SET_RUNNING(0).  Notably,
> this is the case with qemu-update operation, during which we perform
> VHOST_RESET_OWNER.  In this case sendmsg()/connect() on otherwise healthy
> connection gets EHOSTUNREACH.
> 
> Gate the fast-fail on a sticky started_once bit set in
> vhost_vsock_start() and never cleared.  Once the guest has brought
> up virtio-vsock at least once, a NULL backend means a transient stop
> window and the packet must be queued for vhost_vsock_start() to drain
> on re-attach.
> 
> Fixes: 4ff28534c799 ("ms/vhost/vsock: Refuse the connection immediately when guest isn't ready")
> https://virtuozzo.atlassian.net/browse/VSTOR-131956
> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> ---
>  drivers/vhost/vsock.c | 31 ++++++++++++++-----------------
>  1 file changed, 14 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
> index d4c3f94308db..f652f47956d7 100644
> --- a/drivers/vhost/vsock.c
> +++ b/drivers/vhost/vsock.c
> @@ -59,6 +59,7 @@ struct vhost_vsock {
>  
>  	u32 guest_cid;
>  	bool seqpacket_allow;
> +	bool started_once;	/* latched in vhost_vsock_start(); never cleared */
>  	bool cpr_paused;	/* between stop and next start; queues sends */
>  };

static int vhost_vsock_dev_open(struct inode *inode, struct file *file)
{
...
        vsock = kvmalloc(sizeof(*vsock), GFP_KERNEL | __GFP_RETRY_MAYFAIL);

So, not zeroing struct fields here on allocation.
.started_once is not directly initialized => can have any start value.

>  
> @@ -289,24 +290,17 @@ vhost_transport_send_pkt(struct sk_buff *skb, struct net *net)
>  		return -ENODEV;
>  	}
>  
> -	/* Fast-fail if the guest hasn't enabled the RX vq yet. Queuing the packet
> -	 * and making the caller wait is pointless: even if the guest manages to init
> -	 * within the timeout, it'll immediately reply with RST, because there's no
> -	 * listener on the port yet.
> -	 *


> -	 * vhost_vq_get_backend() without vq->mutex is acceptable here: locking
> -	 * the mutex would be too expensive in this hot path, and we already have
> -	 * all the outcomes covered: if the backend becomes NULL right after the check,
> -	 * vhost_transport_do_send_pkt() will check it under the mutex anyway.

Why you drop this part of the comment? It looks useful.

> +	/*
> +	 * Fast-fail only when the guest has never enabled virtio-vsock.
> +	 * Once it has, a NULL backend means a transient SET_RUNNING(0)
> +	 * window (e.g. VHOST_RESET_OWNER); the packet must be
> +	 * queued for vhost_vsock_start() to drain on re-attach.
>  	 */
> -	/* cpr_paused: queue across CPR; else NULL backend means not ready. */
> -	if (unlikely(!data_race(vhost_vq_get_backend(&vsock->vqs[VSOCK_VQ_RX])))) {
> -		smp_rmb();	/* pairs with smp_wmb() in start/drop_backends */
> -		if (!READ_ONCE(vsock->cpr_paused)) {

(kostja at f0)/git/vzkernel.vz10:git grep cpr_paused
drivers/vhost/vsock.c:  bool cpr_paused;        /* between stop and next start; queues sends */
drivers/vhost/vsock.c:  /* cpr_paused: queue across CPR; else NULL backend means not ready. */
drivers/vhost/vsock.c:          if (!READ_ONCE(vsock->cpr_paused)) {
drivers/vhost/vsock.c:  WRITE_ONCE(vsock->cpr_paused, false);
drivers/vhost/vsock.c:          WRITE_ONCE(vsock->cpr_paused, true);
drivers/vhost/vsock.c:  vsock->cpr_paused = false;

So you are dropping the only READ of this vsock->cpr_paused, so it's not needed anymore after this patch.

> -			rcu_read_unlock();
> -			kfree_skb(skb);
> -			return -EHOSTUNREACH;
> -		}
> +	if (unlikely(!READ_ONCE(vsock->started_once)) &&
> +	    !data_race(vhost_vq_get_backend(&vsock->vqs[VSOCK_VQ_RX]))) {
> +		rcu_read_unlock();
> +		kfree_skb(skb);
> +		return -EHOSTUNREACH;
>  	}
>  
>  	if (virtio_vsock_skb_reply(skb))
> @@ -637,6 +631,9 @@ static int vhost_vsock_start(struct vhost_vsock *vsock)
>  	 */
>  	vhost_vq_work_queue(&vsock->vqs[VSOCK_VQ_RX], &vsock->send_pkt_work);
>  
> +	/* See vhost_transport_send_pkt(); never cleared. */
> +	WRITE_ONCE(vsock->started_once, true);
> +
>  	mutex_unlock(&vsock->dev.mutex);
>  	return 0;
>  

Re: [Devel] [PATCH vz10 4/5] fixup! vhost/vsock: re-scan TX virtqueue on device start

[Konstantin Khorenko]

already applied here

The commit is pushed to "branch-rh10-6.12.0-211.16.1.12.x.vz10-ovz" and will appear at git at bitbucket.org:openvz/vzkernel.git
after rh10-6.12.0-211.16.1.12.5.vz10
------>
commit 67fdd1befc4da39f114de9a2ad4e725ea442a034
Author: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Date:   Thu Jun 4 18:46:13 2026 +0300

    vhost/vsock: re-scan TX virtqueue on device start
    
    During QEMU CPR live-update (and VHOST_RESET_OWNER in general) the guest
    keeps running while the host drops and later re-attaches vhost backends.
    If the guest adds a buffer to the TX virtqueue (guest->host) and kicks
    while the backend is temporarily NULL (between vhost_vsock_drop_backends()
    and the next vhost_vsock_start()), then the kick is delivered to the
    vhost worker, handle_tx_kick() sees a NULL backend and returns, and the
    kick signal is consumed.  The buffer is then left in the ring.
    
    Then upon device start vhost_vsock_start() only re-kicks the RX send
    worker, never the TX VQ, so the buffer is processed only if the guest
    happens to kick again.  But if the guest itself is now waiting for data
    from the host, it will never kick TX VQ again, and we end up in a
    deadlock.
    
    The deadlock is reproduced during active host->guest socat data transfer
    under multiple consecutive qemu-update's.
    
    To fix this, in vhost_vsock_start(), after kicking the RX send worker, also
    queue the TX vq poll so any buffers the guest enqueued while we were paused
    get scanned.
    
    https://virtuozzo.atlassian.net/browse/VSTOR-131956
    https://virtuozzo.atlassian.net/browse/VSTOR-101116
    Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
    Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
    Feature: vhost-vsock: VHOST_RESET_OWNER ioctl

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

On 6/25/26 20:16, Eva Kurchatova wrote:
> From: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> 
> During QEMU CPR live-update (and VHOST_RESET_OWNER in general) the guest
> keeps running while the host drops and later re-attaches vhost backends.
> If the guest adds a buffer to the TX virtqueue (guest->host) and kicks
> while the backend is temporarily NULL (between vhost_vsock_drop_backends()
> and the next vhost_vsock_start()), then the kick is delivered to the
> vhost worker, handle_tx_kick() sees a NULL backend and returns, and the
> kick signal is consumed.  The buffer is then left in the ring.
> 
> Then upon device start vhost_vsock_start() only re-kicks the RX send
> worker, never the TX VQ, so the buffer is processed only if the guest
> happens to kick again.  But if the guest itself is now waiting for data
> from the host, it will never kick TX VQ again, and we end up in a
> deadlock.
> 
> The deadlock is reproduced during active host->guest socat data transfer
> under multiple consecutive qemu-update's.
> 
> To fix this, in vhost_vsock_start(), after kicking the RX send worker, also
> queue the TX vq poll so any buffers the guest enqueued while we were paused
> get scanned.
> 
> https://virtuozzo.atlassian.net/browse/VSTOR-131956
> https://virtuozzo.atlassian.net/browse/VSTOR-101116
> 
> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> 
> Feature: vhost-vsock: VHOST_RESET_OWNER ioctl
> ---
>  drivers/vhost/vsock.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
> index f652f47956d7..2cee40a1ca04 100644
> --- a/drivers/vhost/vsock.c
> +++ b/drivers/vhost/vsock.c
> @@ -634,6 +634,12 @@ static int vhost_vsock_start(struct vhost_vsock *vsock)
>  	/* See vhost_transport_send_pkt(); never cleared. */
>  	WRITE_ONCE(vsock->started_once, true);
>  
> +	/*
> +	 * Some packets might've also been queued in TX VQ.  Re-scan it here,
> +	 * mirroring the RX send-worker kick above.
> +	 */
> +	vhost_poll_queue(&vsock->vqs[VSOCK_VQ_TX].poll);
> +
>  	mutex_unlock(&vsock->dev.mutex);
>  	return 0;
>  

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

[Konstantin Khorenko]

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 \

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

[Konstantin Khorenko]

a kind ping

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

On 8/18/26 19: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 \
> 

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

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

[Eva Kurchatova (Virtuozzo)]

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.

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.

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

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

[Konstantin Khorenko]

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

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

[Eva Kurchatova (Virtuozzo)]

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