Skip to content

Conversation

shreeya-patel98
Copy link
Collaborator

Commit message

    Drivers: hv: vmbus: Remove vmbus_sendpacket_pagebuffer()
    
    jira LE-3554
    commit-author Michael Kelley <[email protected]>
    commit 45a442fe369e6c4e0b4aa9f63b31c3f2f9e2090e
    
    With the netvsc driver changed to use vmbus_sendpacket_mpb_desc()
    instead of vmbus_sendpacket_pagebuffer(), the latter has no remaining
    callers. Remove it.

--------------------------------------------------------------------------------------------

    hv_netvsc: Remove rmsg_pgcnt
    
    jira LE-3554
    commit-author Michael Kelley <[email protected]>
    commit 5bbc644bbf4e97a05bc0cb052189004588ff8a09
    
    init_page_array() now always creates a single page buffer array entry
    for the rndis message, even if the rndis message crosses a page
    boundary. As such, the number of page buffer array entries used for
    the rndis message must no longer be tracked -- it is always just 1.
    Remove the rmsg_pgcnt field and use "1" where the value is needed.

--------------------------------------------------------------------------------------------


    hv_netvsc: Preserve contiguous PFN grouping in the page buffer array
    
    jira LE-3554
    commit-author Michael Kelley <[email protected]>
    commit 41a6328b2c55276f89ea3812069fd7521e348bbf
    
    Starting with commit dca5161f9bd0 ("hv_netvsc: Check status in
    SEND_RNDIS_PKT completion message") in the 6.3 kernel, the Linux
    driver for Hyper-V synthetic networking (netvsc) occasionally reports
    "nvsp_rndis_pkt_complete error status: 2".[1] This error indicates
    that Hyper-V has rejected a network packet transmit request from the
    guest, and the outgoing network packet is dropped. Higher level
    network protocols presumably recover and resend the packet so there is
    no functional error, but performance is slightly impacted. Commit
    dca5161f9bd0 is not the cause of the error -- it only added reporting
    of an error that was already happening without any notice. The error
    has presumably been present since the netvsc driver was originally
    introduced into Linux.
    
    The root cause of the problem is that the netvsc driver in Linux may
    send an incorrectly formatted VMBus message to Hyper-V when
    transmitting the network packet. The incorrect formatting occurs when
    the rndis header of the VMBus message crosses a page boundary due to
    how the Linux skb head memory is aligned. In such a case, two PFNs are
    required to describe the location of the rndis header, even though
    they are contiguous in guest physical address (GPA) space. Hyper-V
    requires that two rndis header PFNs be in a single "GPA range" data
    struture, but current netvsc code puts each PFN in its own GPA range,
    which Hyper-V rejects as an error.
    
    The incorrect formatting occurs only for larger packets that netvsc
    must transmit via a VMBus "GPA Direct" message. There's no problem
    when netvsc transmits a smaller packet by copying it into a pre-
    allocated send buffer slot because the pre-allocated slots don't have
    page crossing issues.
    
    After commit 14ad6ed30a10 ("net: allow small head cache usage with
    large MAX_SKB_FRAGS values") in the 6.14-rc4 kernel, the error occurs
    much more frequently in VMs with 16 or more vCPUs. It may occur every
    few seconds, or even more frequently, in an ssh session that outputs a
    lot of text. Commit 14ad6ed30a10 subtly changes how skb head memory is
    allocated, making it much more likely that the rndis header will cross
    a page boundary when the vCPU count is 16 or more. The changes in
    commit 14ad6ed30a10 are perfectly valid -- they just had the side
    effect of making the netvsc bug more prominent.
    
    Current code in init_page_array() creates a separate page buffer array
    entry for each PFN required to identify the data to be transmitted.
    Contiguous PFNs get separate entries in the page buffer array, and any
    information about contiguity is lost.
    
    Fix the core issue by having init_page_array() construct the page
    buffer array to represent contiguous ranges rather than individual
    pages. When these ranges are subsequently passed to
    netvsc_build_mpb_array(), it can build GPA ranges that contain
    multiple PFNs, as required to avoid the error "nvsp_rndis_pkt_complete
    error status: 2". If instead the network packet is sent by copying
    into a pre-allocated send buffer slot, the copy proceeds using the
    contiguous ranges rather than individual pages, but the result of the
    copying is the same. Also fix rndis_filter_send_request() to construct
    a contiguous range, since it has its own page buffer array.
    
    This change has a side benefit in CoCo VMs in that netvsc_dma_map()
    calls dma_map_single() on each contiguous range instead of on each
    page. This results in fewer calls to dma_map_single() but on larger
    chunks of memory, which should reduce contention on the swiotlb.
    
    Since the page buffer array now contains one entry for each contiguous
    range instead of for each individual page, the number of entries in
    the array can be reduced, saving 208 bytes of stack space in
    netvsc_xmit() when MAX_SKG_FRAGS has the default value of 17.
    
    [1] https://bugzilla.kernel.org/show_bug.cgi?id=217503
    
--------------------------------------------------------------------------------------------

    hv_netvsc: Use vmbus_sendpacket_mpb_desc() to send VMBus messages
    
    jira LE-3554
    commit-author Michael Kelley <[email protected]>
    commit 4f98616b855cb0e3b5917918bb07b44728eb96ea
    
    netvsc currently uses vmbus_sendpacket_pagebuffer() to send VMBus
    messages. This function creates a series of GPA ranges, each of which
    contains a single PFN. However, if the rndis header in the VMBus
    message crosses a page boundary, the netvsc protocol with the host
    requires that both PFNs for the rndis header must be in a single "GPA
    range" data structure, which isn't possible with
    vmbus_sendpacket_pagebuffer(). As the first step in fixing this, add a
    new function netvsc_build_mpb_array() to build a VMBus message with
    multiple GPA ranges, each of which may contain multiple PFNs. Use
    vmbus_sendpacket_mpb_desc() to send this VMBus message to the host.
    
    There's no functional change since higher levels of netvsc don't
    maintain or propagate knowledge of contiguous PFNs. Based on its
    input, netvsc_build_mpb_array() still produces a separate GPA range
    for each PFN and the behavior is the same as with
    vmbus_sendpacket_pagebuffer(). But the groundwork is laid for a
    subsequent patch to provide the necessary grouping.
    
--------------------------------------------------------------------------------------------

    Drivers: hv: Allow vmbus_sendpacket_mpb_desc() to create multiple ranges
    
    jira LE-3554
    commit-author Michael Kelley <[email protected]>
    commit 380b75d3078626aadd0817de61f3143f5db6e393
    
    vmbus_sendpacket_mpb_desc() is currently used only by the storvsc driver
    and is hardcoded to create a single GPA range. To allow it to also be
    used by the netvsc driver to create multiple GPA ranges, no longer
    hardcode as having a single GPA range. Allow the calling driver to
    specify the rangecount in the supplied descriptor.
    
    Update the storvsc driver to reflect this new approach.
    

Kernel Build

/home/rocky/workspace/kernel-src-tree
Skipping make mrproper
[TIMER]{MRPROPER}: 0s
x86_64 architecture detected, copying config
'configs/kernel-x86_64-rhel.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-HEAD-901c28ff4d62"
Making olddefconfig
#
# configuration written to .config
#
Starting Build
  SYNC    include/config/auto.conf.cmd
mkdir -p /home/rocky/workspace/kernel-src-tree/tools/objtool && make O=/home/rocky/workspace/kernel-src-tree subdir=tools/objtool --no-print-directory -C objtool 
mkdir -p /home/rocky/workspace/kernel-src-tree/tools/bpf/resolve_btfids && make O=/home/rocky/workspace/kernel-src-tree subdir=tools/bpf/resolve_btfids --no-print-directory -C bpf/resolve_btfids 
  INSTALL libsubcmd_headers
  CALL    scripts/atomic/check-atomics.sh
warning: generated include/linux/atomic/atomic-instrumented.h has been modified.
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  CHK     kernel/kheaders_data.tar.xz
  TEST    posttest
arch/x86/tools/insn_decoder_test: success: Decoded and checked 6993310 instructions
  TEST    posttest
arch/x86/tools/insn_sanity: Success: decoded and checked 1000000 random instructions with 0 errors (seed:0xc8873efd)
Kernel: arch/x86/boot/bzImage is ready  (#1)
[TIMER]{BUILD}: 34s
Making Modules
  INSTALL /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/arch/x86/crypto/blake2s-x86_64.ko
  INSTALL /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/arch/x86/crypto/blowfish-x86_64.ko
  INSTALL /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/arch/x86/crypto/camellia-aesni-avx-x86_64.ko
  INSTALL /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/arch/x86/crypto/camellia-aesni-avx2.ko
  INSTALL /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/
  <--snip-->  STRIP   /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/sound/x86/snd-hdmi-lpe-audio.ko
  STRIP   /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/sound/xen/snd_xen_front.ko
  SIGN    /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/sound/usb/usx2y/snd-usb-usx2y.ko
  SIGN    /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/sound/virtio/virtio_snd.ko
  SIGN    /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/sound/usb/snd-usb-audio.ko
  SIGN    /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/sound/x86/snd-hdmi-lpe-audio.ko
  SIGN    /lib/modules/5.14.0-HEAD-901c28ff4d62+/kernel/sound/xen/snd_xen_front.ko
  DEPMOD  /lib/modules/5.14.0-HEAD-901c28ff4d62+
[TIMER]{MODULES}: 8s
Making Install
sh ./arch/x86/boot/install.sh 5.14.0-HEAD-901c28ff4d62+ \
	arch/x86/boot/bzImage System.map "/boot"
[TIMER]{INSTALL}: 25s
Checking kABI
kABI check passed
Setting Default Kernel to /boot/vmlinuz-5.14.0-HEAD-c771763a2b69+ and Index to 3
The default is /boot/loader/entries/ae477367830943118aa3354df0e829b2-5.14.0-HEAD-c771763a2b69+.conf with index 3 and kernel /boot/vmlinuz-5.14.0-HEAD-c771763a2b69+
The default is /boot/loader/entries/ae477367830943118aa3354df0e829b2-5.14.0-HEAD-c771763a2b69+.conf with index 3 and kernel /boot/vmlinuz-5.14.0-HEAD-c771763a2b69+
Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done
Hopefully Grub2.0 took everything ... rebooting after time metrices
[TIMER]{MRPROPER}: 0s
[TIMER]{BUILD}: 34s
[TIMER]{MODULES}: 8s
[TIMER]{INSTALL}: 25s
[TIMER]{TOTAL} 69s
Rebooting in 10 seconds

kernel-build.log

Kselftest

[rocky@shreeya-scn9 workspace]$ grep '^ok ' kselftest-before.log | wc -l && grep '^ok ' kselftest-after.log | wc -l
345
347
[rocky@shreeya-scn9 workspace]$ grep '^not ok ' kselftest-before.log | wc -l && grep '^not ok ' kselftest-after.log | wc -l
82
80

kselftest-after.log
kselftest-before.log

Testing

[rocky@shreeya-scn9 kernel-src-tree]$ lsmod | grep hv_netvsc
hv_netvsc             122880  0
hv_vmbus              188416  8 hv_balloon,hv_utils,hv_netvsc,hid_hyperv,hv_storvsc,hyperv_keyboard,hyperv_drm,pci_hyperv

[rocky@shreeya-scn9 kernel-src-tree]$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 60:45:bd:ef:7a:84 brd ff:ff:ff:ff:ff:ff
    inet 10.3.0.10/24 brd 10.3.0.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::6245:bdff:feef:7a84/64 scope link 
       valid_lft forever preferred_lft forever

[rocky@shreeya-scn9 kernel-src-tree]$ ip route show default
default via 10.3.0.1 dev eth0 proto dhcp src 10.3.0.10 metric 100 
default via 10.3.0.1 dev eth1 proto dhcp src 10.3.0.10 metric 100 
[rocky@shreeya-scn9 kernel-src-tree]$ ping -c 4 10.3.0.10
PING 10.3.0.10 (10.3.0.10) 56(84) bytes of data.
64 bytes from 10.3.0.10: icmp_seq=1 ttl=64 time=0.028 ms
64 bytes from 10.3.0.10: icmp_seq=2 ttl=64 time=0.038 ms
64 bytes from 10.3.0.10: icmp_seq=3 ttl=64 time=0.047 ms
64 bytes from 10.3.0.10: icmp_seq=4 ttl=64 time=0.036 ms

--- 10.3.0.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3073ms
rtt min/avg/max/mdev = 0.028/0.037/0.047/0.006 ms

[rocky@shreeya-scn9 kernel-src-tree]$ ping -c 20 -s 1472 10.3.0.10
PING 10.3.0.10 (10.3.0.10) 1472(1500) bytes of data.
1480 bytes from 10.3.0.10: icmp_seq=1 ttl=64 time=0.029 ms
1480 bytes from 10.3.0.10: icmp_seq=2 ttl=64 time=0.038 ms
1480 bytes from 10.3.0.10: icmp_seq=3 ttl=64 time=0.042 ms
1480 bytes from 10.3.0.10: icmp_seq=4 ttl=64 time=0.035 ms
1480 bytes from 10.3.0.10: icmp_seq=5 ttl=64 time=0.035 ms
1480 bytes from 10.3.0.10: icmp_seq=6 ttl=64 time=0.022 ms
1480 bytes from 10.3.0.10: icmp_seq=7 ttl=64 time=0.037 ms
1480 bytes from 10.3.0.10: icmp_seq=8 ttl=64 time=0.038 ms
1480 bytes from 10.3.0.10: icmp_seq=9 ttl=64 time=0.040 ms
1480 bytes from 10.3.0.10: icmp_seq=10 ttl=64 time=0.043 ms
1480 bytes from 10.3.0.10: icmp_seq=11 ttl=64 time=0.032 ms
1480 bytes from 10.3.0.10: icmp_seq=12 ttl=64 time=0.036 ms
1480 bytes from 10.3.0.10: icmp_seq=13 ttl=64 time=0.039 ms
1480 bytes from 10.3.0.10: icmp_seq=14 ttl=64 time=0.039 ms
1480 bytes from 10.3.0.10: icmp_seq=15 ttl=64 time=0.048 ms
1480 bytes from 10.3.0.10: icmp_seq=16 ttl=64 time=0.047 ms
1480 bytes from 10.3.0.10: icmp_seq=17 ttl=64 time=0.041 ms
1480 bytes from 10.3.0.10: icmp_seq=18 ttl=64 time=0.039 ms
1480 bytes from 10.3.0.10: icmp_seq=19 ttl=64 time=0.046 ms
1480 bytes from 10.3.0.10: icmp_seq=20 ttl=64 time=0.047 ms

--- 10.3.0.10 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19469ms
rtt min/avg/max/mdev = 0.022/0.038/0.048/0.006 ms

[rocky@shreeya-scn9 kernel-src-tree]$ sudo dmesg | grep hv_netvsc
[    2.851798] hv_vmbus: registering driver hv_netvsc
[    2.860647] hv_netvsc f8615163-0000-1000-2000-6045bdef7a84 (unnamed net_device) (uninitialized): VF slot 1 added
[    4.918476] hv_netvsc f8615163-0000-1000-2000-6045bdef7a84 eth0: VF registering: eth1
[    5.606771] hv_netvsc f8615163-0000-1000-2000-6045bdef7a84 eth0: Data path switched to VF: eth1
[    5.682826] hv_netvsc f8615163-0000-1000-2000-6045bdef7a84 eth0: Data path switched from VF: eth1
[    5.887417] hv_netvsc f8615163-0000-1000-2000-6045bdef7a84 eth0: Data path switched to VF: eth1
[rocky@shreeya-scn9 kernel-src-tree]$ 

jira LE-3554
commit-author Michael Kelley <[email protected]>
commit 380b75d

vmbus_sendpacket_mpb_desc() is currently used only by the storvsc driver
and is hardcoded to create a single GPA range. To allow it to also be
used by the netvsc driver to create multiple GPA ranges, no longer
hardcode as having a single GPA range. Allow the calling driver to
specify the rangecount in the supplied descriptor.

Update the storvsc driver to reflect this new approach.

	Cc: <[email protected]> # 6.1.x
	Signed-off-by: Michael Kelley <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 380b75d)
	Signed-off-by: Shreeya Patel <[email protected]>
jira LE-3554
commit-author Michael Kelley <[email protected]>
commit 4f98616

netvsc currently uses vmbus_sendpacket_pagebuffer() to send VMBus
messages. This function creates a series of GPA ranges, each of which
contains a single PFN. However, if the rndis header in the VMBus
message crosses a page boundary, the netvsc protocol with the host
requires that both PFNs for the rndis header must be in a single "GPA
range" data structure, which isn't possible with
vmbus_sendpacket_pagebuffer(). As the first step in fixing this, add a
new function netvsc_build_mpb_array() to build a VMBus message with
multiple GPA ranges, each of which may contain multiple PFNs. Use
vmbus_sendpacket_mpb_desc() to send this VMBus message to the host.

There's no functional change since higher levels of netvsc don't
maintain or propagate knowledge of contiguous PFNs. Based on its
input, netvsc_build_mpb_array() still produces a separate GPA range
for each PFN and the behavior is the same as with
vmbus_sendpacket_pagebuffer(). But the groundwork is laid for a
subsequent patch to provide the necessary grouping.

	Cc: <[email protected]> # 6.1.x
	Signed-off-by: Michael Kelley <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 4f98616)
	Signed-off-by: Shreeya Patel <[email protected]>
jira LE-3554
commit-author Michael Kelley <[email protected]>
commit 41a6328

Starting with commit dca5161 ("hv_netvsc: Check status in
SEND_RNDIS_PKT completion message") in the 6.3 kernel, the Linux
driver for Hyper-V synthetic networking (netvsc) occasionally reports
"nvsp_rndis_pkt_complete error status: 2".[1] This error indicates
that Hyper-V has rejected a network packet transmit request from the
guest, and the outgoing network packet is dropped. Higher level
network protocols presumably recover and resend the packet so there is
no functional error, but performance is slightly impacted. Commit
dca5161 is not the cause of the error -- it only added reporting
of an error that was already happening without any notice. The error
has presumably been present since the netvsc driver was originally
introduced into Linux.

The root cause of the problem is that the netvsc driver in Linux may
send an incorrectly formatted VMBus message to Hyper-V when
transmitting the network packet. The incorrect formatting occurs when
the rndis header of the VMBus message crosses a page boundary due to
how the Linux skb head memory is aligned. In such a case, two PFNs are
required to describe the location of the rndis header, even though
they are contiguous in guest physical address (GPA) space. Hyper-V
requires that two rndis header PFNs be in a single "GPA range" data
struture, but current netvsc code puts each PFN in its own GPA range,
which Hyper-V rejects as an error.

The incorrect formatting occurs only for larger packets that netvsc
must transmit via a VMBus "GPA Direct" message. There's no problem
when netvsc transmits a smaller packet by copying it into a pre-
allocated send buffer slot because the pre-allocated slots don't have
page crossing issues.

After commit 14ad6ed ("net: allow small head cache usage with
large MAX_SKB_FRAGS values") in the 6.14-rc4 kernel, the error occurs
much more frequently in VMs with 16 or more vCPUs. It may occur every
few seconds, or even more frequently, in an ssh session that outputs a
lot of text. Commit 14ad6ed subtly changes how skb head memory is
allocated, making it much more likely that the rndis header will cross
a page boundary when the vCPU count is 16 or more. The changes in
commit 14ad6ed are perfectly valid -- they just had the side
effect of making the netvsc bug more prominent.

Current code in init_page_array() creates a separate page buffer array
entry for each PFN required to identify the data to be transmitted.
Contiguous PFNs get separate entries in the page buffer array, and any
information about contiguity is lost.

Fix the core issue by having init_page_array() construct the page
buffer array to represent contiguous ranges rather than individual
pages. When these ranges are subsequently passed to
netvsc_build_mpb_array(), it can build GPA ranges that contain
multiple PFNs, as required to avoid the error "nvsp_rndis_pkt_complete
error status: 2". If instead the network packet is sent by copying
into a pre-allocated send buffer slot, the copy proceeds using the
contiguous ranges rather than individual pages, but the result of the
copying is the same. Also fix rndis_filter_send_request() to construct
a contiguous range, since it has its own page buffer array.

This change has a side benefit in CoCo VMs in that netvsc_dma_map()
calls dma_map_single() on each contiguous range instead of on each
page. This results in fewer calls to dma_map_single() but on larger
chunks of memory, which should reduce contention on the swiotlb.

Since the page buffer array now contains one entry for each contiguous
range instead of for each individual page, the number of entries in
the array can be reduced, saving 208 bytes of stack space in
netvsc_xmit() when MAX_SKG_FRAGS has the default value of 17.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=217503

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217503
	Cc: <[email protected]> # 6.1.x
	Signed-off-by: Michael Kelley <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 41a6328)
	Signed-off-by: Shreeya Patel <[email protected]>
jira LE-3554
commit-author Michael Kelley <[email protected]>
commit 5bbc644

init_page_array() now always creates a single page buffer array entry
for the rndis message, even if the rndis message crosses a page
boundary. As such, the number of page buffer array entries used for
the rndis message must no longer be tracked -- it is always just 1.
Remove the rmsg_pgcnt field and use "1" where the value is needed.

	Cc: <[email protected]> # 6.1.x
	Signed-off-by: Michael Kelley <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 5bbc644)
	Signed-off-by: Shreeya Patel <[email protected]>
jira LE-3554
commit-author Michael Kelley <[email protected]>
commit 45a442f

With the netvsc driver changed to use vmbus_sendpacket_mpb_desc()
instead of vmbus_sendpacket_pagebuffer(), the latter has no remaining
callers. Remove it.

	Cc: <[email protected]> # 6.1.x
	Signed-off-by: Michael Kelley <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 45a442f)
	Signed-off-by: Shreeya Patel <[email protected]>
Copy link

@jdieter jdieter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@shreeya-patel98 shreeya-patel98 changed the title [LE-3554] Drivers: hv: vmbus: Remove vmbus_sendpacket_pagebuffer() [SIG_CLOUD-9] [LE-3554] Drivers: hv: vmbus: Remove vmbus_sendpacket_pagebuffer() Aug 29, 2025
@shreeya-patel98 shreeya-patel98 changed the title [SIG_CLOUD-9] [LE-3554] Drivers: hv: vmbus: Remove vmbus_sendpacket_pagebuffer() [SIG-CLOUD-9] [LE-3554] Drivers: hv: vmbus: Remove vmbus_sendpacket_pagebuffer() Aug 29, 2025
Copy link
Collaborator

@bmastbergen bmastbergen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

@shreeya-patel98 shreeya-patel98 merged commit 1576230 into sig-cloud-9/5.14.0-570.33.2.el9_6 Aug 30, 2025
4 checks passed
@shreeya-patel98 shreeya-patel98 deleted the {spatel}_sig-cloud-9/5.14.0-570.33.2.el9_6 branch August 30, 2025 17:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants