- 14 6月, 2023 5 次提交
-
-
由 Pengcheng Yang 提交于
stable inclusion from stable-v5.10.163 commit 28e4a763cd4a2b1a78852216ef4bd7df3a05cec6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6AVM6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=28e4a763cd4a2b1a78852216ef4bd7df3a05cec6 -------------------------------- [ Upstream commit 7a9841ca ] In tcp_bpf_send_verdict() redirection, the eval variable is assigned to __SK_REDIRECT after the apply_bytes data is sent, if msg has more_data, sock_put() will be called multiple times. We should reset the eval variable to __SK_NONE every time more_data starts. This causes: IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7 ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110 Modules linked in: CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1 Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014 Call Trace: <TASK> __tcp_transmit_skb+0xa1b/0xb90 ? __alloc_skb+0x8c/0x1a0 ? __kmalloc_node_track_caller+0x184/0x320 tcp_write_xmit+0x22a/0x1110 __tcp_push_pending_frames+0x32/0xf0 do_tcp_sendpages+0x62d/0x640 tcp_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x260/0x410 ? preempt_count_add+0x70/0xa0 tcp_bpf_send_verdict+0x386/0x4b0 tcp_bpf_sendmsg+0x21b/0x3b0 sock_sendmsg+0x58/0x70 __sys_sendto+0xfa/0x170 ? xfd_validate_state+0x1d/0x80 ? switch_fpu_return+0x59/0xe0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: cd9733f5 ("tcp_bpf: Fix one concurrency problem in the tcp_bpf_send_verdict function") Signed-off-by: NPengcheng Yang <yangpc@wangsu.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Acked-by: NJakub Sitnicki <jakub@cloudflare.com> Link: https://lore.kernel.org/bpf/1669718441-2654-2-git-send-email-yangpc@wangsu.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NWang Hai <wanghai38@huawei.com> Signed-off-by: NLiu Jian <liujian56@huawei.com> (cherry picked from commit 48c7aa19)
-
由 Cong Wang 提交于
mainline inclusion from mainline-v6.1-rc5 commit 8bbabb3f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I65HYE CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8bbabb3fddcd0f858be69ed5abc9b470a239d6f2 --------------------------- Stanislav reported a lockdep warning, which is caused by the cancel_work_sync() called inside sock_map_close(), as analyzed below by Jakub: psock->work.func = sk_psock_backlog() ACQUIRE psock->work_mutex sk_psock_handle_skb() skb_send_sock() __skb_send_sock() sendpage_unlocked() kernel_sendpage() sock->ops->sendpage = inet_sendpage() sk->sk_prot->sendpage = tcp_sendpage() ACQUIRE sk->sk_lock tcp_sendpage_locked() RELEASE sk->sk_lock RELEASE psock->work_mutex sock_map_close() ACQUIRE sk->sk_lock sk_psock_stop() sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED) cancel_work_sync() __cancel_work_timer() __flush_work() // wait for psock->work to finish RELEASE sk->sk_lock We can move the cancel_work_sync() out of the sock lock protection, but still before saved_close() was called. Fixes: 799aa7f9 ("skmsg: Avoid lock_sock() in sk_psock_backlog()") Reported-by: NStanislav Fomichev <sdf@google.com> Signed-off-by: NCong Wang <cong.wang@bytedance.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Tested-by: NJakub Sitnicki <jakub@cloudflare.com> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Acked-by: NJakub Sitnicki <jakub@cloudflare.com> Link: https://lore.kernel.org/bpf/20221102043417.279409-1-xiyou.wangcong@gmail.com (cherry picked from commit 8bbabb3f) Signed-off-by: NLiu Jian <liujian56@huawei.com> Conflicts: net/core/skmsg.c (cherry picked from commit a4aa9897)
-
由 Wang Yufen 提交于
stable inclusion from stable-v5.10.155 commit cc21dc48a78cc9e5af9a4d039cd456446a6e73ff category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCD CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cc21dc48a78cc9e5af9a4d039cd456446a6e73ff -------------------------------- [ Upstream commit 8ec95b94 ] When running `test_sockmap` selftests, the following warning appears: WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0 Call Trace: <TASK> inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xd28/0x1380 ? tcp_v4_do_rcv+0x77/0x2c0 tcp_v4_do_rcv+0x77/0x2c0 __release_sock+0x106/0x130 __tcp_close+0x1a7/0x4e0 tcp_close+0x20/0x70 inet_release+0x3c/0x80 __sock_release+0x3a/0xb0 sock_close+0x14/0x20 __fput+0xa3/0x260 task_work_run+0x59/0xb0 exit_to_user_mode_prepare+0x1b3/0x1c0 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The root case is in commit 84472b43 ("bpf, sockmap: Fix more uncharged while msg has more_data"), where I used msg->sg.size to replace the tosend, causing breakage: if (msg->apply_bytes && msg->apply_bytes < tosend) tosend = psock->apply_bytes; Fixes: 84472b43 ("bpf, sockmap: Fix more uncharged while msg has more_data") Reported-by: NJakub Sitnicki <jakub@cloudflare.com> Signed-off-by: NWang Yufen <wangyufen@huawei.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Acked-by: NJakub Sitnicki <jakub@cloudflare.com> Link: https://lore.kernel.org/bpf/1667266296-8794-1-git-send-email-wangyufen@huawei.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com> Signed-off-by: NLiu Jian <liujian56@huawei.com> (cherry picked from commit 86404036)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @did-you-collect-the-wool-today virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7BQMW CVE: NA ----------------------------------------------------------------- The deafault value of NR_IRQS is not sufficient to support GICv4.1 features and ~56K LPIs. This parameter would be too small for certain server platforms where it has many IO devices and is capable of direct injection of vSGI and vLPI features. Currently, maximum of 64 + 8192 (IRQ_BITMAP_BITS) IRQ descriptors are allowed. The vCPU creation fails after reaching count ~400 with kvm-arm.vgic_v4_enable=1. This patch increases NR_IRQS to 1^19 to cover 56K LPIs and 262144 vSGIs (16vPEs x 16). ------------------------------------------------------------------ Tips: Tish is a temporary fix[1], but it has been able to solve the problem. The latest upstream version[2] depends on the 'maple tree', which is inappropriately introduced to the current kernel. ------------------------------------------------------------------- Another Tips: According to Chao Liu and Chang Liao's suggestion, modifying IRQ_BITMAP_BITS can achieve the same effect with less impact. Compared with solution[2], solution[1] has a disadvantage: the memory foot print increases as the number of VMs increases. Link: https://lore.kernel.org/linux-arm-kernel/20230104023738.1258925-1-sdonthineni@nvidia.com/ [1] Link: https://lore.kernel.org/all/20230519134902.1495562-1-sdonthineni@nvidia.com/#t [2] Signed-off-by: NShanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: NChao Liu <liuchao173@huawei.com> Signed-off-by: NChang Liao <liaochang1@huawei.com> Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com> Link:https://gitee.com/openeuler/kernel/pulls/991 Reviewed-by: Liu Chao <liuchao173@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Peng Zhang <zhangpeng362@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/GRJWIT22G2QJFYJL64FIBD6E7V5TTDY5/ From: ZhangPeng <zhangpeng362@huawei.com> Fix Fuzz test BUG_ON and failure to swap out large memory. Two userswap bugfixes synchronized from hulk5.10. ZhangPeng (2): userswap: fix BUG_ON in userfaultfd_release() userswap: fix kmalloc ENOMEM failed for a large memory -- 2.25.1 Link:https://gitee.com/openeuler/kernel/pulls/1115 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 13 6月, 2023 9 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @svishen This pull Requests refactor hclge_mac_link_status_wait and add wait until mac link down issue: https://gitee.com/openeuler/kernel/issues/I7D6IP Link:https://gitee.com/openeuler/kernel/pulls/1113 Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @Hongchen_Zhang 7A1000 int_clear register should be write 64bit aligned. Link:https://gitee.com/openeuler/kernel/pulls/1084 Reviewed-by: Guo Dongtai <guodongtai@kylinos.cn> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @Hongchen_Zhang when we test the 2k500 bmc,the system hang when send the following command: [loongson@localhost ~]# ipmi mc reset cold After apply this PR,the problem disappeared. Link:https://gitee.com/openeuler/kernel/pulls/1083 Reviewed-by: Guo Dongtai <guodongtai@kylinos.cn> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 ZhangPeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6CAIM -------------------------------- If the swapped-out memory is large, such as tens of gigabytes, we will allocate a large management structure, which may be tens of megabytes or hundreds of megabytes. So if we use kmalloc to allocate management structures it may fail. Fix this by changing kmalloc to kvzalloc and kfree to kvfree. Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>
-
由 ZhangPeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6CAIM -------------------------------- In some features of userfaultfd, vma->vm_userfaultfd_ctx.ctx may be NULL but VM_USWAP is not cleared. No longer check whether vma->vm_flags has VM_USWAP. Just remove the flag. Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>
-
由 Jie Wang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7D6IP CVE: NA ---------------------------------------------------------------------- In some configure flow of hns3 driver, for example, change mtu, it will disable MAC through firmware before configuration. But firmware disables MAC asynchronously. The rx traffic may be not stopped in this case. So fixes it by waiting until mac link is down. Fixes: a9775bb6 ("net: hns3: fix set and get link ksettings issue") Signed-off-by: NJie Wang <wangjie125@huawei.com>
-
由 Jie Wang 提交于
driver inclusion category: cleanup bugzilla: https://gitee.com/openeuler/kernel/issues/I7D6IP CVE: NA ---------------------------------------------------------------------- Some nic configurations could only be performed after link is down. So this patch refactor this API for reuse. Signed-off-by: NJie Wang <wangjie125@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Zhao Wenhui <zhaowenhui8@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/FTJHXWWTIUDTIGLFJ4DL6XSYWRZEPLE4/ Link:https://gitee.com/openeuler/kernel/pulls/1089 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/VQ5QP4GZFTJCMRJ3WK33W5A5SSQR2MY7/ Link:https://gitee.com/openeuler/kernel/pulls/1090 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 12 6月, 2023 5 次提交
-
-
由 Konstantin Komarov 提交于
mainline inclusion from mainline-v6.2-rc1 commit 0e8235d2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I79X84 CVE: CVE-2022-48502 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e8235d28f3a0e9eda9f02ff67ee566d5f42b66b -------------------------------- Added new functions index_hdr_check and index_buf_check. Now we check all stuff for correctness while reading from disk. Also fixed bug with stale nfs data. Reported-by: Nvan fantasy <g1042620637@gmail.com> Signed-off-by: NKonstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com> Conflicts: fs/ntfs3/inode.c fs/ntfs3/xattr.c
-
由 Kunkun Jiang 提交于
virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7BQMW CVE: NA ----------------------------------------------------------------- The deafault value of NR_IRQS is not sufficient to support GICv4.1 features and ~56K LPIs. This parameter would be too small for certain server platforms where it has many IO devices and is capable of direct injection of vSGI and vLPI features. Currently, maximum of 64 + 8192 (IRQ_BITMAP_BITS) IRQ descriptors are allowed. The vCPU creation fails after reaching count ~400 with kvm-arm.vgic_v4_enable=1. This patch increases NR_IRQS to 1^19 to cover 56K LPIs and 262144 vSGIs (16vPEs x 16). ------------------------------------------------------------------ Tips: This is a temporary fix[1], but it has been able to solve the problem. The latest upstream version[2] depends on the 'maple tree', which is inappropriately introduced to the current kernel. ------------------------------------------------------------------- Another Tips: According to Chao Liu and Chang Liao's suggestion, modifying IRQ_BITMAP_BITS can achieve the same effect with less impact. Compared with solution[2], solution[1] has a disadvantage: the memory foot print increases as the number of VMs increases. Link: https://lore.kernel.org/linux-arm-kernel/20230104023738.1258925-1-sdonthineni@nvidia.com/ [1] Link: https://lore.kernel.org/all/20230519134902.1495562-1-sdonthineni@nvidia.com/#t [2] Signed-off-by: NShanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: NChao Liu <liuchao173@huawei.com> Signed-off-by: NChang Liao <liaochang1@huawei.com> Signed-off-by: NKunkun Jiang <jiangkunkun@huawei.com>
-
由 Zheng Wang 提交于
stable inclusion from stable-v5.10.177 commit 2b346876b93168541a45551d5f9abd1d26102e89 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7781Q CVE: CVE-2023-33288 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2b346876b93168541a45551d5f9abd1d26102e89 -------------------------------- [ Upstream commit 47c29d69 ] In bq24190_probe, &bdi->input_current_limit_work is bound with bq24190_input_current_limit_work. When external power changed, it will call bq24190_charger_external_power_changed to start the work. If we remove the module which will call bq24190_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows: CPU0 CPUc1 |bq24190_input_current_limit_work bq24190_remove | power_supply_unregister | device_unregister | power_supply_dev_release| kfree(psy) | | | power_supply_get_property_from_supplier | //use Fix it by finishing the work before cleanup in the bq24190_remove Fixes: 97774672 ("power_supply: Initialize changed_work before calling device_add") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Conflicts: drivers/power/supply/bq24190_charger.c Signed-off-by: NZhao Wenhui <zhaowenhui8@huawei.com>
-
由 Chong Qiao 提交于
LoongArch inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7BUJN -------------------------------- Signed-off-by: NChong Qiao <qiaochong@loongson.cn> Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>
-
由 Chong Qiao 提交于
LoongArch inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7CPCD -------------------------------- Signed-off-by: NChong Qiao <qiaochong@loongson.cn> Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>
-
- 09 6月, 2023 2 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/993 https://gitee.com/openeuler/kernel/issues/I7A4LC Link:https://gitee.com/openeuler/kernel/pulls/1004 Reviewed-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Long Li <leo.lilong@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/SDZSQIDVZ6KO6663MZWABIKABBLHZOUS/ Link:https://gitee.com/openeuler/kernel/pulls/1028 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 08 6月, 2023 19 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @HuaxinLuGitee The SM2 signature for module signing is only supported with openEuler openssl 1.1.1. Fix the compile option to avoid compilation failure with openssl 3.x. Link:https://gitee.com/openeuler/kernel/pulls/1027 Reviewed-by: Zhu Jianwei <zhujianwei7@huawei.com> Signed-off-by: Zhu Jianwei <zhujianwei7@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @svishen This pull request add ROH event and default use hardware event 0 as group leader event (1)perf: hns3: add event suppport for ROH (2)perf: hns3: default use hardware event 0 as group leader event issue: https://gitee.com/openeuler/kernel/issues/I7BY7T Link:https://gitee.com/openeuler/kernel/pulls/1007 Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @xiao_jiang_shui The problem of service interruption and loss may be triggered during live migration. In order to ensure normal business, it is necessary to resend an interrupt in the live migration driver. And in the QM service driver, it is guaranteed that the retransmission interrupt can be received normally. issue: https://gitee.com/openeuler/kernel/issues/I7BTMW Link:https://gitee.com/openeuler/kernel/pulls/1032 Reviewed-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @hejunhao3 The driver needs to migrate the perf context if the current using CPU going to teardown. By the time calling the cpuhp::teardown() callback the cpu_online_mask() hasn't updated yet and still includes the CPU going to teardown. In current driver's implementation we may migrate the context to the teardown CPU and leads to the below calltrace: ... [ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008 [ 368.113699][ T932] Call trace: [ 368.116834][ T932] __switch_to+0x7c/0xbc [ 368.120924][ T932] __schedule+0x338/0x6f0 [ 368.125098][ T932] schedule+0x50/0xe0 [ 368.128926][ T932] schedule_preempt_disabled+0x18/0x24 [ 368.134229][ T932] __mutex_lock.constprop.0+0x1d4/0x5dc [ 368.139617][ T932] __mutex_lock_slowpath+0x1c/0x30 [ 368.144573][ T932] mutex_lock+0x50/0x60 [ 368.148579][ T932] perf_pmu_migrate_context+0x84/0x2b0 [ 368.153884][ T932] hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu] [ 368.160579][ T932] cpuhp_invoke_callback+0x2a0/0x650 [ 368.165707][ T932] cpuhp_thread_fun+0xe4/0x190 [ 368.170316][ T932] smpboot_thread_fn+0x15c/0x1a0 [ 368.175099][ T932] kthread+0x108/0x13c [ 368.179012][ T932] ret_from_fork+0x10/0x18 ... Use function cpumask_any_but() to find one correct active cpu to fixes this issue. Link:https://gitee.com/openeuler/kernel/pulls/1019 Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Longfang Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7BTMW CVE: NA ---------------------------------------------------------------------- During repeated live migration. There may be a problem with missing interrupts. In this case, re-send the doorbell on the migration end. Let QM report an interrupt again, and migrate the interrupt to the destination together. Thereby preventing the problem of interrupt loss. fixec: a0464f0b ("vfio/hisilicon: add acc live migration driver") Signed-off-by: NLongfang Liu <liulongfang@huawei.com> Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>
-
由 Longfang Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7BTMW CVE: NA ---------------------------------------------------------------------- During a live migration operation. In order to prevent the problem of EQ/AEQ interrupt loss. Migration driver will trigger an EQ/AEQ doorbell at the end of the migration. This operation may cause a double interrupt of EQ/AEQ. In order to ensure that the interrupt processing is normal. The interrupt handling of EQ/AEQ needs to be updated to prevent interrupt duplication. fixec: a0464f0b ("vfio/hisilicon: add acc live migration driver") Signed-off-by: NLongfang Liu <liulongfang@huawei.com> Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>
-
由 Dongliang Mu 提交于
stable inclusion from stable-v5.10.167 commit ef7d71d7bd57b8b7fe514e459927696c1c6d1047 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I79LIO CVE: CVE-2023-2985 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=ef7d71d7bd57b8b7fe514e459927696c1c6d1047 -------------------------------- commit 07db5e24 upstream. The current hfsplus_put_super first calls hfs_btree_close on sbi->ext_tree, then invokes iput on sbi->hidden_dir, resulting in an use-after-free issue in hfsplus_release_folio. As shown in hfsplus_fill_super, the error handling code also calls iput before hfs_btree_close. To fix this error, we move all iput calls before hfsplus_btree_close. Note that this patch is tested on Syzbot. Link: https://lkml.kernel.org/r/20230226124948.3175736-1-mudongliangabcd@gmail.com Reported-by: syzbot+57e3e98f7e3b80f64d56@syzkaller.appspotmail.com Tested-by: NDongliang Mu <mudongliangabcd@gmail.com> Signed-off-by: NDongliang Mu <mudongliangabcd@gmail.com> Cc: Bart Van Assche <bvanassche@acm.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Muchun Song <songmuchun@bytedance.com> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLong Li <leo.lilong@huawei.com> Reviewed-by: NYang Erkun <yangerkun@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Li Lingfeng <lilingfeng3@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/DP5GHDF7ULWL52W5DGYZWS6HBE5WJ52E/ patch1: arch: setup PF_IO_WORKER threads like PF_KTHREAD pre patch of patch4 patch2: arch: ensure parisc/powerpc handle PF_IO_WORKER in copy_thread() fix patch of patch1 patch3: kernel: don't call do_exit() for PF_IO_WORKER threads fix the segfault patch4: x86/process: setup io_threads more like normal user space threads allow io worker to exit Jens Axboe (3): arch: setup PF_IO_WORKER threads like PF_KTHREAD arch: ensure parisc/powerpc handle PF_IO_WORKER in copy_thread() kernel: don't call do_exit() for PF_IO_WORKER threads Stefan Metzmacher (1): x86/process: setup io_threads more like normal user space threads -- 2.31.1 Link:https://gitee.com/openeuler/kernel/pulls/978 Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @chenke1978 When the ROH CMDQ processes multiple BDs, the operations are inconsistent with those in the UM manual. As a result, the CMDQ parses unexpected return values, interrupts the CMDQ processing process, and the ROH MIB statistics query may fail. This patch fix the process method of roh cmdq multiple BDs. Link:https://gitee.com/openeuler/kernel/pulls/1003 Reviewed-by: Ling Mingqiang <lingmingqiang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Junhao He 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7BUN2 CVE: NA ---------------------------------------------------------------------- The driver needs to migrate the perf context if the current using CPU going to teardown. By the time calling the cpuhp::teardown() callback the cpu_online_mask() hasn't updated yet and still includes the CPU going to teardown. In current driver's implementation we may migrate the context to the teardown CPU and leads to the below calltrace: ... [ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008 [ 368.113699][ T932] Call trace: [ 368.116834][ T932] __switch_to+0x7c/0xbc [ 368.120924][ T932] __schedule+0x338/0x6f0 [ 368.125098][ T932] schedule+0x50/0xe0 [ 368.128926][ T932] schedule_preempt_disabled+0x18/0x24 [ 368.134229][ T932] __mutex_lock.constprop.0+0x1d4/0x5dc [ 368.139617][ T932] __mutex_lock_slowpath+0x1c/0x30 [ 368.144573][ T932] mutex_lock+0x50/0x60 [ 368.148579][ T932] perf_pmu_migrate_context+0x84/0x2b0 [ 368.153884][ T932] hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu] [ 368.160579][ T932] cpuhp_invoke_callback+0x2a0/0x650 [ 368.165707][ T932] cpuhp_thread_fun+0xe4/0x190 [ 368.170316][ T932] smpboot_thread_fn+0x15c/0x1a0 [ 368.175099][ T932] kthread+0x108/0x13c [ 368.179012][ T932] ret_from_fork+0x10/0x18 ... Use function cpumask_any_but() to find one correct active cpu to fixes this issue. Fixes: 8404b0fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU") Signed-off-by: NJunhao He <hejunhao3@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Zhong Jinghua <zhongjinghua@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/SH7IMWAMZDZBA352XEQZ4WD6CFY3EGCW/ Link:https://gitee.com/openeuler/kernel/pulls/944 Reviewed-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Li Lingfeng <lilingfeng3@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/XNE65PIJUOQRSLID56LFRUSB3FNDYMGE/ Link:https://gitee.com/openeuler/kernel/pulls/920 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Li Lingfeng <lilingfeng3@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/KP2DRRZQIPU5IM7FF4GECWSW5466QLFH/ Link:https://gitee.com/openeuler/kernel/pulls/924 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Hao Chen 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7BY7T CVE: NA ---------------------------------------------------------------------- For hns3 pmu events, we use command as below before: perf stat -g -e hns3_pmu_sicl_0/config=0x00105,global=1/ -e hns3_pmu_sicl_0/config=0x10105,global=1/ -I 1000 We want 0x00105 event and 0x10105 event share a hardware event, but for kernel 6.2 'commit 5f8f9567 ("perf evlist: Remove group option.")' remove -g parameter. So add this patch to set default related event idx as 0 to share the first hardware event. Fixes: 66637ab1 ("drivers/perf: hisi: add driver for HNS3 PMU") Signed-off-by: NHao Chen <chenhao418@huawei.com>
-
由 Jian Shen 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7BY7T CVE: NA ---------------------------------------------------------------------- Add ROH events support. Fixes: 66637ab1 ("drivers/perf: hisi: add driver for HNS3 PMU") Signed-off-by: NJian Shen <shenjian15@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @xiao_jiang_shui The mailbox of the Kunpeng accelerator is a special operation. Data(128 bits) needs to be read from hardware or written to hardware at one time. And the operation cannot be canceled by software. Therefore, the software process needs to be modified to avoid mailbox operation errors. Weili Qian (4): crypto: hisilicon/qm - obtain the mailbox configuration at one time vfio/migration: obtain the mailbox configuration at one time crypto: hisilicon/qm - fix the pf2vf timeout when device reset crypto: hisilicon/qm - alloc buffer to set and get xqc issue: https://gitee.com/openeuler/kernel/issues/I7BJW9 Link:https://gitee.com/openeuler/kernel/pulls/980 Reviewed-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @Hongchen_Zhang LS7A Root Ports have a hardware defect: clearing PCI_COMMAND_MASTER *also* prevents the bridge from forwarding CPU MMIO requests in the downstream direction, and these MMIO accesses to devices below the bridge happen even after .shutdown(), e.g., to print console messages. LS7A neither forwards the requests nor sends an unsuccessful completion to the CPU, so the CPU waits forever, resulting in the hang. After apply this PR,the machine which has 2k500 bmc connected to the LS7A bridge can reboot normally. Link:https://gitee.com/openeuler/kernel/pulls/941 Reviewed-by: Guo Dongtai <guodongtai@kylinos.cn> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I77OGM --------------------------------------------------------------- When the ROH CMDQ processes multiple BDs, the operations are inconsistent with those in the UM manual. As a result, the CMDQ parses unexpected return values, interrupts the CMDQ processing process, and the ROH MIB statistics query may fail. This patch fix the process method of roh cmdq multiple BDs. Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com>
-
由 Yangyang Li 提交于
mainline inclusion from mainline-v6.1-rc1 commit 5436272c category: cleanup bugzilla: https://gitee.com/openeuler/kernel/issues/I7A4LC CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5436272c8cf4eb420fdb3926ec07560051c8fd11 ---------------------------------------------------------------------- The num_mtt_segs and max_extend_sg used to be used for HIP06, remove them since the HIP06 code has been removed. Link: https://lore.kernel.org/r/20220922123315.3732205-9-xuhaoyue1@hisilicon.comSigned-off-by: NYangyang Li <liyangyang20@huawei.com> Signed-off-by: NHaoyue Xu <xuhaoyue1@hisilicon.com> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com> Signed-off-by: NZhou Juan <nnuzj07170227@163.com> (cherry picked from commit c08f6dd3)
-