- 25 11月, 2022 18 次提交
-
-
由 Namjae Jeon 提交于
mainline inclusion from mainline-5.15-rc1 commit e5066499 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/e5066499079d ------------------------------- Remove unneeded RESPONSE_BUF, REQUEST_BUF, RESPONSE_SZ, INIT_AUX_PAYLOAD, HAS_AUX_PAYLOAD, AUX_PAYLOAD, AUX_PAYLOAD_SIZE, RESP_HDR_SIZE, HAS_TRANSFORM_BUF and TRANSFORM_BUF macros. Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Colin Ian King 提交于
mainline inclusion from mainline-5.15-rc1 commit 3161ad3a category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/3161ad3a717e ------------------------------- The variable err is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Dan Carpenter 提交于
mainline inclusion from mainline-5.15-rc1 commit 849f59e1 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/849f59e1a18a ------------------------------- The error handling in ksmbd_server_init() uses "one function to free everything style" which is impossible to audit and leads to several canonical bugs. When we free something that wasn't allocated it may be uninitialized, an error pointer, freed in a different function or we try freeing "foo->bar" when "foo" is a NULL pointer. And since the code is impossible to audit then it leads to memory leaks. In the ksmbd_server_init() function, every goto will lead to a crash because we have not allocated the work queue but we call ksmbd_workqueue_destroy() which tries to flush a NULL work queue. Another bug is if ksmbd_init_buffer_pools() fails then it leads to a double free because we free "work_cache" twice. A third type of bug is that we forgot to call ksmbd_release_inode_hash() so that is a resource leak. A better way to write error handling is for every function to clean up after itself and never leave things partially allocated. Then we can use "free the last successfully allocated resource" style. That way when someone is reading the code they can just track the last resource in their head and verify that the goto matches what they expect. In this patch I modified ksmbd_ipc_init() to clean up after itself and then I converted ksmbd_server_init() to use gotos to clean up. Fixes: cabcebc31de4 ("cifsd: introduce SMB3 kernel server") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Dan Carpenter 提交于
mainline inclusion from mainline-5.15-rc1 commit c1ea111f category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/c1ea111fd1bb ------------------------------- This code is assigning the wrong variable to "err" so it returns zero/success instead of -ENOMEM. Fixes: 788b6f45c1d2 ("cifsd: add server-side procedures for SMB3") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Namjae Jeon 提交于
mainline inclusion from mainline-5.15-rc1 commit b24c9335 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/b24c93358035 ------------------------------- When iterating through a directory, a file's name may not be null-terminated (depending on the underlying filesystem implementation). Modify match_pattern to take the string's length into account when matching it against the request pattern. Signed-off-by: NMarios Makassikis <mmakassikis@freebox.fr> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Namjae Jeon 提交于
mainline inclusion from mainline-5.15-rc1 commit 548e9ad3 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/548e9ad31739 ------------------------------- kernel test robot reported warnings: fs/cifsd/smbacl.c: In function 'parse_sec_desc': >> fs/cifsd/smbacl.c:786:6: warning: variable 'total_ace_size' set but not used [-Wunused-but-set-variable] 786 | int total_ace_size = 0, pntsd_type; | ^~~~~~~~~~~~~~ Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Hyunchul Lee 提交于
mainline inclusion from mainline-5.15-rc1 commit 95fa1ce9 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/95fa1ce947d6 ------------------------------- kernel test bot reports some incorrect comments. This patch fixes these comments. Reported-by: Nkernel test bot <lkp@intel.com> Signed-off-by: NHyunchul Lee <hyc.lee@gmail.com> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Sergey Senozhatsky 提交于
mainline inclusion from mainline-5.15-rc1 commit 2e2b0dda category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/2e2b0dda1889 ------------------------------- Remove unneeded FIXME comments. Signed-off-by: NSergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Namjae Jeon 提交于
mainline inclusion from mainline-5.15-rc1 commit 50355b0b category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/50355b0b2010 ------------------------------- Dan reported static checker warning: fs/cifsd/smbacl.c:1140 smb_check_perm_dacl() error: we previously assumed 'pntsd' could be null (see line 1137) This patch validate bounds of pntsd buffer. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Namjae Jeon 提交于
mainline inclusion from mainline-5.15-rc1 commit bc3fcc94 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/bc3fcc9462ef ------------------------------- Dan reported static checker warning: fs/cifsd/transport_rdma.c:1168 smb_direct_post_send_data() warn: missing error code 'ret' This patch add missing ret error code. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Dan Carpenter 提交于
mainline inclusion from mainline-5.15-rc1 commit a2ba2709 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/a2ba2709f5e4 ------------------------------- The ksmbd_free_work_struct() frees "work" so we need to swap the order of these two function calls to avoid a use after free. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Dan Carpenter 提交于
mainline inclusion from mainline-5.15-rc1 commit 8ef32967 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/8ef329670657 ------------------------------- The smb_direct_alloc_sendmsg() function never returns NULL, it only returns error pointers so the check needs to be updated. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Dan Carpenter 提交于
mainline inclusion from mainline-5.15-rc1 commit 86df49e1 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/86df49e105af ------------------------------- The shift has higher precedence than mask so this doesn't work as intended. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Colin Ian King 提交于
mainline inclusion from mainline-5.15-rc1 commit 1e853b93 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/1e853b937b2f ------------------------------- There are several spelling mistakes in various ksmbd_err and ksmbd_debug messages. Fix these. Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Stephen Rothwell 提交于
mainline inclusion from mainline-5.15-rc1 commit 36ba3866 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/36ba38663be0 ------------------------------- uniquify extract_sharename(). Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Namjae Jeon 提交于
mainline inclusion from mainline-5.15-rc1 commit f4415848 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/f44158485826 ------------------------------- This adds file operations and buffer pool for cifsd. Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: NHyunchul Lee <hyc.lee@gmail.com> Acked-by: NRonnie Sahlberg <lsahlber@redhat.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Namjae Jeon 提交于
mainline inclusion from mainline-5.15-rc1 commit e2f34481 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/e2f34481b24d ------------------------------- This adds smb3 engine, NTLM/NTLMv2/Kerberos authentication, oplock/lease cache mechanism for cifsd. Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: NHyunchul Lee <hyc.lee@gmail.com> Acked-by: NRonnie Sahlberg <lsahlber@redhat.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Namjae Jeon 提交于
mainline inclusion from mainline-5.15-rc1 commit 0626e664 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I60T7G CVE: NA Reference: https://git.kernel.org/torvalds/linux/c/0626e6641f6b ------------------------------- This adds server handler for central processing, transport layers(tcp, rdma, ipc) and a document describing cifsd architecture. Signed-off-by: NNamjae Jeon <namjae.jeon@samsung.com> Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: NHyunchul Lee <hyc.lee@gmail.com> Acked-by: NRonnie Sahlberg <lsahlber@redhat.com> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
- 23 11月, 2022 2 次提交
-
-
由 Luiz Augusto von Dentz 提交于
stable inclusion from stable-v5.10.154 commit 6b6f94fb9a74dd2891f11de4e638c6202bc89476 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5ZNPH?from=project-issue CVE: CVE-2022-42896 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6b6f94fb9a74dd2891f11de4e638c6202bc89476 ------------------------------- commit 711f8c3f upstream. The Bluetooth spec states that the valid range for SPSM is from 0x0001-0x00ff so it is invalid to accept values outside of this range: BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part A page 1059: Table 4.15: L2CAP_LE_CREDIT_BASED_CONNECTION_REQ SPSM ranges CVE: CVE-2022-42896 CC: stable@vger.kernel.org Reported-by: NTamás Koczka <poprdi@google.com> Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com> Reviewed-by: NTedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Luiz Augusto von Dentz 提交于
stable inclusion from stable-v5.10.154 commit 26ca2ac091b49281d73df86111d16e5a76e43bd7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5ZNRS CVE: CVE-2022-42895 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=26ca2ac091b49281d73df86111d16e5a76e43bd7 -------------------------------- commit b1a2cd50 upstream. On l2cap_parse_conf_req the variable efs is only initialized if remote_efs has been set. CVE: CVE-2022-42895 CC: stable@vger.kernel.org Reported-by: NTamás Koczka <poprdi@google.com> Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com> Reviewed-by: NTedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NBaisong Zhong <zhongbaisong@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 22 11月, 2022 2 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @hejunhao3 ``` Synchronize the coresight code of the Linux mainline to support HiSilicon tracing [Testing] kernel config CONFIG_CORESIGHT_LINK_AND_SINK_TMC=m CONFIG_CORESIGHT_TRBE=m [test log] insmod coresight.ko coresight-etm4x.ko coresight-funnel.ko coresight-tmc.ko estuary:/$ ls /sys/bus/coresight/devices/ ete0 ete12 ete2 ete6 funnel0 tmc_etf0 tmc_etr0 ete1 ete13 ete3 ete7 funnel1 tmc_etf1 ete10 ete14 ete4 ete8 funnel2 tmc_etf2 ete11 ete15 ete5 ete9 funnel3 tmc_etf3 estuary:/$ echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink estuary:/$ echo 1 > /sys/bus/coresight/devices/ete3/enable_source estuary:/$ cat /sys/bus/coresight/devices/tmc_etr0/mgmt/rwp 0x79100000 estuary:/$ cat /sys/bus/coresight/devices/tmc_etr0/mgmt/rwp 0x79106e00 estuary:/$ echo 0 > /sys/bus/coresight/devices/ete3/enable_source estuary:/$ insmod /lib/modules/5.10.0+/ram_blk_drv.ko p_addr=0x79100000 p_size=0x3000 estuary:/$ dd if=/dev/ramblock of=sys_c1_range.data bs=4k count=48 3+0 records in 3+0 records out 12288 bytes (12.0KB) copied, 0.028941 seconds, 414.6KB/s estuary:/$ ptm2human -e -i sys_c1_range.data >sys_c1_range.data.log 2>&1 estuary:/$ grep sys_c1_range.data.log | "Decode trace stream of ID" [22;1HDecode trace stream of ID 21 estuary:/$ estuary:/$ perf record -e /cs_etm/@tmc_etr0/ -C 7 taskset -c 7 uname -a Linux (none) 5.10.0+ #3 SMP Thu Oct 27 14:51:05 CST 2022 aarch64 GNU/Linux [ 2900.563565][ T306] coresight tmc_etr0: timeout while waiting for completion of Manual Flush [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.588 MB perf.data ] estuary:/$ perf report --stdio -D > report.txt estuary:/$ grep -rn "I_ASYNC : Alignment Synchronisation" report.txt 4244: Idx:0; ID:1e; I_ASYNC : Alignment Synchronisation. 6913: Idx:4429; ID:1e; I_ASYNC : Alignment Synchronisation. 9279: Idx:8833; ID:1e; I_ASYNC : Alignment Synchronisation. ``` Link:https://gitee.com/openeuler/kernel/pulls/225 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: Ling Mingqiang <lingmingqiang@huawei.com> Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @duanqiangwen This PR is t add Beijing WangXun Technology Co. net-swift ngbe NIC support. Issue:https://gitee.com/openeuler/kernel/issues/I61PSD Hardware List: Netswift WX1860AL_W 8088:0100[VID:DID] Netswift WX1860A2 8088:0101[VID:DID] Netswift WX1860A2S 8088:0102[VID:DID] Netswift WX1860A4 8088:0103[VID:DID] Netswift WX1860A4S 8088:0104[VID:DID] Netswift WX1860AL2 8088:0105[VID:DID] Netswift WX1860AL2S 8088:0106[VID:DID] Netswift WX1860AL4 8088:0107[VID:DID] Netswift WX1860AL4S 8088:0108[VID:DID] Netswift WX1860NCSI 8088:0109[VID:DID] Netswift WX1860A1 8088:010a[VID:DID] Netswift WX1860AL1 8088:010b[VID:DID] Supported Features: - Support 10/100/1000M full and Autoneg. - Support Legacy/MSI/MSI-X interrupt. - Support ipv4/ipv6, Support promisc mode. - Support RSS. - Support Vlan. - Support Tx/Rx checksum offload. - Support TSO. - Support Jumbo Frames. - Support IEEE 1588. - Support Linux bond. - Support L2 Filter. Net-Swift Official Website: https://www.net-swift.com ngbe Out-of-Tree Linux Driver Source Code: Click https://www.net-swift.com/p/contact to contact us. Link:https://gitee.com/openeuler/kernel/pulls/257 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
- 21 11月, 2022 2 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @zhangjian210 This patch delete unused function of SVM: Now, the SVM_IOCTL_SET_RC,SVM_IOCTL_REMAP_PROC function has not been used by others, and SVM_IOCTL_REMAP_PROC interface has withdrawal of rights action, so we must delete it's function. Delete interface: SVM_IOCTL_REMAP_PROC SVM_IOCTL_SET_RC Link:https://gitee.com/openeuler/kernel/pulls/263 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I61RA3 ------------------------------- The following three ioctl command are not in used at all. Delete those implementation. SVM_IOCTL_SET_RC SVM_IOCTL_REMAP_PROC Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
-
- 18 11月, 2022 16 次提交
-
-
由 Qu Wenruo 提交于
stable inclusion from stable-v5.10.137 commit fb4e220e1b2bbe6b983ebe78fed5eae6ce31c1c2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fb4e220e1b2bbe6b983ebe78fed5eae6ce31c1c2 -------------------------------- commit f6065f8e upstream. [BUG] There is a small workload which will always fail with recent kernel: (A simplified version from btrfs/125 test case) mkfs.btrfs -f -m raid5 -d raid5 -b 1G $dev1 $dev2 $dev3 mount $dev1 $mnt xfs_io -f -c "pwrite -S 0xee 0 1M" $mnt/file1 sync umount $mnt btrfs dev scan -u $dev3 mount -o degraded $dev1 $mnt xfs_io -f -c "pwrite -S 0xff 0 128M" $mnt/file2 umount $mnt btrfs dev scan mount $dev1 $mnt btrfs balance start --full-balance $mnt umount $mnt The failure is always failed to read some tree blocks: BTRFS info (device dm-4): relocating block group 217710592 flags data|raid5 BTRFS error (device dm-4): parent transid verify failed on 38993920 wanted 9 found 7 BTRFS error (device dm-4): parent transid verify failed on 38993920 wanted 9 found 7 ... [CAUSE] With the recently added debug output, we can see all RAID56 operations related to full stripe 38928384: 56.1183: raid56_read_partial: full_stripe=38928384 devid=2 type=DATA1 offset=0 opf=0x0 physical=9502720 len=65536 56.1185: raid56_read_partial: full_stripe=38928384 devid=3 type=DATA2 offset=16384 opf=0x0 physical=9519104 len=16384 56.1185: raid56_read_partial: full_stripe=38928384 devid=3 type=DATA2 offset=49152 opf=0x0 physical=9551872 len=16384 56.1187: raid56_write_stripe: full_stripe=38928384 devid=3 type=DATA2 offset=0 opf=0x1 physical=9502720 len=16384 56.1188: raid56_write_stripe: full_stripe=38928384 devid=3 type=DATA2 offset=32768 opf=0x1 physical=9535488 len=16384 56.1188: raid56_write_stripe: full_stripe=38928384 devid=1 type=PQ1 offset=0 opf=0x1 physical=30474240 len=16384 56.1189: raid56_write_stripe: full_stripe=38928384 devid=1 type=PQ1 offset=32768 opf=0x1 physical=30507008 len=16384 56.1218: raid56_write_stripe: full_stripe=38928384 devid=3 type=DATA2 offset=49152 opf=0x1 physical=9551872 len=16384 56.1219: raid56_write_stripe: full_stripe=38928384 devid=1 type=PQ1 offset=49152 opf=0x1 physical=30523392 len=16384 56.2721: raid56_parity_recover: full stripe=38928384 eb=39010304 mirror=2 56.2723: raid56_parity_recover: full stripe=38928384 eb=39010304 mirror=2 56.2724: raid56_parity_recover: full stripe=38928384 eb=39010304 mirror=2 Before we enter raid56_parity_recover(), we have triggered some metadata write for the full stripe 38928384, this leads to us to read all the sectors from disk. Furthermore, btrfs raid56 write will cache its calculated P/Q sectors to avoid unnecessary read. This means, for that full stripe, after any partial write, we will have stale data, along with P/Q calculated using that stale data. Thankfully due to patch "btrfs: only write the sectors in the vertical stripe which has data stripes" we haven't submitted all the corrupted P/Q to disk. When we really need to recover certain range, aka in raid56_parity_recover(), we will use the cached rbio, along with its cached sectors (the full stripe is all cached). This explains why we have no event raid56_scrub_read_recover() triggered. Since we have the cached P/Q which is calculated using the stale data, the recovered one will just be stale. In our particular test case, it will always return the same incorrect metadata, thus causing the same error message "parent transid verify failed on 39010304 wanted 9 found 7" again and again. [BTRFS DESTRUCTIVE RMW PROBLEM] Test case btrfs/125 (and above workload) always has its trouble with the destructive read-modify-write (RMW) cycle: 0 32K 64K Data1: | Good | Good | Data2: | Bad | Bad | Parity: | Good | Good | In above case, if we trigger any write into Data1, we will use the bad data in Data2 to re-generate parity, killing the only chance to recovery Data2, thus Data2 is lost forever. This destructive RMW cycle is not specific to btrfs RAID56, but there are some btrfs specific behaviors making the case even worse: - Btrfs will cache sectors for unrelated vertical stripes. In above example, if we're only writing into 0~32K range, btrfs will still read data range (32K ~ 64K) of Data1, and (64K~128K) of Data2. This behavior is to cache sectors for later update. Incidentally commit d4e28d9b ("btrfs: raid56: make steal_rbio() subpage compatible") has a bug which makes RAID56 to never trust the cached sectors, thus slightly improve the situation for recovery. Unfortunately, follow up fix "btrfs: update stripe_sectors::uptodate in steal_rbio" will revert the behavior back to the old one. - Btrfs raid56 partial write will update all P/Q sectors and cache them This means, even if data at (64K ~ 96K) of Data2 is free space, and only (96K ~ 128K) of Data2 is really stale data. And we write into that (96K ~ 128K), we will update all the parity sectors for the full stripe. This unnecessary behavior will completely kill the chance of recovery. Thankfully, an unrelated optimization "btrfs: only write the sectors in the vertical stripe which has data stripes" will prevent submitting the write bio for untouched vertical sectors. That optimization will keep the on-disk P/Q untouched for a chance for later recovery. [FIX] Although we have no good way to completely fix the destructive RMW (unless we go full scrub for each partial write), we can still limit the damage. With patch "btrfs: only write the sectors in the vertical stripe which has data stripes" now we won't really submit the P/Q of unrelated vertical stripes, so the on-disk P/Q should still be fine. Now we really need to do is just drop all the cached sectors when doing recovery. By this, we have a chance to read the original P/Q from disk, and have a chance to recover the stale data, while still keep the cache to speed up regular write path. In fact, just dropping all the cache for recovery path is good enough to allow the test case btrfs/125 along with the small script to pass reliably. The lack of metadata write after the degraded mount, and forced metadata COW is saving us this time. So this patch will fix the behavior by not trust any cache in __raid56_parity_recover(), to solve the problem while still keep the cache useful. But please note that this test pass DOES NOT mean we have solved the destructive RMW problem, we just do better damage control a little better. Related patches: - btrfs: only write the sectors in the vertical stripe - d4e28d9b ("btrfs: raid56: make steal_rbio() subpage compatible") - btrfs: update stripe_sectors::uptodate in steal_rbio Acked-by: NDavid Sterba <dsterba@suse.com> Signed-off-by: NQu Wenruo <wqu@suse.com> Signed-off-by: NDavid Sterba <dsterba@suse.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Qu Wenruo 提交于
stable inclusion from stable-v5.10.137 commit 1e1a039f44b7efcef6a4df13c9f105c8daa41be2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e1a039f44b7efcef6a4df13c9f105c8daa41be2 -------------------------------- commit bd8f7e62 upstream. If we have only 8K partial write at the beginning of a full RAID56 stripe, we will write the following contents: 0 8K 32K 64K Disk 1 (data): |XX| | | Disk 2 (data): | | | Disk 3 (parity): |XXXXXXXXXXXXXXX|XXXXXXXXXXXXXXX| |X| means the sector will be written back to disk. Note that, although we won't write any sectors from disk 2, but we will write the full 64KiB of parity to disk. This behavior is fine for now, but not for the future (especially for RAID56J, as we waste quite some space to journal the unused parity stripes). So here we will also utilize the btrfs_raid_bio::dbitmap, anytime we queue a higher level bio into an rbio, we will update rbio::dbitmap to indicate which vertical stripes we need to writeback. And at finish_rmw(), we also check dbitmap to see if we need to write any sector in the vertical stripe. So after the patch, above example will only lead to the following writeback pattern: 0 8K 32K 64K Disk 1 (data): |XX| | | Disk 2 (data): | | | Disk 3 (parity): |XX| | | Acked-by: NDavid Sterba <dsterba@suse.com> Signed-off-by: NQu Wenruo <wqu@suse.com> Signed-off-by: NDavid Sterba <dsterba@suse.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Tadeusz Struk 提交于
stable inclusion from stable-v5.10.137 commit 8f317cd888059c59e2fa924bf4b0957cfa53f78e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8f317cd888059c59e2fa924bf4b0957cfa53f78e -------------------------------- commit 13765de8 upstream. Syzbot found a GPF in reweight_entity. This has been bisected to commit 4ef0c5c6 ("kernel/sched: Fix sched_fork() access an invalid sched_task_group") There is a race between sched_post_fork() and setpriority(PRIO_PGRP) within a thread group that causes a null-ptr-deref in reweight_entity() in CFS. The scenario is that the main process spawns number of new threads, which then call setpriority(PRIO_PGRP, 0, -20), wait, and exit. For each of the new threads the copy_process() gets invoked, which adds the new task_struct and calls sched_post_fork() for it. In the above scenario there is a possibility that setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread in the group that is just being created by copy_process(), and for which the sched_post_fork() has not been executed yet. This will trigger a null pointer dereference in reweight_entity(), as it will try to access the run queue pointer, which hasn't been set. Before the mentioned change the cfs_rq pointer for the task has been set in sched_fork(), which is called much earlier in copy_process(), before the new task is added to the thread_group. Now it is done in the sched_post_fork(), which is called after that. To fix the issue the remove the update_load param from the update_load param() function and call reweight_task() only if the task flag doesn't have the TASK_NEW flag set. Fixes: 4ef0c5c6 ("kernel/sched: Fix sched_fork() access an invalid sched_task_group") Reported-by: syzbot+af7a719bc92395ee41b3@syzkaller.appspotmail.com Signed-off-by: NTadeusz Struk <tadeusz.struk@linaro.org> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NDietmar Eggemann <dietmar.eggemann@arm.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20220203161846.1160750-1-tadeusz.struk@linaro.orgSigned-off-by: NFedor Pchelkin <pchelkin@ispras.ru> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Jamal Hadi Salim 提交于
stable inclusion from stable-v5.10.137 commit aa318d35bedce767d88648ca3016779f93f1bde5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=aa318d35bedce767d88648ca3016779f93f1bde5 -------------------------------- commit 02799571 upstream. Follows up on: https://lore.kernel.org/all/20220809170518.164662-1-cascardo@canonical.com/ handle of 0 implies from/to of universe realm which is not very sensible. Lets see what this patch will do: $sudo tc qdisc add dev $DEV root handle 1:0 prio //lets manufacture a way to insert handle of 0 $sudo tc filter add dev $DEV parent 1:0 protocol ip prio 100 \ route to 0 from 0 classid 1:10 action ok //gets rejected... Error: handle of 0 is not valid. We have an error talking to the kernel, -1 //lets create a legit entry.. sudo tc filter add dev $DEV parent 1:0 protocol ip prio 100 route from 10 \ classid 1:10 action ok //what did the kernel insert? $sudo tc filter ls dev $DEV parent 1:0 filter protocol ip pref 100 route chain 0 filter protocol ip pref 100 route chain 0 fh 0x000a8000 flowid 1:10 from 10 action order 1: gact action pass random type none pass val 0 index 1 ref 1 bind 1 //Lets try to replace that legit entry with a handle of 0 $ sudo tc filter replace dev $DEV parent 1:0 protocol ip prio 100 \ handle 0x000a8000 route to 0 from 0 classid 1:10 action drop Error: Replacing with handle of 0 is invalid. We have an error talking to the kernel, -1 And last, lets run Cascardo's POC: $ ./poc 0 0 -22 -22 -22 Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com> Acked-by: NStephen Hemminger <stephen@networkplumber.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Tyler Hicks 提交于
stable inclusion from stable-v5.10.137 commit 5a2a00b60458214017a5eb8fb78fce723b5e2faf category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5a2a00b60458214017a5eb8fb78fce723b5e2faf -------------------------------- commit aa7aeee1 upstream. Ensure that the fid's iounit field is set to zero when a new fid is created. Certain 9P operations, such as OPEN and CREATE, allow the server to reply with an iounit size which the client code assigns to the p9_fid struct shortly after the fid is created by p9_fid_create(). On the other hand, an XATTRWALK operation doesn't allow for the server to specify an iounit value. The iounit field of the newly allocated p9_fid struct remained uninitialized in that case. Depending on allocation patterns, the iounit value could have been something reasonable that was carried over from previously freed fids or, in the worst case, could have been arbitrary values from non-fid related usages of the memory location. The bug was detected in the Windows Subsystem for Linux 2 (WSL2) kernel after the uninitialized iounit field resulted in the typical sequence of two getxattr(2) syscalls, one to get the size of an xattr and another after allocating a sufficiently sized buffer to fit the xattr value, to hit an unexpected ERANGE error in the second call to getxattr(2). An uninitialized iounit field would sometimes force rsize to be smaller than the xattr value size in p9_client_read_once() and the 9P server in WSL refused to chunk up the READ on the attr_fid and, instead, returned ERANGE to the client. The virtfs server in QEMU seems happy to chunk up the READ and this problem goes undetected there. Link: https://lkml.kernel.org/r/20220710141402.803295-1-tyhicks@linux.microsoft.com Fixes: ebf46264 ("fs/9p: Add support user. xattr") Cc: stable@vger.kernel.org Signed-off-by: NTyler Hicks <tyhicks@linux.microsoft.com> Reviewed-by: NChristian Schoenebeck <linux_oss@crudebyte.com> Signed-off-by: NDominique Martinet <asmadeus@codewreck.org> [tyhicks: Adjusted context due to: - Lack of fid refcounting introduced in v5.11 commit 6636b6dc ("9p: add refcount to p9_fid struct") - Difference in how buffer sizes are specified v5.16 commit 6e195b0f ("9p: fix a bunch of checkpatch warnings")] Signed-off-by: NTyler Hicks <tyhicks@linux.microsoft.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Jens Wiklander 提交于
stable inclusion from stable-v5.10.137 commit 578c349570d2a912401963783b36e0ec7a25c053 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=578c349570d2a912401963783b36e0ec7a25c053 -------------------------------- commit 573ae4f1 upstream. With special lengths supplied by user space, register_shm_helper() has an integer overflow when calculating the number of pages covered by a supplied user space memory region. This causes internal_get_user_pages_fast() a helper function of pin_user_pages_fast() to do a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Modules linked in: CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internal_get_user_pages_fast+0x474/0xa80 Call trace: internal_get_user_pages_fast+0x474/0xa80 pin_user_pages_fast+0x24/0x4c register_shm_helper+0x194/0x330 tee_shm_register_user_buf+0x78/0x120 tee_ioctl+0xd0/0x11a0 __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114 Fix this by adding an an explicit call to access_ok() in tee_shm_register_user_buf() to catch an invalid user space address early. Fixes: 033ddf12 ("tee: add register user memory") Cc: stable@vger.kernel.org Reported-by: NNimish Mishra <neelam.nimish@gmail.com> Reported-by: NAnirban Chakraborty <ch.anirban00727@gmail.com> Reported-by: NDebdeep Mukhopadhyay <debdeep.mukhopadhyay@gmail.com> Suggested-by: NJerome Forissier <jerome.forissier@linaro.org> Signed-off-by: NJens Wiklander <jens.wiklander@linaro.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Aaron Lewis 提交于
stable inclusion from stable-v5.10.137 commit 98b20e1612e69bf91185cf722a96293a136fe894 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=98b20e1612e69bf91185cf722a96293a136fe894 -------------------------------- commit 4ac19ead upstream. When returning from the compare function the u64 is truncated to an int. This results in a loss of the high nybble[1] in the event select and its sign if that nybble is in use. Switch from using a result that can end up being truncated to a result that can only be: 1, 0, -1. [1] bits 35:32 in the event select register and bits 11:8 in the event select. Fixes: 7ff775ac ("KVM: x86/pmu: Use binary search to check filtered events") Signed-off-by: NAaron Lewis <aaronlewis@google.com> Reviewed-by: NSean Christopherson <seanjc@google.com> Message-Id: <20220517051238.2566934-1-aaronlewis@google.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Miquel Raynal 提交于
stable inclusion from stable-v5.10.137 commit 705dfc4575d6fae17c60a222cb5f78d8de43be38 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=705dfc4575d6fae17c60a222cb5f78d8de43be38 -------------------------------- commit fc9e18f9 upstream. Under the following conditions: * after rounding up by 4 the number of bytes to transfer (this is related to the controller's internal constraints), * if this (rounded) amount of data is situated beyond the end of the device, * and only in NV-DDR mode, the Arasan NAND controller timeouts. This currently can happen in a particular helper used when picking software ECC algorithms. Let's prevent this situation by refusing to use the NV-DDR interface with software engines. Fixes: 4edde603 ("mtd: rawnand: arasan: Support NV-DDR interface") Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211008163640.1753821-1-miquel.raynal@bootlin.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Luiz Augusto von Dentz 提交于
stable inclusion from stable-v5.10.137 commit c898e917d8bb317addcafa4511bde51af8e3976e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c898e917d8bb317addcafa4511bde51af8e3976e -------------------------------- commit 332f1795 upstream. The patch d0be8347: "Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put" from Jul 21, 2022, leads to the following Smatch static checker warning: net/bluetooth/l2cap_core.c:1977 l2cap_global_chan_by_psm() error: we previously assumed 'c' could be null (see line 1996) Fixes: d0be8347 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put") Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Jose Alonso 提交于
stable inclusion from stable-v5.10.137 commit e81046da1d9b2ffe8bb26a70871bebc281bcd06a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e81046da1d9b2ffe8bb26a70871bebc281bcd06a -------------------------------- commit 6fd2c17f upstream. This reverts commit 36a15e1c. The usage of FLAG_SEND_ZLP causes problems to other firmware/hardware versions that have no issues. The FLAG_SEND_ZLP is not safe to use in this context. See: https://patchwork.ozlabs.org/project/netdev/patch/1270599787.8900.8.camel@Linuxdev4-laptop/#118378 The original problem needs another way to solve. Fixes: 36a15e1c ("net: usb: ax88179_178a needs FLAG_SEND_ZLP") Cc: stable@vger.kernel.org Reported-by: NRonald Wahl <ronald.wahl@raritan.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216327 Link: https://bugs.archlinux.org/task/75491Signed-off-by: NJose Alonso <joalonsof@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Tom Rix 提交于
stable inclusion from stable-v5.10.137 commit a60996dc027a026baca91a5bbf948bd3fb30ecd1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a60996dc027a026baca91a5bbf948bd3fb30ecd1 -------------------------------- commit 63569d90 upstream. sparse reports drivers/gpu/drm/vc4/vc4_drv.c:270:27: warning: symbol 'vc4_dma_range_matches' was not declared. Should it be static? vc4_dma_range_matches is only used in vc4_drv.c, so it's storage class specifier should be static. Fixes: da8e393e ("drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component") Signed-off-by: NTom Rix <trix@redhat.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220629200101.498138-1-trix@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Marek Vasut 提交于
stable inclusion from stable-v5.10.137 commit 3422e24af9ba79eb4ba70646dfd3c1621ea92558 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3422e24af9ba79eb4ba70646dfd3c1621ea92558 -------------------------------- commit 9030a9e5 upstream. Per toshiba,tc358767.yaml DT binding document, port@2 the output (e)DP port is optional. In case this port is not described in DT, the bridge driver operates in DPI-to-DP mode. The drm_of_find_panel_or_bridge() call in tc_probe_edp_bridge_endpoint() returns -ENODEV in case port@2 is not present in DT and this specific return value is incorrectly propagated outside of tc_probe_edp_bridge_endpoint() function. All other error values must be propagated and are propagated correctly. Return 0 in case the port@2 is missing instead, that reinstates the original behavior before the commit this patch fixes. Fixes: 8478095a ("drm/bridge: tc358767: Move (e)DP bridge endpoint parsing into dedicated function") Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Marek Vasut <marex@denx.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: NLucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220428213132.447890-1-marex@denx.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Greg Kroah-Hartman 提交于
stable inclusion from stable-v5.10.137 commit 2223b35c57523580317cf85254a9ae9819ecc7b1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2223b35c57523580317cf85254a9ae9819ecc7b1 -------------------------------- commit 5f8954e0 upstream. This reverts commit a52ed486 as it causes build problems in linux-next. It needs to be reintroduced in a way that can allow the api to evolve and not require a "flag day" to catch all users. Link: https://lore.kernel.org/r/20220623160723.7a44b573@canb.auug.org.au Cc: Duoming Zhou <duoming@zju.edu.cn> Cc: Brian Norris <briannorris@chromium.org> Cc: Johannes Berg <johannes@sipsolutions.net> Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Eric Dumazet 提交于
stable inclusion from stable-v5.10.137 commit 8338305317dfc03622b1fedf9b23182b8c993a27 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8338305317dfc03622b1fedf9b23182b8c993a27 -------------------------------- commit c4ee1185 upstream. sk_forced_mem_schedule() has a bug similar to ones fixed in commit 7c80b038 ("net: fix sk_wmem_schedule() and sk_rmem_schedule() errors") While this bug has little chance to trigger in old kernels, we need to fix it before the following patch. Fixes: d83769a5 ("tcp: fix possible deadlock in tcp_send_fin()") Signed-off-by: NEric Dumazet <edumazet@google.com> Acked-by: NSoheil Hassas Yeganeh <soheil@google.com> Reviewed-by: NShakeel Butt <shakeelb@google.com> Reviewed-by: NWei Wang <weiwan@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Ahmed Zaki 提交于
stable inclusion from stable-v5.10.137 commit c35c01a7cb3002b86f7c245b9e5e3e76a331d738 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c35c01a7cb3002b86f7c245b9e5e3e76a331d738 -------------------------------- commit 8f9dcc29 upstream. The following is from a system that went OOM due to a memory leak: wlan0: Allocated STA 74:83:c2:64:0b:87 wlan0: Allocated STA 74:83:c2:64:0b:87 wlan0: IBSS finish 74:83:c2:64:0b:87 (---from ieee80211_ibss_add_sta) wlan0: Adding new IBSS station 74:83:c2:64:0b:87 wlan0: moving STA 74:83:c2:64:0b:87 to state 2 wlan0: moving STA 74:83:c2:64:0b:87 to state 3 wlan0: Inserted STA 74:83:c2:64:0b:87 wlan0: IBSS finish 74:83:c2:64:0b:87 (---from ieee80211_ibss_work) wlan0: Adding new IBSS station 74:83:c2:64:0b:87 wlan0: moving STA 74:83:c2:64:0b:87 to state 2 wlan0: moving STA 74:83:c2:64:0b:87 to state 3 . . wlan0: expiring inactive not authorized STA 74:83:c2:64:0b:87 wlan0: moving STA 74:83:c2:64:0b:87 to state 2 wlan0: moving STA 74:83:c2:64:0b:87 to state 1 wlan0: Removed STA 74:83:c2:64:0b:87 wlan0: Destroyed STA 74:83:c2:64:0b:87 The ieee80211_ibss_finish_sta() is called twice on the same STA from 2 different locations. On the second attempt, the allocated STA is not destroyed creating a kernel memory leak. This is happening because sta_info_insert_finish() does not call sta_info_free() the second time when the STA already exists (returns -EEXIST). Note that the caller sta_info_insert_rcu() assumes STA is destroyed upon errors. Same fix is applied to -ENOMEM. Signed-off-by: NAhmed Zaki <anzaki@gmail.com> Link: https://lore.kernel.org/r/20211002145329.3125293-1-anzaki@gmail.com [change the error path label to use the existing code] Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NViacheslav Sablin <sablin@ispras.ru> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Vitaly Kuznetsov 提交于
stable inclusion from stable-v5.10.137 commit ac7de8c2ba1292856fdd4a4c0764669b9607cf0a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ac7de8c2ba1292856fdd4a4c0764669b9607cf0a -------------------------------- commit 00b5f371 upstream When kvm_irq_delivery_to_apic_fast() is called with APIC_DEST_SELF shorthand, 'src' must not be NULL. Crash the VM with KVM_BUG_ON() instead of crashing the host. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20220325132140.25650-3-vkuznets@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NStefan Ghinea <stefan.ghinea@windriver.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-