- Kernel - mailweb.openeuler.org

[PATCH rdma-core v4 0/2] Support congestion control algorithm
by Chengchang Tang 12 Apr '23

12 Apr '23

From: Juan Zhou <zhoujuan51(a)h-partners.com> Yixing Liu (2): Update kernel headers libhns: Support congestion control algorithm configuration kernel-headers/rdma/hns-abi.h | 18 ++++- providers/hns/hns_roce_u.c | 1 + providers/hns/hns_roce_u.h | 6 ++ providers/hns/hns_roce_u_verbs.c | 114 +++++++++++++++++++++++++++++-- providers/hns/hnsdv.h | 24 ++++++- providers/hns/libhns.map | 1 + 6 files changed, 156 insertions(+), 8 deletions(-) -- 2.30.0

1 2

[OLK-5.10 v5 0/2] Support congestion control algorithm
by Chengchang Tang 12 Apr '23

12 Apr '23

From: Juan Zhou <zhoujuan51(a)h-partners.com> This group of patches implements the congestion control algorithm configuration. Yixing Liu (2): RDMA/hns: Modify congestion abbreviation RDMA/hns: Support congestion control algorithm configuration at QP granularity drivers/infiniband/hw/hns/hns_roce_device.h | 16 +-- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 113 ++++++++++---------- drivers/infiniband/hw/hns/hns_roce_hw_v2.h | 11 +- drivers/infiniband/hw/hns/hns_roce_main.c | 4 + drivers/infiniband/hw/hns/hns_roce_qp.c | 46 ++++++++ drivers/infiniband/hw/hns/hns_roce_sysfs.c | 2 +- include/uapi/rdma/hns-abi.h | 18 +++- 7 files changed, 142 insertions(+), 68 deletions(-) -- 2.30.0

1 2

[PATCH openEuler-5.10-LTS 01/27] xfs: log worker needs to start before intent/unlink recovery
by Jialin Zhang 12 Apr '23

12 Apr '23

From: Dave Chinner <dchinner(a)redhat.com> mainline inclusion from mainline-v5.17-rc6 commit a9a4bc8c76d747aa40b30e2dfc176c781f353a08 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4KIAO CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- After 963 iterations of generic/530, it deadlocked during recovery on a pinned inode cluster buffer like so: XFS (pmem1): Starting recovery (logdev: internal) INFO: task kworker/8:0:306037 blocked for more than 122 seconds. Not tainted 5.17.0-rc6-dgc+ #975 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:0 state:D stack:13024 pid:306037 ppid: 2 flags:0x00004000 Workqueue: xfs-inodegc/pmem1 xfs_inodegc_worker Call Trace: <TASK> __schedule+0x30d/0x9e0 schedule+0x55/0xd0 schedule_timeout+0x114/0x160 __down+0x99/0xf0 down+0x5e/0x70 xfs_buf_lock+0x36/0xf0 xfs_buf_find+0x418/0x850 xfs_buf_get_map+0x47/0x380 xfs_buf_read_map+0x54/0x240 xfs_trans_read_buf_map+0x1bd/0x490 xfs_imap_to_bp+0x4f/0x70 xfs_iunlink_map_ino+0x66/0xd0 xfs_iunlink_map_prev.constprop.0+0x148/0x2f0 xfs_iunlink_remove_inode+0xf2/0x1d0 xfs_inactive_ifree+0x1a3/0x900 xfs_inode_unlink+0xcc/0x210 xfs_inodegc_worker+0x1ac/0x2f0 process_one_work+0x1ac/0x390 worker_thread+0x56/0x3c0 kthread+0xf6/0x120 ret_from_fork+0x1f/0x30 </TASK> task:mount state:D stack:13248 pid:324509 ppid:324233 flags:0x00004000 Call Trace: <TASK> __schedule+0x30d/0x9e0 schedule+0x55/0xd0 schedule_timeout+0x114/0x160 __down+0x99/0xf0 down+0x5e/0x70 xfs_buf_lock+0x36/0xf0 xfs_buf_find+0x418/0x850 xfs_buf_get_map+0x47/0x380 xfs_buf_read_map+0x54/0x240 xfs_trans_read_buf_map+0x1bd/0x490 xfs_imap_to_bp+0x4f/0x70 xfs_iget+0x300/0xb40 xlog_recover_process_one_iunlink+0x4c/0x170 xlog_recover_process_iunlinks.isra.0+0xee/0x130 xlog_recover_finish+0x57/0x110 xfs_log_mount_finish+0xfc/0x1e0 xfs_mountfs+0x540/0x910 xfs_fs_fill_super+0x495/0x850 get_tree_bdev+0x171/0x270 xfs_fs_get_tree+0x15/0x20 vfs_get_tree+0x24/0xc0 path_mount+0x304/0xba0 __x64_sys_mount+0x108/0x140 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> task:xfsaild/pmem1 state:D stack:14544 pid:324525 ppid: 2 flags:0x00004000 Call Trace: <TASK> __schedule+0x30d/0x9e0 schedule+0x55/0xd0 io_schedule+0x4b/0x80 xfs_buf_wait_unpin+0x9e/0xf0 __xfs_buf_submit+0x14a/0x230 xfs_buf_delwri_submit_buffers+0x107/0x280 xfs_buf_delwri_submit_nowait+0x10/0x20 xfsaild+0x27e/0x9d0 kthread+0xf6/0x120 ret_from_fork+0x1f/0x30 We have the mount process waiting on an inode cluster buffer read, inodegc doing unlink waiting on the same inode cluster buffer, and the AIL push thread blocked in writeback waiting for the inode cluster buffer to become unpinned. What has happened here is that the AIL push thread has raced with the inodegc process modifying, committing and pinning the inode cluster buffer here in xfs_buf_delwri_submit_buffers() here: blk_start_plug(&plug); list_for_each_entry_safe(bp, n, buffer_list, b_list) { if (!wait_list) { if (xfs_buf_ispinned(bp)) { pinned++; continue; } Here >>>>>> if (!xfs_buf_trylock(bp)) continue; Basically, the AIL has found the buffer wasn't pinned and got the lock without blocking, but then the buffer was pinned. This implies the processing here was pre-empted between the pin check and the lock, because the pin count can only be increased while holding the buffer locked. Hence when it has gone to submit the IO, it has blocked waiting for the buffer to be unpinned. With all executing threads now waiting on the buffer to be unpinned, we normally get out of situations like this via the background log worker issuing a log force which will unpinned stuck buffers like this. But at this point in recovery, we haven't started the log worker. In fact, the first thing we do after processing intents and unlinked inodes is *start the log worker*. IOWs, we start it too late to have it break deadlocks like this. Avoid this and any other similar deadlock vectors in intent and unlinked inode recovery by starting the log worker before we recover intents and unlinked inodes. This part of recovery runs as though the filesystem is fully active, so we really should have the same infrastructure running as we normally do at runtime. Signed-off-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Chandan Babu R <chandan.babu(a)oracle.com> Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> Reviewed-by: Yang Erkun <yangerkun(a)huawei.com> Reviewed-by: Zhang Yi <yi.zhang(a)huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11(a)huawei.com> --- fs/xfs/xfs_log.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index 92c5d6ef47d6..e154c0d44f9c 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -782,10 +782,9 @@ xfs_log_mount_finish( * mount failure occurs. */ mp->m_super->s_flags |= SB_ACTIVE; + xfs_log_work_queue(mp); if (xlog_recovery_needed(log)) error = xlog_recover_finish(log); - if (!error) - xfs_log_work_queue(mp); mp->m_super->s_flags &= ~SB_ACTIVE; evict_inodes(mp->m_super); -- 2.25.1

1 26

[PATCH openEuler-5.10-LTS-SP1 01/33] xfs: log worker needs to start before intent/unlink recovery
by Jialin Zhang 12 Apr '23

12 Apr '23

From: Dave Chinner <dchinner(a)redhat.com> mainline inclusion from mainline-v5.17-rc6 commit a9a4bc8c76d747aa40b30e2dfc176c781f353a08 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4KIAO CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- After 963 iterations of generic/530, it deadlocked during recovery on a pinned inode cluster buffer like so: XFS (pmem1): Starting recovery (logdev: internal) INFO: task kworker/8:0:306037 blocked for more than 122 seconds. Not tainted 5.17.0-rc6-dgc+ #975 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:0 state:D stack:13024 pid:306037 ppid: 2 flags:0x00004000 Workqueue: xfs-inodegc/pmem1 xfs_inodegc_worker Call Trace: <TASK> __schedule+0x30d/0x9e0 schedule+0x55/0xd0 schedule_timeout+0x114/0x160 __down+0x99/0xf0 down+0x5e/0x70 xfs_buf_lock+0x36/0xf0 xfs_buf_find+0x418/0x850 xfs_buf_get_map+0x47/0x380 xfs_buf_read_map+0x54/0x240 xfs_trans_read_buf_map+0x1bd/0x490 xfs_imap_to_bp+0x4f/0x70 xfs_iunlink_map_ino+0x66/0xd0 xfs_iunlink_map_prev.constprop.0+0x148/0x2f0 xfs_iunlink_remove_inode+0xf2/0x1d0 xfs_inactive_ifree+0x1a3/0x900 xfs_inode_unlink+0xcc/0x210 xfs_inodegc_worker+0x1ac/0x2f0 process_one_work+0x1ac/0x390 worker_thread+0x56/0x3c0 kthread+0xf6/0x120 ret_from_fork+0x1f/0x30 </TASK> task:mount state:D stack:13248 pid:324509 ppid:324233 flags:0x00004000 Call Trace: <TASK> __schedule+0x30d/0x9e0 schedule+0x55/0xd0 schedule_timeout+0x114/0x160 __down+0x99/0xf0 down+0x5e/0x70 xfs_buf_lock+0x36/0xf0 xfs_buf_find+0x418/0x850 xfs_buf_get_map+0x47/0x380 xfs_buf_read_map+0x54/0x240 xfs_trans_read_buf_map+0x1bd/0x490 xfs_imap_to_bp+0x4f/0x70 xfs_iget+0x300/0xb40 xlog_recover_process_one_iunlink+0x4c/0x170 xlog_recover_process_iunlinks.isra.0+0xee/0x130 xlog_recover_finish+0x57/0x110 xfs_log_mount_finish+0xfc/0x1e0 xfs_mountfs+0x540/0x910 xfs_fs_fill_super+0x495/0x850 get_tree_bdev+0x171/0x270 xfs_fs_get_tree+0x15/0x20 vfs_get_tree+0x24/0xc0 path_mount+0x304/0xba0 __x64_sys_mount+0x108/0x140 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> task:xfsaild/pmem1 state:D stack:14544 pid:324525 ppid: 2 flags:0x00004000 Call Trace: <TASK> __schedule+0x30d/0x9e0 schedule+0x55/0xd0 io_schedule+0x4b/0x80 xfs_buf_wait_unpin+0x9e/0xf0 __xfs_buf_submit+0x14a/0x230 xfs_buf_delwri_submit_buffers+0x107/0x280 xfs_buf_delwri_submit_nowait+0x10/0x20 xfsaild+0x27e/0x9d0 kthread+0xf6/0x120 ret_from_fork+0x1f/0x30 We have the mount process waiting on an inode cluster buffer read, inodegc doing unlink waiting on the same inode cluster buffer, and the AIL push thread blocked in writeback waiting for the inode cluster buffer to become unpinned. What has happened here is that the AIL push thread has raced with the inodegc process modifying, committing and pinning the inode cluster buffer here in xfs_buf_delwri_submit_buffers() here: blk_start_plug(&plug); list_for_each_entry_safe(bp, n, buffer_list, b_list) { if (!wait_list) { if (xfs_buf_ispinned(bp)) { pinned++; continue; } Here >>>>>> if (!xfs_buf_trylock(bp)) continue; Basically, the AIL has found the buffer wasn't pinned and got the lock without blocking, but then the buffer was pinned. This implies the processing here was pre-empted between the pin check and the lock, because the pin count can only be increased while holding the buffer locked. Hence when it has gone to submit the IO, it has blocked waiting for the buffer to be unpinned. With all executing threads now waiting on the buffer to be unpinned, we normally get out of situations like this via the background log worker issuing a log force which will unpinned stuck buffers like this. But at this point in recovery, we haven't started the log worker. In fact, the first thing we do after processing intents and unlinked inodes is *start the log worker*. IOWs, we start it too late to have it break deadlocks like this. Avoid this and any other similar deadlock vectors in intent and unlinked inode recovery by starting the log worker before we recover intents and unlinked inodes. This part of recovery runs as though the filesystem is fully active, so we really should have the same infrastructure running as we normally do at runtime. Signed-off-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Chandan Babu R <chandan.babu(a)oracle.com> Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> Reviewed-by: Yang Erkun <yangerkun(a)huawei.com> Reviewed-by: Zhang Yi <yi.zhang(a)huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11(a)huawei.com> --- fs/xfs/xfs_log.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index 92c5d6ef47d6..e154c0d44f9c 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -782,10 +782,9 @@ xfs_log_mount_finish( * mount failure occurs. */ mp->m_super->s_flags |= SB_ACTIVE; + xfs_log_work_queue(mp); if (xlog_recovery_needed(log)) error = xlog_recover_finish(log); - if (!error) - xfs_log_work_queue(mp); mp->m_super->s_flags &= ~SB_ACTIVE; evict_inodes(mp->m_super); -- 2.25.1

1 32

[PATCH openEuler-1.0-LTS] hwmon: (xgene) Fix use after free bug in xgene_hwmon_remove due to race condition
by Yongqiang Liu 11 Apr '23

11 Apr '23

From: Zheng Wang <zyytlz.wz(a)163.com> mainline inclusion from mainline-v6.3-rc3 commit cb090e64cf25602b9adaf32d5dfc9c8bec493cd1 category: bugfix bugzilla: 188657, https://gitee.com/src-openeuler/kernel/issues/I6T36A CVE: CVE-2023-1855 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In xgene_hwmon_probe, &ctx->workq is bound with xgene_hwmon_evt_work. Then it will be started. If we remove the driver which will call xgene_hwmon_remove to clean up, there may be unfinished work. The possible sequence is as follows: Fix it by finishing the work before cleanup in xgene_hwmon_remove. CPU0 CPU1 |xgene_hwmon_evt_work xgene_hwmon_remove | kfifo_free(&ctx->async_msg_fifo);| | |kfifo_out_spinlocked |//use &ctx->async_msg_fifo Fixes: 2ca492e22cb7 ("hwmon: (xgene) Fix crash when alarm occurs before driver probe") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Link: https://lore.kernel.org/r/20230310084007.1403388-1-zyytlz.wz@163.com Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Zhao Wenhui <zhaowenhui8(a)huawei.com> Reviewed-by: songping yu <yusongping(a)huawei.com> Reviewed-by: Zhang Qiao <zhangqiao22(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- drivers/hwmon/xgene-hwmon.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c index a3cd91f23267..2dd19a420305 100644 --- a/drivers/hwmon/xgene-hwmon.c +++ b/drivers/hwmon/xgene-hwmon.c @@ -780,6 +780,7 @@ static int xgene_hwmon_remove(struct platform_device *pdev) { struct xgene_hwmon_dev *ctx = platform_get_drvdata(pdev); + cancel_work_sync(&ctx->workq); hwmon_device_unregister(ctx->hwmon_dev); kfifo_free(&ctx->async_msg_fifo); if (acpi_disabled) -- 2.25.1

1 0

[Dev] Kernel SIG邀请您参加2023年4月20日~21日 openEuler Developer Day SIG组开放工作会议
by Zhengzengkai 11 Apr '23

11 Apr '23

��ã� openEuler Developer Day 2023(�� ODD 2023�� openEuler��ȶ��飬 �ǿ��ԭ�ӿ�Դ�� openEuler ��Ŀ��߷�ᡣ ODD 2023��2023��4��20��~21��Ϻ��ֶ��Ƶ��У��ӭ��ұ��λᡣ ��̼��Ϣ�ɲο��ӣ�https://www.openeuler.org/zh/interaction/summit-list/devday2023/ ��ӣ�https://e-campaign.huawei.com/m/RNN3Yz ��openEuler Kernel SIG��μ�4��21��16��00 �C 17��30��е�ODD 2023 Kernel SIG��¿��Ź��飬 ��ʱ��ߣ��潻�� ¿��Ź��ǰ�ռ��⣬�밴��+��+��ˡ��ʽ�ύ��etherpad�� https://etherpad.openeuler.org/p/ODD2023_Kernel_SIG

1 0

[PATCH] fs: eulerfs: fix wrong dereferencing in eufs_lookup
by Kang Chen 10 Apr '23

10 Apr '23

inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TN56 -------------------------------- smatch report: fs/eulerfs/namei.c:118 eufs_lookup() error: 'inode' dereferencing possible ERR_PTR() Signed-off-by: Kang Chen <void0red(a)hust.edu.cn> --- I run smatch on the openEuler-2203-sp1 source and find some bugs. But I have on idea on the fields of the commit message template. Please let me know if there is anything that can be improved. fs/eulerfs/namei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/eulerfs/namei.c b/fs/eulerfs/namei.c index e4c6c36575f2..cfba6eefbcc8 100644 --- a/fs/eulerfs/namei.c +++ b/fs/eulerfs/namei.c @@ -116,7 +116,7 @@ static struct dentry *eufs_lookup(struct inode *dir, struct dentry *dentry, inode = eufs_iget(dir->i_sb, s2p(dir->i_sb, de->inode)); if (inode == ERR_PTR(-ESTALE)) { eufs_err(dir->i_sb, "deleted inode referenced: 0x%lx", - inode->i_ino); + le64_to_cpu(de->inode)); return ERR_PTR(-EIO); } not_found: -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] xirc2ps_cs: Fix use after free bug in xirc2ps_detach
by Yongqiang Liu 10 Apr '23

10 Apr '23

From: Zheng Wang <zyytlz.wz(a)163.com> stable inclusion from stable-v4.19.279 commit 526660c25d3b93b1232a525b75469048388f0928 category: bugfix bugzilla: 188641, https://gitee.com/src-openeuler/kernel/issues/I6R4MM CVE: CVE-2023-1670 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e8d20c3ded59a092532513c9bd030d1ea66f5f44 ] In xirc2ps_probe, the local->tx_timeout_task was bounded with xirc2ps_tx_timeout_task. When timeout occurs, it will call xirc_tx_timeout->schedule_work to start the work. When we call xirc2ps_detach to remove the driver, there may be a sequence as follows: Stop responding to timeout tasks and complete scheduled tasks before cleanup in xirc2ps_detach, which will fix the problem. CPU0 CPU1 |xirc2ps_tx_timeout_task xirc2ps_detach | free_netdev | kfree(dev); | | | do_reset | //use dev Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> Reviewed-by: Liu Jian <liujian56(a)huawei.com> Reviewed-by: Wang Weiyang <wangweiyang2(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- drivers/net/ethernet/xircom/xirc2ps_cs.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/ethernet/xircom/xirc2ps_cs.c b/drivers/net/ethernet/xircom/xirc2ps_cs.c index fd5288ff53b5..e3438cef5f9c 100644 --- a/drivers/net/ethernet/xircom/xirc2ps_cs.c +++ b/drivers/net/ethernet/xircom/xirc2ps_cs.c @@ -503,6 +503,11 @@ static void xirc2ps_detach(struct pcmcia_device *link) { struct net_device *dev = link->priv; + struct local_info *local = netdev_priv(dev); + + netif_carrier_off(dev); + netif_tx_disable(dev); + cancel_work_sync(&local->tx_timeout_task); dev_dbg(&link->dev, "detach\n"); -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS] 9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition
by Yongqiang Liu 10 Apr '23

10 Apr '23

From: Zheng Wang <zyytlz.wz(a)163.com> maillist inclusion category: bugfix bugzilla: 188655, https://gitee.com/src-openeuler/kernel/issues/I6T36H CVE: CVE-2023-1859 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/… ---------------------------------------- In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring to init priv->rings and bound &ring->work with p9_xen_response. When it calls xen_9pfs_front_event_handler to handle IRQ requests, it will finally call schedule_work to start the work. When we call xen_9pfs_front_remove to remove the driver, there may be a sequence as follows: Fix it by finishing the work before cleanup in xen_9pfs_front_free. Note that, this bug is found by static analysis, which might be false positive. CPU0 CPU1 |p9_xen_response xen_9pfs_front_remove| xen_9pfs_front_free| kfree(priv) | //free priv | |p9_tag_lookup |//use priv->client Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski(a)linux.intel.com> Signed-off-by: Eric Van Hensbergen <ericvh(a)kernel.org> Signed-off-by: Lu Wei <luwei32(a)huawei.com> Reviewed-by: Yue Haibing <yuehaibing(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- net/9p/trans_xen.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c index 81002cba88b3..8e158f09cba8 100644 --- a/net/9p/trans_xen.c +++ b/net/9p/trans_xen.c @@ -290,6 +290,10 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) write_unlock(&xen_9pfs_lock); for (i = 0; i < priv->num_rings; i++) { + struct xen_9pfs_dataring *ring = &priv->rings[i]; + + cancel_work_sync(&ring->work); + if (!priv->rings[i].intf) break; if (priv->rings[i].irq > 0) -- 2.25.1

1 0

[PATCH OLK-5.10] KVM: nVMX: Set LDTR to its architecturally defined value on nested VM-Exit
by 任敏敏(联通集团联通数字科技有限公司本部) 10 Apr '23

10 Apr '23

From: Sean Christopherson <seanjc(a)google.com> stable inclusion from stable-v5.15 commit afc8de0118be84f4058b9977d481aeb3e0758dbb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6SN2F CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------ commit afc8de0118be84f4058b9977d481aeb3e0758dbb upstream Set L1's LDTR on VM-Exit per the Intel SDM: The host-state area does not contain a selector field for LDTR. LDTR is established as follows on all VM exits: the selector is cleared to 0000H, the segment is marked unusable and is otherwise undefined (although the base address is always canonical). This is likely a benign bug since the LDTR is unusable, as it means the L1 VMM is conditioned to reload its LDTR in order to function properly on bare metal. Fixes: 4704d0befb07 ("KVM: nVMX: Exiting from L2 to L1") Reviewed-by: Reiji Watanabe <reijiw(a)google.com> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20210713163324.627647-3-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: rminmin <renmm6(a)chinaunicom.cn> --- arch/x86/kvm/vmx/nested.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index 9003b14d72ca..05284589c14d 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -4326,6 +4326,10 @@ static void load_vmcs12_host_state(struct kvm_vcpu *vcpu, }; vmx_set_segment(vcpu, &seg, VCPU_SREG_TR); + memset(&seg, 0, sizeof(seg)); + seg.unusable = 1; + vmx_set_segment(vcpu, &seg, VCPU_SREG_LDTR); + kvm_set_dr(vcpu, 7, 0x400); vmcs_write64(GUEST_IA32_DEBUGCTL, 0); -- 2.33.0 Èç¹ûÄúŽíÎóœÓÊÕÁËžÃÓÊŒþ£¬ÇëÍš¹ýµç×ÓÓÊŒþÁ¢ŒŽÍšÖªÎÒÃÇ¡£Çë»ØžŽÓÊŒþµœ hqs-spmc@chinaunicom.cn£¬ŒŽ¿ÉÒÔÍË¶©ŽËÓÊŒþ¡£ÎÒÃÇœ«Á¢ŒŽœ«ÄúµÄÐÅÏ¢ŽÓÎÒÃÇµÄ·¢ËÍÄ¿ÂŒÖÐÉŸ³ý¡£ If you have received this email in error please notify us immediately by e-mail. Please reply to hqs-spmc(a)chinaunicom.cn ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

1 0

2024

2023

2022

2021

2020

2019

Kernel