September 2024 - Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1] efi: fix NULL-deref in init error path
by Gu Bowen 02 Sep '24

02 Sep '24

From: Johan Hovold <johan+linaro(a)kernel.org> stable inclusion from stable-v5.10.164 commit 4ca71bc0e1995d15486cd7b60845602a28399cb5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALIAT CVE: CVE-2022-48879 Reference:https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/… -------------------------------- [ Upstream commit 703c13fe3c9af557d312f5895ed6a5fda2711104 ] In cases where runtime services are not supported or have been disabled, the runtime services workqueue will never have been allocated. Do not try to destroy the workqueue unconditionally in the unlikely event that EFI initialisation fails to avoid dereferencing a NULL pointer. Fixes: 98086df8b70c ("efi: add missed destroy_workqueue when efisubsys_init fails") Cc: stable(a)vger.kernel.org Cc: Li Heng <liheng40(a)huawei.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- drivers/firmware/efi/efi.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 97a0916d6502..534688df3655 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -386,8 +386,8 @@ static int __init efisubsys_init(void) efi_kobj = kobject_create_and_add("efi", firmware_kobj); if (!efi_kobj) { pr_err("efi: Firmware registration failed.\n"); - destroy_workqueue(efi_rts_wq); - return -ENOMEM; + error = -ENOMEM; + goto err_destroy_wq; } if (efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE | @@ -430,7 +430,10 @@ static int __init efisubsys_init(void) generic_ops_unregister(); err_put: kobject_put(efi_kobj); - destroy_workqueue(efi_rts_wq); +err_destroy_wq: + if (efi_rts_wq) + destroy_workqueue(efi_rts_wq); + return error; } -- 2.25.1

2 1

[PATCH OLK-6.6] nvme-fabrics: use reserved tag for reg read/write command
by Wupeng Ma 02 Sep '24

02 Sep '24

From: Chunguang Xu <chunguang.xu(a)shopee.com> mainline inclusion from mainline-v6.10-rc3 commit 7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEKB CVE: CVE-2024-41082 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. For the enable ctrl / fw activate path, since connect and reg_xx() are called serially. So the reserved tags may still be enough while reg_xx() use reserved tags. Signed-off-by: Chunguang Xu <chunguang.xu(a)shopee.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/host/fabrics.c [Ma Wupeng: BLK_MQ_REQ_RESERVED is replaced by NVME_SUBMIT_RESERVED in v6.8] Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- drivers/nvme/host/fabrics.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c index 92ba315cfe19..b0290e3de929 100644 --- a/drivers/nvme/host/fabrics.c +++ b/drivers/nvme/host/fabrics.c @@ -179,7 +179,7 @@ int nvmf_reg_read32(struct nvme_ctrl *ctrl, u32 off, u32 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, - NVME_QID_ANY, 0, 0); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -225,7 +225,7 @@ int nvmf_reg_read64(struct nvme_ctrl *ctrl, u32 off, u64 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, - NVME_QID_ANY, 0, 0); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -270,7 +270,7 @@ int nvmf_reg_write32(struct nvme_ctrl *ctrl, u32 off, u32 val) cmd.prop_set.value = cpu_to_le64(val); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, NULL, NULL, 0, - NVME_QID_ANY, 0, 0); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED); if (unlikely(ret)) dev_err(ctrl->device, "Property Set error: %d, offset %#x\n", -- 2.25.1

2 1

[PATCH OLK-5.10] nvme-fabrics: use reserved tag for reg read/write command
by Wupeng Ma 02 Sep '24

02 Sep '24

From: Chunguang Xu <chunguang.xu(a)shopee.com> mainline inclusion from mainline-v6.10-rc3 commit 7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEKB CVE: CVE-2024-41082 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. For the enable ctrl / fw activate path, since connect and reg_xx() are called serially. So the reserved tags may still be enough while reg_xx() use reserved tags. Signed-off-by: Chunguang Xu <chunguang.xu(a)shopee.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/host/fabrics.c [Ma Wupeng: BLK_MQ_REQ_RESERVED is replaced by NVME_SUBMIT_RESERVED in v6.8] Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- drivers/nvme/host/fabrics.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c index 7015fba2e512..2687454351bc 100644 --- a/drivers/nvme/host/fabrics.c +++ b/drivers/nvme/host/fabrics.c @@ -151,7 +151,7 @@ int nvmf_reg_read32(struct nvme_ctrl *ctrl, u32 off, u32 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -198,7 +198,7 @@ int nvmf_reg_read64(struct nvme_ctrl *ctrl, u32 off, u64 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -244,7 +244,7 @@ int nvmf_reg_write32(struct nvme_ctrl *ctrl, u32 off, u32 val) cmd.prop_set.value = cpu_to_le64(val); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, NULL, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (unlikely(ret)) dev_err(ctrl->device, "Property Set error: %d, offset %#x\n", -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] nvme-fabrics: use reserved tag for reg read/write command
by Wupeng Ma 02 Sep '24

02 Sep '24

From: Chunguang Xu <chunguang.xu(a)shopee.com> mainline inclusion from mainline-v6.10-rc3 commit 7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEKB CVE: CVE-2024-41082 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. For the enable ctrl / fw activate path, since connect and reg_xx() are called serially. So the reserved tags may still be enough while reg_xx() use reserved tags. Signed-off-by: Chunguang Xu <chunguang.xu(a)shopee.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/host/fabrics.c [Ma Wupeng: BLK_MQ_REQ_RESERVED is replaced by NVME_SUBMIT_RESERVED in v6.8] Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- drivers/nvme/host/fabrics.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c index 7015fba2e512..2687454351bc 100644 --- a/drivers/nvme/host/fabrics.c +++ b/drivers/nvme/host/fabrics.c @@ -151,7 +151,7 @@ int nvmf_reg_read32(struct nvme_ctrl *ctrl, u32 off, u32 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -198,7 +198,7 @@ int nvmf_reg_read64(struct nvme_ctrl *ctrl, u32 off, u64 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -244,7 +244,7 @@ int nvmf_reg_write32(struct nvme_ctrl *ctrl, u32 off, u32 val) cmd.prop_set.value = cpu_to_le64(val); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, NULL, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (unlikely(ret)) dev_err(ctrl->device, "Property Set error: %d, offset %#x\n", -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/radeon: check bo_va->bo is non-NULL before using it
by Wupeng Ma 02 Sep '24

02 Sep '24

From: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> stable inclusion from stable-v6.6.42 commit f13c96e0e325a057c03f8a47734adb360e112efe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEMD CVE: CVE-2024-41060 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6fb15dcbcf4f212930350eaee174bb60ed40a536 ] The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/gpu/drm/radeon/radeon_gem.c [Ma Wupeng: Context conflict] Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- drivers/gpu/drm/radeon/radeon_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index e5c4271e64ed..1c9c6e49cb22 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -584,7 +584,7 @@ static void radeon_gem_va_update_vm(struct radeon_device *rdev, if (r) goto error_unlock; - if (bo_va->it.start) + if (bo_va->it.start && bo_va->bo) r = radeon_vm_bo_update(rdev, bo_va, &bo_va->bo->tbo.mem); error_unlock: -- 2.25.1

2 1

[PATCH OLK-5.10] drm/radeon: check bo_va->bo is non-NULL before using it
by Wupeng Ma 02 Sep '24

02 Sep '24

From: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> stable inclusion from stable-v6.6.42 commit f13c96e0e325a057c03f8a47734adb360e112efe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEMD CVE: CVE-2024-41060 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6fb15dcbcf4f212930350eaee174bb60ed40a536 ] The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/gpu/drm/radeon/radeon_gem.c [Ma Wupeng: Context conflict] Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- drivers/gpu/drm/radeon/radeon_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index 75053917d213..51b6f38b5c47 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -582,7 +582,7 @@ static void radeon_gem_va_update_vm(struct radeon_device *rdev, if (r) goto error_unlock; - if (bo_va->it.start) + if (bo_va->it.start && bo_va->bo) r = radeon_vm_bo_update(rdev, bo_va, &bo_va->bo->tbo.mem); error_unlock: -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] efi: fix NULL-deref in init error path
by Gu Bowen 02 Sep '24

02 Sep '24

From: Johan Hovold <johan+linaro(a)kernel.org> stable inclusion from stable-v5.10.164 commit 4ca71bc0e1995d15486cd7b60845602a28399cb5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKPW7 CVE: CVE-2022-48879 Reference:https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/… -------------------------------- [ Upstream commit 703c13fe3c9af557d312f5895ed6a5fda2711104 ] In cases where runtime services are not supported or have been disabled, the runtime services workqueue will never have been allocated. Do not try to destroy the workqueue unconditionally in the unlikely event that EFI initialisation fails to avoid dereferencing a NULL pointer. Fixes: 98086df8b70c ("efi: add missed destroy_workqueue when efisubsys_init fails") Cc: stable(a)vger.kernel.org Cc: Li Heng <liheng40(a)huawei.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- drivers/firmware/efi/efi.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 97a0916d6502..534688df3655 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -386,8 +386,8 @@ static int __init efisubsys_init(void) efi_kobj = kobject_create_and_add("efi", firmware_kobj); if (!efi_kobj) { pr_err("efi: Firmware registration failed.\n"); - destroy_workqueue(efi_rts_wq); - return -ENOMEM; + error = -ENOMEM; + goto err_destroy_wq; } if (efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE | @@ -430,7 +430,10 @@ static int __init efisubsys_init(void) generic_ops_unregister(); err_put: kobject_put(efi_kobj); - destroy_workqueue(efi_rts_wq); +err_destroy_wq: + if (efi_rts_wq) + destroy_workqueue(efi_rts_wq); + return error; } -- 2.25.1

2 1

[PATCH OLK-5.10] ovl: remove upper umask handling from ovl_create_upper()
by Yifan Qiao 02 Sep '24

02 Sep '24

From: Miklos Szeredi <mszeredi(a)redhat.com> mainline inclusion from mainline-v6.10-rc1 commit 096802748ea1dea8b476938e0a8dc16f4bd2f1ad bugzilla: https://gitee.com/src-openeuler/kernel/issues/IANSAC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This is already done by vfs_prepare_mode() when creating the upper object by vfs_create(), vfs_mkdir() and vfs_mknod(). No regressions have been observed in xfstests run with posix acls turned off for the upper filesystem. Fixes: 1639a49ccdce ("fs: move S_ISGID stripping into the vfs_*() helpers") Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Conflicts: fs/overlayfs/dir,c [Just context differences] Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/overlayfs/dir.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c index b2eb48b495f7..492b9faff54f 100644 --- a/fs/overlayfs/dir.c +++ b/fs/overlayfs/dir.c @@ -323,9 +323,6 @@ static int ovl_create_upper(struct dentry *dentry, struct inode *inode, struct dentry *newdentry; int err; - if (!attr->hardlink && !IS_POSIXACL(udir)) - attr->mode &= ~current_umask(); - inode_lock_nested(udir, I_MUTEX_PARENT); newdentry = ovl_create_real(udir, lookup_one_len(dentry->d_name.name, -- 2.39.2

2 1

[PATCH OLK-5.10 0/2] Fix cifs kmemleak
by Zizhi Wo 02 Sep '24

02 Sep '24

This patchset mainly fixed the cifs_write_from_iter function, it execution failure caused pagevec kmemleak problem, the previous round of the mainline patch automatically adapted the error, adjusted the fixcode position. Zhang Xiaoxu (1): cifs: Fix pages leak when writedata alloc failed in cifs_write_from_iter() Zizhi Wo (1): Revert "[Backport] cifs: Fix pages leak when writedata alloc failed in cifs_write_from_iter()" -- 2.39.2

2 3

[PATCH OLK-6.6] iomap: fault in smaller chunks for non-large folio mappings
by Yifan Qiao 02 Sep '24

02 Sep '24

From: Xu Yang <xu.yang_2(a)nxp.com> mainline inclusion from mainline-v6.10-rc2 commit 4e527d5841e24623181edc7fd6f6598ffa810e10 bugzilla: https://gitee.com/src-openeuler/kernel/issues/IANSAC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Since commit (5d8edfb900d5 "iomap: Copy larger chunks from userspace"), iomap will try to copy in larger chunks than PAGE_SIZE. However, if the mapping doesn't support large folio, only one page of maximum 4KB will be created and 4KB data will be writen to pagecache each time. Then, next 4KB will be handled in next iteration. This will cause potential write performance problem. If chunk is 2MB, total 512 pages need to be handled finally. During this period, fault_in_iov_iter_readable() is called to check iov_iter readable validity. Since only 4KB will be handled each time, below address space will be checked over and over again: start end - buf, buf+2MB buf+4KB, buf+2MB buf+8KB, buf+2MB ... buf+2044KB buf+2MB Obviously the checking size is wrong since only 4KB will be handled each time. So this will get a correct chunk to let iomap work well in non-large folio case. With this change, the write speed will be stable. Tested on ARM64 device. Before: - dd if=/dev/zero of=/dev/sda bs=400K count=10485 (334 MB/s) - dd if=/dev/zero of=/dev/sda bs=800K count=5242 (278 MB/s) - dd if=/dev/zero of=/dev/sda bs=1600K count=2621 (204 MB/s) - dd if=/dev/zero of=/dev/sda bs=2200K count=1906 (170 MB/s) - dd if=/dev/zero of=/dev/sda bs=3000K count=1398 (150 MB/s) - dd if=/dev/zero of=/dev/sda bs=4500K count=932 (139 MB/s) After: - dd if=/dev/zero of=/dev/sda bs=400K count=10485 (339 MB/s) - dd if=/dev/zero of=/dev/sda bs=800K count=5242 (330 MB/s) - dd if=/dev/zero of=/dev/sda bs=1600K count=2621 (332 MB/s) - dd if=/dev/zero of=/dev/sda bs=2200K count=1906 (333 MB/s) - dd if=/dev/zero of=/dev/sda bs=3000K count=1398 (333 MB/s) - dd if=/dev/zero of=/dev/sda bs=4500K count=932 (333 MB/s) Fixes: 5d8edfb900d5 ("iomap: Copy larger chunks from userspace") Cc: stable(a)vger.kernel.org Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Xu Yang <xu.yang_2(a)nxp.com> Link: https://lore.kernel.org/r/20240521114939.2541461-2-xu.yang_2@nxp.com Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/iomap/buffered-io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index fe64886e4eae..526a197c5eb7 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -973,11 +973,11 @@ static bool iomap_write_end(struct iomap_iter *iter, loff_t pos, size_t len, static loff_t iomap_write_iter(struct iomap_iter *iter, struct iov_iter *i) { loff_t length = iomap_length(iter); - size_t chunk = PAGE_SIZE << MAX_PAGECACHE_ORDER; loff_t pos = iter->pos; ssize_t total_written = 0; long status = 0; struct address_space *mapping = iter->inode->i_mapping; + size_t chunk = mapping_max_folio_size(mapping); unsigned int bdp_flags = (iter->flags & IOMAP_NOWAIT) ? BDP_ASYNC : 0; do { -- 2.39.2

2 1

2024

2023

2022

2021

2020

2019

Kernel September 2024