- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] media: Revert "media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()"
by Zheng Yejian 20 Sep '24

20 Sep '24

From: Sean Young <sean(a)mess.org> stable inclusion from stable-v5.10.224 commit 2de18b5cc38e83428316d6d6d05a702208fb299b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAS2LK Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 0c84bde4f37ba27d50e4c70ecacd33fe4a57030d upstream. This reverts commit 2052138b7da52ad5ccaf74f736d00f39a1c9198c. This breaks the TeVii s480 dual DVB-S2 S660. The device has a bulk in endpoint but no corresponding out endpoint, so the device does not pass the "has both receive and send bulk endpoint" test. Seemingly this device does not use dvb_usb_generic_rw() so I have tried removing the generic_bulk_ctrl_endpoint entry, but this resulted in different problems. As we have no explanation yet, revert. $ dmesg | grep -i -e dvb -e dw21 -e usb\ 4 [ 0.999122] usb 1-1: new high-speed USB device number 2 using ehci-pci [ 1.023123] usb 4-1: new high-speed USB device number 2 using ehci-pci [ 1.130247] usb 1-1: New USB device found, idVendor=9022, idProduct=d482, +bcdDevice= 0.01 [ 1.130257] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 1.152323] usb 4-1: New USB device found, idVendor=9022, idProduct=d481, +bcdDevice= 0.01 [ 1.152329] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 6.701033] dvb-usb: found a 'TeVii S480.2 USB' in cold state, will try to +load a firmware [ 6.701178] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' [ 6.701179] dw2102: start downloading DW210X firmware [ 6.703715] dvb-usb: found a 'Microsoft Xbox One Digital TV Tuner' in cold +state, will try to load a firmware [ 6.703974] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [ 6.756432] usb 1-1: USB disconnect, device number 2 [ 6.862119] dvb-usb: found a 'TeVii S480.2 USB' in warm state. [ 6.862194] dvb-usb: TeVii S480.2 USB error while loading driver (-22) [ 6.862209] dvb-usb: found a 'TeVii S480.1 USB' in cold state, will try to +load a firmware [ 6.862244] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' [ 6.862245] dw2102: start downloading DW210X firmware [ 6.914811] usb 4-1: USB disconnect, device number 2 [ 7.014131] dvb-usb: found a 'TeVii S480.1 USB' in warm state. [ 7.014487] dvb-usb: TeVii S480.1 USB error while loading driver (-22) [ 7.014538] usbcore: registered new interface driver dw2102 Closes: https://lore.kernel.org/stable/20240801165146.38991f60@mir/ Fixes: 2052138b7da5 ("media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()") Reported-by: Stefan Lippers-Hollmann <s.l-h(a)gmx.de> Cc: stable(a)vger.kernel.org Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/media/usb/dvb-usb/dvb-usb-init.c | 35 +++--------------------- 1 file changed, 4 insertions(+), 31 deletions(-) diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c b/drivers/media/usb/dvb-usb/dvb-usb-init.c index 6cf6d08cc4ec..58eea8ab5477 100644 --- a/drivers/media/usb/dvb-usb/dvb-usb-init.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c @@ -23,40 +23,11 @@ static int dvb_usb_force_pid_filter_usage; module_param_named(force_pid_filter_usage, dvb_usb_force_pid_filter_usage, int, 0444); MODULE_PARM_DESC(force_pid_filter_usage, "force all dvb-usb-devices to use a PID filter, if any (default: 0)."); -static int dvb_usb_check_bulk_endpoint(struct dvb_usb_device *d, u8 endpoint) -{ - if (endpoint) { - int ret; - - ret = usb_pipe_type_check(d->udev, usb_sndbulkpipe(d->udev, endpoint)); - if (ret) - return ret; - ret = usb_pipe_type_check(d->udev, usb_rcvbulkpipe(d->udev, endpoint)); - if (ret) - return ret; - } - return 0; -} - -static void dvb_usb_clear_halt(struct dvb_usb_device *d, u8 endpoint) -{ - if (endpoint) { - usb_clear_halt(d->udev, usb_sndbulkpipe(d->udev, endpoint)); - usb_clear_halt(d->udev, usb_rcvbulkpipe(d->udev, endpoint)); - } -} - static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs) { struct dvb_usb_adapter *adap; int ret, n, o; - ret = dvb_usb_check_bulk_endpoint(d, d->props.generic_bulk_ctrl_endpoint); - if (ret) - return ret; - ret = dvb_usb_check_bulk_endpoint(d, d->props.generic_bulk_ctrl_endpoint_response); - if (ret) - return ret; for (n = 0; n < d->props.num_adapters; n++) { adap = &d->adapter[n]; adap->dev = d; @@ -132,8 +103,10 @@ static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs) * when reloading the driver w/o replugging the device * sometimes a timeout occurs, this helps */ - dvb_usb_clear_halt(d, d->props.generic_bulk_ctrl_endpoint); - dvb_usb_clear_halt(d, d->props.generic_bulk_ctrl_endpoint_response); + if (d->props.generic_bulk_ctrl_endpoint != 0) { + usb_clear_halt(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); + usb_clear_halt(d->udev, usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); + } return 0; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] media: Revert "media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()"
by Zheng Yejian 20 Sep '24

20 Sep '24

From: Sean Young <sean(a)mess.org> stable inclusion from stable-v5.10.224 commit 2de18b5cc38e83428316d6d6d05a702208fb299b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAS2LK Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 0c84bde4f37ba27d50e4c70ecacd33fe4a57030d upstream. This reverts commit 2052138b7da52ad5ccaf74f736d00f39a1c9198c. This breaks the TeVii s480 dual DVB-S2 S660. The device has a bulk in endpoint but no corresponding out endpoint, so the device does not pass the "has both receive and send bulk endpoint" test. Seemingly this device does not use dvb_usb_generic_rw() so I have tried removing the generic_bulk_ctrl_endpoint entry, but this resulted in different problems. As we have no explanation yet, revert. $ dmesg | grep -i -e dvb -e dw21 -e usb\ 4 [ 0.999122] usb 1-1: new high-speed USB device number 2 using ehci-pci [ 1.023123] usb 4-1: new high-speed USB device number 2 using ehci-pci [ 1.130247] usb 1-1: New USB device found, idVendor=9022, idProduct=d482, +bcdDevice= 0.01 [ 1.130257] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 1.152323] usb 4-1: New USB device found, idVendor=9022, idProduct=d481, +bcdDevice= 0.01 [ 1.152329] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 6.701033] dvb-usb: found a 'TeVii S480.2 USB' in cold state, will try to +load a firmware [ 6.701178] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' [ 6.701179] dw2102: start downloading DW210X firmware [ 6.703715] dvb-usb: found a 'Microsoft Xbox One Digital TV Tuner' in cold +state, will try to load a firmware [ 6.703974] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [ 6.756432] usb 1-1: USB disconnect, device number 2 [ 6.862119] dvb-usb: found a 'TeVii S480.2 USB' in warm state. [ 6.862194] dvb-usb: TeVii S480.2 USB error while loading driver (-22) [ 6.862209] dvb-usb: found a 'TeVii S480.1 USB' in cold state, will try to +load a firmware [ 6.862244] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' [ 6.862245] dw2102: start downloading DW210X firmware [ 6.914811] usb 4-1: USB disconnect, device number 2 [ 7.014131] dvb-usb: found a 'TeVii S480.1 USB' in warm state. [ 7.014487] dvb-usb: TeVii S480.1 USB error while loading driver (-22) [ 7.014538] usbcore: registered new interface driver dw2102 Closes: https://lore.kernel.org/stable/20240801165146.38991f60@mir/ Fixes: 2052138b7da5 ("media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()") Reported-by: Stefan Lippers-Hollmann <s.l-h(a)gmx.de> Cc: stable(a)vger.kernel.org Conflicts: drivers/media/usb/dvb-usb/dvb-usb-init.c [Resolve conflicts due to changes in comments] Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/media/usb/dvb-usb/dvb-usb-init.c | 35 +++--------------------- 1 file changed, 4 insertions(+), 31 deletions(-) diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c b/drivers/media/usb/dvb-usb/dvb-usb-init.c index 04af78316efd..39ac22486bcd 100644 --- a/drivers/media/usb/dvb-usb/dvb-usb-init.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c @@ -26,40 +26,11 @@ static int dvb_usb_force_pid_filter_usage; module_param_named(force_pid_filter_usage, dvb_usb_force_pid_filter_usage, int, 0444); MODULE_PARM_DESC(force_pid_filter_usage, "force all dvb-usb-devices to use a PID filter, if any (default: 0)."); -static int dvb_usb_check_bulk_endpoint(struct dvb_usb_device *d, u8 endpoint) -{ - if (endpoint) { - int ret; - - ret = usb_pipe_type_check(d->udev, usb_sndbulkpipe(d->udev, endpoint)); - if (ret) - return ret; - ret = usb_pipe_type_check(d->udev, usb_rcvbulkpipe(d->udev, endpoint)); - if (ret) - return ret; - } - return 0; -} - -static void dvb_usb_clear_halt(struct dvb_usb_device *d, u8 endpoint) -{ - if (endpoint) { - usb_clear_halt(d->udev, usb_sndbulkpipe(d->udev, endpoint)); - usb_clear_halt(d->udev, usb_rcvbulkpipe(d->udev, endpoint)); - } -} - static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs) { struct dvb_usb_adapter *adap; int ret, n, o; - ret = dvb_usb_check_bulk_endpoint(d, d->props.generic_bulk_ctrl_endpoint); - if (ret) - return ret; - ret = dvb_usb_check_bulk_endpoint(d, d->props.generic_bulk_ctrl_endpoint_response); - if (ret) - return ret; for (n = 0; n < d->props.num_adapters; n++) { adap = &d->adapter[n]; adap->dev = d; @@ -129,8 +100,10 @@ static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs) * when reloading the driver w/o replugging the device * sometimes a timeout occures, this helps */ - dvb_usb_clear_halt(d, d->props.generic_bulk_ctrl_endpoint); - dvb_usb_clear_halt(d, d->props.generic_bulk_ctrl_endpoint_response); + if (d->props.generic_bulk_ctrl_endpoint != 0) { + usb_clear_halt(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); + usb_clear_halt(d->udev, usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint)); + } return 0; } -- 2.25.1

2 1

[openeuler:openEuler-1.0-LTS 18192/23720] mm/memory.c:1546:10: error: implicit declaration of function 'hugetlb_insert_hugepage_pte_by_pa'
by kernel test robot 20 Sep '24

20 Sep '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: bacbf9a9f0df34d979a8029d5a7a7e5dc91460b9 commit: 18f49509eef01d1ee6ed81899298994f2f88dd2a [18192/23720] ascend: share_pool: Use remap_pfn_range to share kva to uva config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20240920/202409201222.m2Vt8TXh-lkp@…) compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240920/202409201222.m2Vt8TXh-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202409201222.m2Vt8TXh-lkp@intel.com/ All errors (new ones prefixed by >>): In file included from mm/memory.c:51: include/linux/pagemap.h:425:21: warning: cast from 'int (*)(struct file *, struct page *)' to 'filler_t *' (aka 'int (*)(void *, struct page *)') converts to incompatible function type [-Wcast-function-type-strict] 425 | filler_t *filler = (filler_t *)mapping->a_ops->readpage; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> mm/memory.c:1546:10: error: implicit declaration of function 'hugetlb_insert_hugepage_pte_by_pa' [-Werror,-Wimplicit-function-declaration] 1546 | return hugetlb_insert_hugepage_pte_by_pa(vma->vm_mm, addr, | ^ mm/memory.c:1546:10: note: did you mean 'hugetlb_insert__hugepage_pte_by_pa'? include/linux/hugetlb.h:658:19: note: 'hugetlb_insert__hugepage_pte_by_pa' declared here 658 | static inline int hugetlb_insert__hugepage_pte_by_pa(struct mm_struct *mm, | ^ 1 warning and 1 error generated. vim +/hugetlb_insert_hugepage_pte_by_pa +1546 mm/memory.c 1504 1505 /** 1506 * vm_insert_page - insert single page into user vma 1507 * @vma: user vma to map to 1508 * @addr: target user address of this page 1509 * @page: source kernel page 1510 * 1511 * This allows drivers to insert individual pages they've allocated 1512 * into a user vma. 1513 * 1514 * The page has to be a nice clean _individual_ kernel allocation. 1515 * If you allocate a compound page, you need to have marked it as 1516 * such (__GFP_COMP), or manually just split the page up yourself 1517 * (see split_page()). 1518 * 1519 * NOTE! Traditionally this was done with "remap_pfn_range()" which 1520 * took an arbitrary page protection parameter. This doesn't allow 1521 * that. Your vma protection will have to be set up correctly, which 1522 * means that if you want a shared writable mapping, you'd better 1523 * ask for a shared writable mapping! 1524 * 1525 * The page does not need to be reserved. 1526 * 1527 * Usually this function is called from f_op->mmap() handler 1528 * under mm->mmap_sem write-lock, so it can change vma->vm_flags. 1529 * Caller must set VM_MIXEDMAP on vma if it wants to call this 1530 * function from other places, for example from page-fault handler. 1531 */ 1532 int vm_insert_page(struct vm_area_struct *vma, unsigned long addr, 1533 struct page *page) 1534 { 1535 if (addr < vma->vm_start || addr >= vma->vm_end) 1536 return -EFAULT; 1537 if (!page_count(page)) 1538 return -EINVAL; 1539 if (!(vma->vm_flags & VM_MIXEDMAP)) { 1540 BUG_ON(down_read_trylock(&vma->vm_mm->mmap_sem)); 1541 BUG_ON(vma->vm_flags & VM_PFNMAP); 1542 vma->vm_flags |= VM_MIXEDMAP; 1543 } 1544 1545 if (sp_check_hugepage(page)) > 1546 return hugetlb_insert_hugepage_pte_by_pa(vma->vm_mm, addr, 1547 vma->vm_page_prot, page_to_phys(page)); 1548 else 1549 return insert_page(vma, addr, page, vma->vm_page_prot); 1550 } 1551 EXPORT_SYMBOL(vm_insert_page); 1552 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 00/11] large folio: Performance and bugfix
by Liu Shixin 20 Sep '24

20 Sep '24

Patch [1-3] are cleanups for shmem. Patch [4,5] fix performance of shmem write. Patch [6-11] fix fault handler's handling of poisoned tail pages. Baolin Wang (3): mm: shmem: simplify the suitable huge orders validation for tmpfs mm: shmem: rename shmem_is_huge() to shmem_huge_global_enabled() mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders() Kefeng Wang (1): tmpfs: fault in smaller chunks if large folio allocation not allowed Matthew Wilcox (Oracle) (6): mm: make mapping_evict_folio() the preferred way to evict clean folios mm: convert __do_fault() to use a folio mm: use mapping_evict_folio() in truncate_error_page() mm: convert soft_offline_in_use_page() to use a folio mm: convert isolate_page() to mf_isolate_folio() mm: remove invalidate_inode_page() Rik van Riel (1): mm,tmpfs: consider end of file write in shmem_is_huge include/linux/fs.h | 2 + include/linux/shmem_fs.h | 15 ++--- mm/filemap.c | 7 +- mm/huge_memory.c | 11 +--- mm/internal.h | 2 +- mm/khugepaged.c | 2 +- mm/memory-failure.c | 54 ++++++++-------- mm/memory.c | 20 +++--- mm/shmem.c | 135 +++++++++++++++++++++------------------ mm/truncate.c | 42 +++++------- mm/userfaultfd.c | 2 +- 11 files changed, 145 insertions(+), 147 deletions(-) -- 2.34.1

2 12

[PATCH openEuler-22.03-LTS-SP1 0/1] fix CVE-2024-46714
by Lin Yujun 20 Sep '24

20 Sep '24

Alex Hung (1): drm/amd/display: Skip wbscl_set_scaler_filter if filter is null drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dwb_scl.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.34.1

2 2

[PATCH OLK-5.10 0/1] fix CVE-2024-46714
by Lin Yujun 20 Sep '24

20 Sep '24

Alex Hung (1): drm/amd/display: Skip wbscl_set_scaler_filter if filter is null drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dwb_scl.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.34.1

2 2

[PATCH OLK-6.6] vsock: fix recursive ->recvmsg calls
by Zhang Changzhong 20 Sep '24

20 Sep '24

From: Cong Wang <cong.wang(a)bytedance.com> stable inclusion from stable-v6.6.48 commit 921f1acf0c3cf6b1260ab57a8a6e8b3d5f3023d5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAOXZC CVE: CVE-2024-44996 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 69139d2919dd4aa9a553c8245e7c63e82613e3fc ] After a vsock socket has been added to a BPF sockmap, its prot->recvmsg has been replaced with vsock_bpf_recvmsg(). Thus the following recursiion could happen: vsock_bpf_recvmsg() -> __vsock_recvmsg() -> vsock_connectible_recvmsg() -> prot->recvmsg() -> vsock_bpf_recvmsg() again We need to fix it by calling the original ->recvmsg() without any BPF sockmap logic in __vsock_recvmsg(). Fixes: 634f1a7110b4 ("vsock: support sockmap") Reported-by: syzbot+bdb4bd87b5e22058e2a4(a)syzkaller.appspotmail.com Tested-by: syzbot+bdb4bd87b5e22058e2a4(a)syzkaller.appspotmail.com Cc: Bobby Eshleman <bobby.eshleman(a)bytedance.com> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Stefano Garzarella <sgarzare(a)redhat.com> Signed-off-by: Cong Wang <cong.wang(a)bytedance.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Link: https://patch.msgid.link/20240812022153.86512-1-xiyou.wangcong@gmail.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- include/net/af_vsock.h | 4 ++++ net/vmw_vsock/af_vsock.c | 50 +++++++++++++++++++++++++++-------------------- net/vmw_vsock/vsock_bpf.c | 4 ++-- 3 files changed, 35 insertions(+), 23 deletions(-) diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h index dc3cb16..f8b09a8 100644 --- a/include/net/af_vsock.h +++ b/include/net/af_vsock.h @@ -227,8 +227,12 @@ struct vsock_tap { int vsock_add_tap(struct vsock_tap *vt); int vsock_remove_tap(struct vsock_tap *vt); void vsock_deliver_tap(struct sk_buff *build_skb(void *opaque), void *opaque); +int __vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, + int flags); int vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, int flags); +int __vsock_dgram_recvmsg(struct socket *sock, struct msghdr *msg, + size_t len, int flags); int vsock_dgram_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, int flags); diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index 4afb6a5..f5eb737 100644 --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -1270,25 +1270,28 @@ static int vsock_dgram_connect(struct socket *sock, return err; } +int __vsock_dgram_recvmsg(struct socket *sock, struct msghdr *msg, + size_t len, int flags) +{ + struct sock *sk = sock->sk; + struct vsock_sock *vsk = vsock_sk(sk); + + return vsk->transport->dgram_dequeue(vsk, msg, len, flags); +} + int vsock_dgram_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, int flags) { #ifdef CONFIG_BPF_SYSCALL + struct sock *sk = sock->sk; const struct proto *prot; -#endif - struct vsock_sock *vsk; - struct sock *sk; - sk = sock->sk; - vsk = vsock_sk(sk); - -#ifdef CONFIG_BPF_SYSCALL prot = READ_ONCE(sk->sk_prot); if (prot != &vsock_proto) return prot->recvmsg(sk, msg, len, flags, NULL); #endif - return vsk->transport->dgram_dequeue(vsk, msg, len, flags); + return __vsock_dgram_recvmsg(sock, msg, len, flags); } EXPORT_SYMBOL_GPL(vsock_dgram_recvmsg); @@ -2124,15 +2127,12 @@ static int __vsock_seqpacket_recvmsg(struct sock *sk, struct msghdr *msg, } int -vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, - int flags) +__vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, + int flags) { struct sock *sk; struct vsock_sock *vsk; const struct vsock_transport *transport; -#ifdef CONFIG_BPF_SYSCALL - const struct proto *prot; -#endif int err; sk = sock->sk; @@ -2183,14 +2183,6 @@ vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, goto out; } -#ifdef CONFIG_BPF_SYSCALL - prot = READ_ONCE(sk->sk_prot); - if (prot != &vsock_proto) { - release_sock(sk); - return prot->recvmsg(sk, msg, len, flags, NULL); - } -#endif - if (sk->sk_type == SOCK_STREAM) err = __vsock_stream_recvmsg(sk, msg, len, flags); else @@ -2200,6 +2192,22 @@ vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, release_sock(sk); return err; } + +int +vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, + int flags) +{ +#ifdef CONFIG_BPF_SYSCALL + struct sock *sk = sock->sk; + const struct proto *prot; + + prot = READ_ONCE(sk->sk_prot); + if (prot != &vsock_proto) + return prot->recvmsg(sk, msg, len, flags, NULL); +#endif + + return __vsock_connectible_recvmsg(sock, msg, len, flags); +} EXPORT_SYMBOL_GPL(vsock_connectible_recvmsg); static int vsock_set_rcvlowat(struct sock *sk, int val) diff --git a/net/vmw_vsock/vsock_bpf.c b/net/vmw_vsock/vsock_bpf.c index a3c9754..c42c5cc1 100644 --- a/net/vmw_vsock/vsock_bpf.c +++ b/net/vmw_vsock/vsock_bpf.c @@ -64,9 +64,9 @@ static int __vsock_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int int err; if (sk->sk_type == SOCK_STREAM || sk->sk_type == SOCK_SEQPACKET) - err = vsock_connectible_recvmsg(sock, msg, len, flags); + err = __vsock_connectible_recvmsg(sock, msg, len, flags); else if (sk->sk_type == SOCK_DGRAM) - err = vsock_dgram_recvmsg(sock, msg, len, flags); + err = __vsock_dgram_recvmsg(sock, msg, len, flags); else err = -EPROTOTYPE; -- 2.9.5

2 1

[PATCH openEuler-22.03-LTS-SP1] net: hns3: fix a deadlock problem when config TC during resetting
by Zhang Changzhong 20 Sep '24

20 Sep '24

From: Jie Wang <wangjie125(a)huawei.com> stable inclusion from stable-v5.10.225 commit fc250eca15bde34c4c8f806b9d88f55bd56a992c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAOY0Z CVE: CVE-2024-44995 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit be5e816d00a506719e9dbb1a9c861c5ced30a109 ] When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable() In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it. Fixes: bb6b94a896d4 ("net: hns3: Add reset interface implementation in client") Signed-off-by: Jie Wang <wangjie125(a)huawei.com> Signed-off-by: Jijie Shao <shaojijie(a)huawei.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c index cf79cd6..f5f7b59 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -5798,6 +5798,9 @@ static int hns3_reset_notify_uninit_enet(struct hnae3_handle *handle) struct net_device *netdev = handle->kinfo.netdev; struct hns3_nic_priv *priv = netdev_priv(netdev); + if (!test_bit(HNS3_NIC_STATE_DOWN, &priv->state)) + hns3_nic_net_stop(netdev); + if (!test_and_clear_bit(HNS3_NIC_STATE_INITED, &priv->state)) { netdev_warn(netdev, "already uninitialized\n"); return 0; -- 2.9.5

2 1

[PATCH OLK-6.6] net: hns3: fix a deadlock problem when config TC during resetting
by Zhang Changzhong 20 Sep '24

20 Sep '24

From: Jie Wang <wangjie125(a)huawei.com> stable inclusion from stable-v6.6.48 commit fa1d4de7265c370e673583ac8d1bd17d21826cd9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAOY0Z CVE: CVE-2024-44995 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit be5e816d00a506719e9dbb1a9c861c5ced30a109 ] When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable() In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it. Fixes: bb6b94a896d4 ("net: hns3: Add reset interface implementation in client") Signed-off-by: Jie Wang <wangjie125(a)huawei.com> Signed-off-by: Jijie Shao <shaojijie(a)huawei.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c index 180787c..ce22b34 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -5998,6 +5998,9 @@ static int hns3_reset_notify_uninit_enet(struct hnae3_handle *handle) struct net_device *netdev = handle->kinfo.netdev; struct hns3_nic_priv *priv = netdev_priv(netdev); + if (!test_bit(HNS3_NIC_STATE_DOWN, &priv->state)) + hns3_nic_net_stop(netdev); + if (!test_and_clear_bit(HNS3_NIC_STATE_INITED, &priv->state)) { netdev_warn(netdev, "already uninitialized\n"); return 0; -- 2.9.5

2 1

[PATCH openEuler-1.0-LTS 00/13] block: backport debugfs patches
by Yu Kuai 20 Sep '24

20 Sep '24

Christoph Hellwig (2): block: serialize all debugfs operations using q->debugfs_mutex block: remove per-disk debugfs files in blk_unregister_queue Greg Kroah-Hartman (2): blk-mq: no need to check return value of debugfs_create functions blk-mq: fix up placement of debugfs directory of queue files Jan Kara (1): blktrace: Avoid sparse warnings when assigning q->blk_trace Luis Chamberlain (3): blktrace: break out of blktrace setup on concurrent calls blktrace: annotate required lock on do_blk_trace_setup() block: create the request_queue debugfs_dir on registration Ming Lei (1): blk-mq: don't create hctx debugfs dir until q->debugfs_dir is created Saravanan D (1): blk-mq: Fix spurious debugfs directory creation during initialization Yu Kuai (3): block: shutdown blktrace in blk_release_queue() block: protect blk_mq_debugfs_register/unregister_hctx() with 'debugfs_mutex' block: fix kabi broken in struct request_queue block/blk-core.c | 8 +- block/blk-io-hierarchy/debugfs.c | 6 ++ block/blk-io-hierarchy/stats.c | 8 ++ block/blk-mq-debugfs.c | 158 ++++++++++++------------------- block/blk-mq-debugfs.h | 36 +++---- block/blk-mq-sched.c | 11 +++ block/blk-mq.c | 2 + block/blk-sysfs.c | 24 +++-- block/blk.h | 2 - include/linux/blkdev.h | 11 ++- kernel/trace/blktrace.c | 72 +++++++------- 11 files changed, 168 insertions(+), 170 deletions(-) -- 2.39.2

2 14

2024

2023

2022

2021

2020

2019

Kernel