April 2025 - Linux-stable-mirror

Re: Patch "lib/Kconfig.ubsan: Remove 'default UBSAN' from UBSAN_INTEGER_WRAP" has been added to the 6.14-stable tree

by Kees Cook

On April 26, 2025 6:25:09 AM PDT, Sasha Levin <sashal(a)kernel.org> wrote: >This is a note to let you know that I've just added the patch titled > > lib/Kconfig.ubsan: Remove 'default UBSAN' from UBSAN_INTEGER_WRAP > >to the 6.14-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > >The filename of the patch is: > lib-kconfig.ubsan-remove-default-ubsan-from-ubsan_in.patch >and it can be found in the queue-6.14 subdirectory. > >If you, or anyone else, feels it should not be added to the stable tree, >please let <stable(a)vger.kernel.org> know about it. Please drop this; it's fixing the other patch that should not be backported. :) -Kees -- Kees Cook

6 days, 6 hours

3
5
0 0

[PATCH] securityfs: fix missing of d_delete() in securityfs_remove()

by alexjlzheng＠gmail.com

From: Jinliang Zheng <alexjlzheng(a)tencent.com> Consider the following module code: static struct dentry *dentry; static int __init securityfs_test_init(void) { dentry = securityfs_create_dir("standon", NULL); return PTR_ERR(dentry); } static void __exit securityfs_test_exit(void) { securityfs_remove(dentry); } module_init(securityfs_test_init); module_exit(securityfs_test_exit); and then: insmod /path/to/thismodule cd /sys/kernel/security/standon <- we hold 'standon' rmmod thismodule <- 'standon' don't go away insmod /path/to/thismodule <- Failed: File exists! Fix this by adding d_delete() in securityfs_remove(). Fixes: b67dbf9d4c198 ("[PATCH] add securityfs for all LSMs to use") Signed-off-by: Jinliang Zheng <alexjlzheng(a)tencent.com> Cc: <stable(a)vger.kernel.org> --- security/inode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/security/inode.c b/security/inode.c index da3ab44c8e57..d99baf26350a 100644 --- a/security/inode.c +++ b/security/inode.c @@ -306,6 +306,7 @@ void securityfs_remove(struct dentry *dentry) simple_rmdir(dir, dentry); else simple_unlink(dir, dentry); + d_delete(dentry); dput(dentry); } inode_unlock(dir); -- 2.49.0

6 days, 14 hours

4
4
0 0

Re: Patch "lib/Kconfig.ubsan: Remove 'default UBSAN' from UBSAN_INTEGER_WRAP" has been added to the 6.12-stable tree

by Kees Cook

On April 26, 2025 6:27:11 AM PDT, Sasha Levin <sashal(a)kernel.org> wrote: >This is a note to let you know that I've just added the patch titled > > lib/Kconfig.ubsan: Remove 'default UBSAN' from UBSAN_INTEGER_WRAP > >to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > >The filename of the patch is: > lib-kconfig.ubsan-remove-default-ubsan-from-ubsan_in.patch >and it can be found in the queue-6.12 subdirectory. > >If you, or anyone else, feels it should not be added to the stable tree, >please let <stable(a)vger.kernel.org> know about it. And this too; please drop. :) -Kees -- Kees Cook

6 days, 16 hours

1
0
0 0

Re: Patch "ubsan/overflow: Rework integer overflow sanitizer option to turn on everything" has been added to the 6.12-stable tree

by Kees Cook

On April 26, 2025 6:27:07 AM PDT, Sasha Levin <sashal(a)kernel.org> wrote: >This is a note to let you know that I've just added the patch titled > > ubsan/overflow: Rework integer overflow sanitizer option to turn on everything > >to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > >The filename of the patch is: > ubsan-overflow-rework-integer-overflow-sanitizer-opt.patch >and it can be found in the queue-6.12 subdirectory. > >If you, or anyone else, feels it should not be added to the stable tree, >please let <stable(a)vger.kernel.org> know about it. Same as the other email; please drop. -Kees -- Kees Cook

6 days, 16 hours

1
0
0 0

Re: Patch "ubsan/overflow: Rework integer overflow sanitizer option to turn on everything" has been added to the 6.14-stable tree

by Kees Cook

On April 26, 2025 6:25:06 AM PDT, Sasha Levin <sashal(a)kernel.org> wrote: >This is a note to let you know that I've just added the patch titled > > ubsan/overflow: Rework integer overflow sanitizer option to turn on everything > >to the 6.14-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > >The filename of the patch is: > ubsan-overflow-rework-integer-overflow-sanitizer-opt.patch >and it can be found in the queue-6.14 subdirectory. > >If you, or anyone else, feels it should not be added to the stable tree, >please let <stable(a)vger.kernel.org> know about it. Please drop this; it is a config change and should not be backported. -Kees -- Kees Cook

6 days, 16 hours

1
0
0 0

FAILED: patch "[PATCH] s390/virtio_ccw: Don't allocate/assign airqs for non-existing" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 2ccd42b959aaf490333dbd3b9b102eaf295c036a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025041736-abrasion-yonder-b301@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2ccd42b959aaf490333dbd3b9b102eaf295c036a Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Wed, 2 Apr 2025 22:36:21 +0200 Subject: [PATCH] s390/virtio_ccw: Don't allocate/assign airqs for non-existing queues If we finds a vq without a name in our input array in virtio_ccw_find_vqs(), we treat it as "non-existing" and set the vq pointer to NULL; we will not call virtio_ccw_setup_vq() to allocate/setup a vq. Consequently, we create only a queue if it actually exists (name != NULL) and assign an incremental queue index to each such existing queue. However, in virtio_ccw_register_adapter_ind()->get_airq_indicator() we will not ignore these "non-existing queues", but instead assign an airq indicator to them. Besides never releasing them in virtio_ccw_drop_indicators() (because there is no virtqueue), the bigger issue seems to be that there will be a disagreement between the device and the Linux guest about the airq indicator to be used for notifying a queue, because the indicator bit for adapter I/O interrupt is derived from the queue index. The virtio spec states under "Setting Up Two-Stage Queue Indicators": ... indicator contains the guest address of an area wherein the indicators for the devices are contained, starting at bit_nr, one bit per virtqueue of the device. And further in "Notification via Adapter I/O Interrupts": For notifying the driver of virtqueue buffers, the device sets the bit in the guest-provided indicator area at the corresponding offset. For example, QEMU uses in virtio_ccw_notify() the queue index (passed as "vector") to select the relevant indicator bit. If a queue does not exist, it does not have a corresponding indicator bit assigned, because it effectively doesn't have a queue index. Using a virtio-balloon-ccw device under QEMU with free-page-hinting disabled ("free-page-hint=off") but free-page-reporting enabled ("free-page-reporting=on") will result in free page reporting not working as expected: in the virtio_balloon driver, we'll be stuck forever in virtballoon_free_page_report()->wait_event(), because the waitqueue will not be woken up as the notification from the device is lost: it would use the wrong indicator bit. Free page reporting stops working and we get splats (when configured to detect hung wqs) like: INFO: task kworker/1:3:463 blocked for more than 61 seconds. Not tainted 6.14.0 #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:3 [...] Workqueue: events page_reporting_process Call Trace: [<000002f404e6dfb2>] __schedule+0x402/0x1640 [<000002f404e6f22e>] schedule+0x3e/0xe0 [<000002f3846a88fa>] virtballoon_free_page_report+0xaa/0x110 [virtio_balloon] [<000002f40435c8a4>] page_reporting_process+0x2e4/0x740 [<000002f403fd3ee2>] process_one_work+0x1c2/0x400 [<000002f403fd4b96>] worker_thread+0x296/0x420 [<000002f403fe10b4>] kthread+0x124/0x290 [<000002f403f4e0dc>] __ret_from_fork+0x3c/0x60 [<000002f404e77272>] ret_from_fork+0xa/0x38 There was recently a discussion [1] whether the "holes" should be treated differently again, effectively assigning also non-existing queues a queue index: that should also fix the issue, but requires other workarounds to not break existing setups. Let's fix it without affecting existing setups for now by properly ignoring the non-existing queues, so the indicator bits will match the queue indexes. [1] https://lore.kernel.org/all/cover.1720611677.git.mst@redhat.com/ Fixes: a229989d975e ("virtio: don't allocate vqs when names[i] = NULL") Reported-by: Chandra Merla <cmerla(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: David Hildenbrand <david(a)redhat.com> Tested-by: Thomas Huth <thuth(a)redhat.com> Reviewed-by: Thomas Huth <thuth(a)redhat.com> Reviewed-by: Cornelia Huck <cohuck(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Acked-by: Christian Borntraeger <borntraeger(a)linux.ibm.com> Link: https://lore.kernel.org/r/20250402203621.940090-1-david@redhat.com Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com> diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index 21fa7ac849e5..4904b831c0a7 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -302,11 +302,17 @@ static struct airq_info *new_airq_info(int index) static unsigned long *get_airq_indicator(struct virtqueue *vqs[], int nvqs, u64 *first, void **airq_info) { - int i, j; + int i, j, queue_idx, highest_queue_idx = -1; struct airq_info *info; unsigned long *indicator_addr = NULL; unsigned long bit, flags; + /* Array entries without an actual queue pointer must be ignored. */ + for (i = 0; i < nvqs; i++) { + if (vqs[i]) + highest_queue_idx++; + } + for (i = 0; i < MAX_AIRQ_AREAS && !indicator_addr; i++) { mutex_lock(&airq_areas_lock); if (!airq_areas[i]) @@ -316,7 +322,7 @@ static unsigned long *get_airq_indicator(struct virtqueue *vqs[], int nvqs, if (!info) return NULL; write_lock_irqsave(&info->lock, flags); - bit = airq_iv_alloc(info->aiv, nvqs); + bit = airq_iv_alloc(info->aiv, highest_queue_idx + 1); if (bit == -1UL) { /* Not enough vacancies. */ write_unlock_irqrestore(&info->lock, flags); @@ -325,8 +331,10 @@ static unsigned long *get_airq_indicator(struct virtqueue *vqs[], int nvqs, *first = bit; *airq_info = info; indicator_addr = info->aiv->vector; - for (j = 0; j < nvqs; j++) { - airq_iv_set_ptr(info->aiv, bit + j, + for (j = 0, queue_idx = 0; j < nvqs; j++) { + if (!vqs[j]) + continue; + airq_iv_set_ptr(info->aiv, bit + queue_idx++, (unsigned long)vqs[j]); } write_unlock_irqrestore(&info->lock, flags);

6 days, 16 hours

3
2
0 0

[PATCH stable 6.12 0/4] Fix xdp_devmap_attach failure in BPF selftests

by Shung-Hsi Yu

This patchset backport commit to fix BPF selftests failure in stable 6.12 since commit 972bafed67ca ("bpf, test_run: Fix use-after-free issue in eth_skb_pkt_type()"), which is backport of upstream commit 6b3d638ca897. The fix needed is upstream commit c7f2188d68c1 ("selftests/bpf: Adjust data size to have ETH_HLEN"), which in turn depends on upstream commit d5fbcf46ee82 "selftests/bpf: make xdp_cpumap_attach keep redirect prog attached". Latter is part of "selftests/bpf: add coverage for xdp_features in test_progs"[1], and I opt to backport the series entirely since it adds coverage. With these patches the xdp_devmap_attach no longer fails[2]. BPF selftests failure log below for completeness. See [3] for the raw log. Error: #566 xdp_devmap_attach Error: #566/1 xdp_devmap_attach/DEVMAP with programs in entries test_xdp_with_devmap_helpers:PASS:ip netns add devmap_attach_ns 0 nsec test_xdp_with_devmap_helpers:PASS:open_netns 0 nsec test_xdp_with_devmap_helpers:PASS:ip link set dev lo up 0 nsec test_xdp_with_devmap_helpers:PASS:test_xdp_with_devmap_helpers__open_and_load 0 nsec test_xdp_with_devmap_helpers:PASS:Generic attach of program with 8-byte devmap 0 nsec test_xdp_with_devmap_helpers:PASS:bpf_prog_get_info_by_fd 0 nsec test_xdp_with_devmap_helpers:PASS:Add program to devmap entry 0 nsec test_xdp_with_devmap_helpers:PASS:Read devmap entry 0 nsec test_xdp_with_devmap_helpers:PASS:Match program id to devmap entry prog_id 0 nsec test_xdp_with_devmap_helpers:FAIL:XDP test run unexpected error: -22 (errno 22) test_xdp_with_devmap_helpers:PASS:XDP program detach 0 nsec libbpf: Kernel error message: BPF_XDP_DEVMAP programs can not be attached to a device test_xdp_with_devmap_helpers:PASS:Attach of BPF_XDP_DEVMAP program 0 nsec test_xdp_with_devmap_helpers:PASS:Add non-BPF_XDP_DEVMAP program to devmap entry 0 nsec test_xdp_with_devmap_helpers:PASS:Add BPF_XDP program with frags to devmap entry 0 nsec Error: #566/4 xdp_devmap_attach/DEVMAP with programs in entries on veth test_xdp_with_devmap_helpers_veth:PASS:ip netns add devmap_attach_ns 0 nsec test_xdp_with_devmap_helpers_veth:PASS:open_netns 0 nsec test_xdp_with_devmap_helpers_veth:PASS:ip link add veth_src type veth peer name veth_dst 0 nsec test_xdp_with_devmap_helpers_veth:PASS:ip link set dev veth_src up 0 nsec test_xdp_with_devmap_helpers_veth:PASS:ip link set dev veth_dst up 0 nsec test_xdp_with_devmap_helpers_veth:PASS:val.ifindex 0 nsec test_xdp_with_devmap_helpers_veth:PASS:ifindex_dst 0 nsec test_xdp_with_devmap_helpers_veth:PASS:test_xdp_with_devmap_helpers__open_and_load 0 nsec test_xdp_with_devmap_helpers_veth:PASS:Attach of program with 8-byte devmap 0 nsec test_xdp_with_devmap_helpers_veth:PASS:bpf_prog_get_info_by_fd 0 nsec test_xdp_with_devmap_helpers_veth:PASS:Add program to devmap entry 0 nsec test_xdp_with_devmap_helpers_veth:PASS:Read devmap entry 0 nsec test_xdp_with_devmap_helpers_veth:PASS:Match program id to devmap entry prog_id 0 nsec test_xdp_with_devmap_helpers_veth:PASS:Attach of dummy XDP 0 nsec test_xdp_with_devmap_helpers_veth:FAIL:XDP test run unexpected error: -22 (errno 22) test_xdp_with_devmap_helpers_veth:PASS:XDP program detach 0 nsec test_xdp_with_devmap_helpers_veth:PASS:XDP program detach 0 nsec 1: https://lore.kernel.org/all/20241009-convert_xdp_tests-v3-0-51cea913710c@bo… 2: https://github.com/shunghsiyu/libbpf/actions/runs/14569651139/job/408644287… 3: https://github.com/shunghsiyu/libbpf/actions/runs/14562221313/job/408469275… Alexis Lothoré (eBPF Foundation) (3): selftests/bpf: fix bpf_map_redirect call for cpu map test selftests/bpf: make xdp_cpumap_attach keep redirect prog attached selftests/bpf: check program redirect in xdp_cpumap_attach Shigeru Yoshida (1): selftests/bpf: Adjust data size to have ETH_HLEN .../bpf/prog_tests/xdp_cpumap_attach.c | 44 +++++++++++++++---- .../bpf/prog_tests/xdp_devmap_attach.c | 8 ++-- .../bpf/progs/test_xdp_with_cpumap_helpers.c | 7 ++- 3 files changed, 46 insertions(+), 13 deletions(-) -- 2.49.0

6 days, 16 hours

2
8
0 0

FAILED: patch "[PATCH] s390/virtio_ccw: Don't allocate/assign airqs for non-existing" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 2ccd42b959aaf490333dbd3b9b102eaf295c036a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025041737-impart-slacker-8722@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2ccd42b959aaf490333dbd3b9b102eaf295c036a Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Wed, 2 Apr 2025 22:36:21 +0200 Subject: [PATCH] s390/virtio_ccw: Don't allocate/assign airqs for non-existing queues If we finds a vq without a name in our input array in virtio_ccw_find_vqs(), we treat it as "non-existing" and set the vq pointer to NULL; we will not call virtio_ccw_setup_vq() to allocate/setup a vq. Consequently, we create only a queue if it actually exists (name != NULL) and assign an incremental queue index to each such existing queue. However, in virtio_ccw_register_adapter_ind()->get_airq_indicator() we will not ignore these "non-existing queues", but instead assign an airq indicator to them. Besides never releasing them in virtio_ccw_drop_indicators() (because there is no virtqueue), the bigger issue seems to be that there will be a disagreement between the device and the Linux guest about the airq indicator to be used for notifying a queue, because the indicator bit for adapter I/O interrupt is derived from the queue index. The virtio spec states under "Setting Up Two-Stage Queue Indicators": ... indicator contains the guest address of an area wherein the indicators for the devices are contained, starting at bit_nr, one bit per virtqueue of the device. And further in "Notification via Adapter I/O Interrupts": For notifying the driver of virtqueue buffers, the device sets the bit in the guest-provided indicator area at the corresponding offset. For example, QEMU uses in virtio_ccw_notify() the queue index (passed as "vector") to select the relevant indicator bit. If a queue does not exist, it does not have a corresponding indicator bit assigned, because it effectively doesn't have a queue index. Using a virtio-balloon-ccw device under QEMU with free-page-hinting disabled ("free-page-hint=off") but free-page-reporting enabled ("free-page-reporting=on") will result in free page reporting not working as expected: in the virtio_balloon driver, we'll be stuck forever in virtballoon_free_page_report()->wait_event(), because the waitqueue will not be woken up as the notification from the device is lost: it would use the wrong indicator bit. Free page reporting stops working and we get splats (when configured to detect hung wqs) like: INFO: task kworker/1:3:463 blocked for more than 61 seconds. Not tainted 6.14.0 #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:3 [...] Workqueue: events page_reporting_process Call Trace: [<000002f404e6dfb2>] __schedule+0x402/0x1640 [<000002f404e6f22e>] schedule+0x3e/0xe0 [<000002f3846a88fa>] virtballoon_free_page_report+0xaa/0x110 [virtio_balloon] [<000002f40435c8a4>] page_reporting_process+0x2e4/0x740 [<000002f403fd3ee2>] process_one_work+0x1c2/0x400 [<000002f403fd4b96>] worker_thread+0x296/0x420 [<000002f403fe10b4>] kthread+0x124/0x290 [<000002f403f4e0dc>] __ret_from_fork+0x3c/0x60 [<000002f404e77272>] ret_from_fork+0xa/0x38 There was recently a discussion [1] whether the "holes" should be treated differently again, effectively assigning also non-existing queues a queue index: that should also fix the issue, but requires other workarounds to not break existing setups. Let's fix it without affecting existing setups for now by properly ignoring the non-existing queues, so the indicator bits will match the queue indexes. [1] https://lore.kernel.org/all/cover.1720611677.git.mst@redhat.com/ Fixes: a229989d975e ("virtio: don't allocate vqs when names[i] = NULL") Reported-by: Chandra Merla <cmerla(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: David Hildenbrand <david(a)redhat.com> Tested-by: Thomas Huth <thuth(a)redhat.com> Reviewed-by: Thomas Huth <thuth(a)redhat.com> Reviewed-by: Cornelia Huck <cohuck(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Acked-by: Christian Borntraeger <borntraeger(a)linux.ibm.com> Link: https://lore.kernel.org/r/20250402203621.940090-1-david@redhat.com Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com> diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index 21fa7ac849e5..4904b831c0a7 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -302,11 +302,17 @@ static struct airq_info *new_airq_info(int index) static unsigned long *get_airq_indicator(struct virtqueue *vqs[], int nvqs, u64 *first, void **airq_info) { - int i, j; + int i, j, queue_idx, highest_queue_idx = -1; struct airq_info *info; unsigned long *indicator_addr = NULL; unsigned long bit, flags; + /* Array entries without an actual queue pointer must be ignored. */ + for (i = 0; i < nvqs; i++) { + if (vqs[i]) + highest_queue_idx++; + } + for (i = 0; i < MAX_AIRQ_AREAS && !indicator_addr; i++) { mutex_lock(&airq_areas_lock); if (!airq_areas[i]) @@ -316,7 +322,7 @@ static unsigned long *get_airq_indicator(struct virtqueue *vqs[], int nvqs, if (!info) return NULL; write_lock_irqsave(&info->lock, flags); - bit = airq_iv_alloc(info->aiv, nvqs); + bit = airq_iv_alloc(info->aiv, highest_queue_idx + 1); if (bit == -1UL) { /* Not enough vacancies. */ write_unlock_irqrestore(&info->lock, flags); @@ -325,8 +331,10 @@ static unsigned long *get_airq_indicator(struct virtqueue *vqs[], int nvqs, *first = bit; *airq_info = info; indicator_addr = info->aiv->vector; - for (j = 0; j < nvqs; j++) { - airq_iv_set_ptr(info->aiv, bit + j, + for (j = 0, queue_idx = 0; j < nvqs; j++) { + if (!vqs[j]) + continue; + airq_iv_set_ptr(info->aiv, bit + queue_idx++, (unsigned long)vqs[j]); } write_unlock_irqrestore(&info->lock, flags);

6 days, 16 hours

3
2
0 0

[PATCH stable 6.12 6.14 1/1] selftests/bpf: Mitigate sockmap_ktls disconnect_after_delete failure

by Shung-Hsi Yu

From: Ihor Solodrai <ihor.solodrai(a)linux.dev> commit 5071a1e606b30c0c11278d3c6620cd6a24724cf6 upstream. "sockmap_ktls disconnect_after_delete" test has been failing on BPF CI after recent merges from netdev: * https://github.com/kernel-patches/bpf/actions/runs/14458537639 * https://github.com/kernel-patches/bpf/actions/runs/14457178732 It happens because disconnect has been disabled for TLS [1], and it renders the test case invalid. Removing all the test code creates a conflict between bpf and bpf-next, so for now only remove the offending assert [2]. The test will be removed later on bpf-next. [1] https://lore.kernel.org/netdev/20250404180334.3224206-1-kuba@kernel.org/ [2] https://lore.kernel.org/bpf/cfc371285323e1a3f3b006bfcf74e6cf7ad65258@linux.… Signed-off-by: Ihor Solodrai <ihor.solodrai(a)linux.dev> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Reviewed-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> Link: https://lore.kernel.org/bpf/20250416170246.2438524-1-ihor.solodrai@linux.dev [ shung-hsi.yu: needed because upstream commit 5071a1e606b3 ("net: tls: explicitly disallow disconnect") is backported ] Signed-off-by: Shung-Hsi Yu <shung-hsi.yu(a)suse.com> --- tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c b/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c index 2d0796314862..0a99fd404f6d 100644 --- a/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c @@ -68,7 +68,6 @@ static void test_sockmap_ktls_disconnect_after_delete(int family, int map) goto close_cli; err = disconnect(cli); - ASSERT_OK(err, "disconnect"); close_cli: close(cli); -- 2.49.0

6 days, 16 hours

3
5
0 0

[PATCH 5.10.y] perf/x86/intel/uncore: Fix the scale of IIO free running counters on SNR

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> [ Upstream commit 96a720db59ab330c8562b2437153faa45dac705f ] (The existing patch in queue-5.10 was wrong. queue-5.10/perf-x86-intel-uncore-fix-the-scale-of-iio-free-running-counters-on-snr.patch It's supposed to change the array snr_uncore_iio_freerunning_events[] rather than icx_uncore_iio_freerunning_events[]. Send the patch to replace the wrong one. With this fix the https://lore.kernel.org/stable/2025042139-protector-rickety-a72d@gregkh/ can be applied then.) There was a mistake in the SNR uncore spec. The counter increments for every 32 bytes of data sent from the IO agent to the SOC, not 4 bytes which was documented in the spec. The event list has been updated: "EventName": "UNC_IIO_BANDWIDTH_IN.PART0_FREERUN", "BriefDescription": "Free running counter that increments for every 32 bytes of data sent from the IO agent to the SOC", Update the scale of the IIO bandwidth in free running counters as well. Fixes: 210cc5f9db7a ("perf/x86/intel/uncore: Add uncore support for Snow Ridge server") Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Acked-by: Peter Zijlstra <a.p.zijlstra(a)chello.nl> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20250416142426.3933977-1-kan.liang@linux.intel.com --- arch/x86/events/intel/uncore_snbep.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c index ad084a5a1463..dd70a6b7879b 100644 --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -4487,28 +4487,28 @@ static struct uncore_event_desc snr_uncore_iio_freerunning_events[] = { INTEL_UNCORE_EVENT_DESC(ioclk, "event=0xff,umask=0x10"), /* Free-Running IIO BANDWIDTH IN Counters */ INTEL_UNCORE_EVENT_DESC(bw_in_port0, "event=0xff,umask=0x20"), - INTEL_UNCORE_EVENT_DESC(bw_in_port0.scale, "3.814697266e-6"), + INTEL_UNCORE_EVENT_DESC(bw_in_port0.scale, "3.0517578125e-5"), INTEL_UNCORE_EVENT_DESC(bw_in_port0.unit, "MiB"), INTEL_UNCORE_EVENT_DESC(bw_in_port1, "event=0xff,umask=0x21"), - INTEL_UNCORE_EVENT_DESC(bw_in_port1.scale, "3.814697266e-6"), + INTEL_UNCORE_EVENT_DESC(bw_in_port1.scale, "3.0517578125e-5"), INTEL_UNCORE_EVENT_DESC(bw_in_port1.unit, "MiB"), INTEL_UNCORE_EVENT_DESC(bw_in_port2, "event=0xff,umask=0x22"), - INTEL_UNCORE_EVENT_DESC(bw_in_port2.scale, "3.814697266e-6"), + INTEL_UNCORE_EVENT_DESC(bw_in_port2.scale, "3.0517578125e-5"), INTEL_UNCORE_EVENT_DESC(bw_in_port2.unit, "MiB"), INTEL_UNCORE_EVENT_DESC(bw_in_port3, "event=0xff,umask=0x23"), - INTEL_UNCORE_EVENT_DESC(bw_in_port3.scale, "3.814697266e-6"), + INTEL_UNCORE_EVENT_DESC(bw_in_port3.scale, "3.0517578125e-5"), INTEL_UNCORE_EVENT_DESC(bw_in_port3.unit, "MiB"), INTEL_UNCORE_EVENT_DESC(bw_in_port4, "event=0xff,umask=0x24"), - INTEL_UNCORE_EVENT_DESC(bw_in_port4.scale, "3.814697266e-6"), + INTEL_UNCORE_EVENT_DESC(bw_in_port4.scale, "3.0517578125e-5"), INTEL_UNCORE_EVENT_DESC(bw_in_port4.unit, "MiB"), INTEL_UNCORE_EVENT_DESC(bw_in_port5, "event=0xff,umask=0x25"), - INTEL_UNCORE_EVENT_DESC(bw_in_port5.scale, "3.814697266e-6"), + INTEL_UNCORE_EVENT_DESC(bw_in_port5.scale, "3.0517578125e-5"), INTEL_UNCORE_EVENT_DESC(bw_in_port5.unit, "MiB"), INTEL_UNCORE_EVENT_DESC(bw_in_port6, "event=0xff,umask=0x26"), - INTEL_UNCORE_EVENT_DESC(bw_in_port6.scale, "3.814697266e-6"), + INTEL_UNCORE_EVENT_DESC(bw_in_port6.scale, "3.0517578125e-5"), INTEL_UNCORE_EVENT_DESC(bw_in_port6.unit, "MiB"), INTEL_UNCORE_EVENT_DESC(bw_in_port7, "event=0xff,umask=0x27"), - INTEL_UNCORE_EVENT_DESC(bw_in_port7.scale, "3.814697266e-6"), + INTEL_UNCORE_EVENT_DESC(bw_in_port7.scale, "3.0517578125e-5"), INTEL_UNCORE_EVENT_DESC(bw_in_port7.unit, "MiB"), { /* end: all zeroes */ }, }; -- 2.38.1

6 days, 16 hours

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2025