From: Sasha Levin Date: Tue, 18 Aug 2020 00:55:17 +0000 (-0400) Subject: Drop iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch X-Git-Tag: v4.19.140~3 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0c9418ef07bce95fa0e70a229e6b6ee33feefb86;p=thirdparty%2Fkernel%2Fstable-queue.git Drop iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch Signed-off-by: Sasha Levin --- diff --git a/queue-5.4/iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch b/queue-5.4/iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch deleted file mode 100644 index f7f8b9cbcb4..00000000000 --- a/queue-5.4/iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch +++ /dev/null @@ -1,64 +0,0 @@ -From 64646dec0521e045f129009e2fd8dfb212be4282 Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Mon, 6 Jul 2020 10:49:27 -0700 -Subject: iomap: Make sure iomap_end is called after iomap_begin - -From: Andreas Gruenbacher - -[ Upstream commit 856473cd5d17dbbf3055710857c67a4af6d9fcc0 ] - -Make sure iomap_end is always called when iomap_begin succeeds. - -Without this fix, iomap_end won't be called when a filesystem's -iomap_begin operation returns an invalid mapping, bypassing any -unlocking done in iomap_end. With this fix, the unlocking will still -happen. - -This bug was found by Bob Peterson during code review. It's unlikely -that such iomap_begin bugs will survive to affect users, so backporting -this fix seems unnecessary. - -Fixes: ae259a9c8593 ("fs: introduce iomap infrastructure") -Signed-off-by: Andreas Gruenbacher -Reviewed-by: Christoph Hellwig -Reviewed-by: Darrick J. Wong -Signed-off-by: Darrick J. Wong -Signed-off-by: Sasha Levin ---- - fs/iomap/apply.c | 13 +++++++++---- - 1 file changed, 9 insertions(+), 4 deletions(-) - -diff --git a/fs/iomap/apply.c b/fs/iomap/apply.c -index 54c02aecf3cd8..c2281a6a7f320 100644 ---- a/fs/iomap/apply.c -+++ b/fs/iomap/apply.c -@@ -41,10 +41,14 @@ iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags, - ret = ops->iomap_begin(inode, pos, length, flags, &iomap); - if (ret) - return ret; -- if (WARN_ON(iomap.offset > pos)) -- return -EIO; -- if (WARN_ON(iomap.length == 0)) -- return -EIO; -+ if (WARN_ON(iomap.offset > pos)) { -+ written = -EIO; -+ goto out; -+ } -+ if (WARN_ON(iomap.length == 0)) { -+ written = -EIO; -+ goto out; -+ } - - /* - * Cut down the length to the one actually provided by the filesystem, -@@ -60,6 +64,7 @@ iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags, - */ - written = actor(inode, pos, length, data, &iomap); - -+out: - /* - * Now the data has been copied, commit the range we've copied. This - * should not fail unless the filesystem has had a fatal error. --- -2.25.1 - diff --git a/queue-5.4/series b/queue-5.4/series index 0904d0a3826..f9be22f11b7 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -126,7 +126,6 @@ media-exynos4-is-add-missed-check-for-pinctrl_lookup.patch media-cros-ec-cec-do-not-bail-on-device_init_wakeup-.patch xfs-don-t-eat-an-eio-enospc-writeback-error-when-scr.patch xfs-fix-reflink-quota-reservation-accounting-error.patch -iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch rdma-rxe-skip-dgid-check-in-loopback-mode.patch pci-fix-pci_cfg_wait-queue-locking-problem.patch drm-stm-repair-runtime-power-management.patch diff --git a/queue-5.7/iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch b/queue-5.7/iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch deleted file mode 100644 index 05262a9279c..00000000000 --- a/queue-5.7/iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch +++ /dev/null @@ -1,64 +0,0 @@ -From 84eb0b9fd116a7e6d8f82e4542158eea600931a0 Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Mon, 6 Jul 2020 10:49:27 -0700 -Subject: iomap: Make sure iomap_end is called after iomap_begin - -From: Andreas Gruenbacher - -[ Upstream commit 856473cd5d17dbbf3055710857c67a4af6d9fcc0 ] - -Make sure iomap_end is always called when iomap_begin succeeds. - -Without this fix, iomap_end won't be called when a filesystem's -iomap_begin operation returns an invalid mapping, bypassing any -unlocking done in iomap_end. With this fix, the unlocking will still -happen. - -This bug was found by Bob Peterson during code review. It's unlikely -that such iomap_begin bugs will survive to affect users, so backporting -this fix seems unnecessary. - -Fixes: ae259a9c8593 ("fs: introduce iomap infrastructure") -Signed-off-by: Andreas Gruenbacher -Reviewed-by: Christoph Hellwig -Reviewed-by: Darrick J. Wong -Signed-off-by: Darrick J. Wong -Signed-off-by: Sasha Levin ---- - fs/iomap/apply.c | 13 +++++++++---- - 1 file changed, 9 insertions(+), 4 deletions(-) - -diff --git a/fs/iomap/apply.c b/fs/iomap/apply.c -index 76925b40b5fd2..26ab6563181fc 100644 ---- a/fs/iomap/apply.c -+++ b/fs/iomap/apply.c -@@ -46,10 +46,14 @@ iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags, - ret = ops->iomap_begin(inode, pos, length, flags, &iomap, &srcmap); - if (ret) - return ret; -- if (WARN_ON(iomap.offset > pos)) -- return -EIO; -- if (WARN_ON(iomap.length == 0)) -- return -EIO; -+ if (WARN_ON(iomap.offset > pos)) { -+ written = -EIO; -+ goto out; -+ } -+ if (WARN_ON(iomap.length == 0)) { -+ written = -EIO; -+ goto out; -+ } - - trace_iomap_apply_dstmap(inode, &iomap); - if (srcmap.type != IOMAP_HOLE) -@@ -80,6 +84,7 @@ iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags, - written = actor(inode, pos, length, data, &iomap, - srcmap.type != IOMAP_HOLE ? &srcmap : &iomap); - -+out: - /* - * Now the data has been copied, commit the range we've copied. This - * should not fail unless the filesystem has had a fatal error. --- -2.25.1 - diff --git a/queue-5.7/series b/queue-5.7/series index 9c0b6f1c8d3..95d03c56d30 100644 --- a/queue-5.7/series +++ b/queue-5.7/series @@ -185,7 +185,6 @@ media-exynos4-is-add-missed-check-for-pinctrl_lookup.patch media-cros-ec-cec-do-not-bail-on-device_init_wakeup-.patch xfs-don-t-eat-an-eio-enospc-writeback-error-when-scr.patch xfs-fix-reflink-quota-reservation-accounting-error.patch -iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch rdma-rxe-skip-dgid-check-in-loopback-mode.patch pci-fix-pci_cfg_wait-queue-locking-problem.patch samples-bpf-fix-bpf-programs-with-kprobe-sys_connect.patch diff --git a/queue-5.8/iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch b/queue-5.8/iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch deleted file mode 100644 index 8e6b109ba3e..00000000000 --- a/queue-5.8/iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch +++ /dev/null @@ -1,64 +0,0 @@ -From 84d980663ad10457f4859ae6ebf8628a7f3fb12a Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Mon, 6 Jul 2020 10:49:27 -0700 -Subject: iomap: Make sure iomap_end is called after iomap_begin - -From: Andreas Gruenbacher - -[ Upstream commit 856473cd5d17dbbf3055710857c67a4af6d9fcc0 ] - -Make sure iomap_end is always called when iomap_begin succeeds. - -Without this fix, iomap_end won't be called when a filesystem's -iomap_begin operation returns an invalid mapping, bypassing any -unlocking done in iomap_end. With this fix, the unlocking will still -happen. - -This bug was found by Bob Peterson during code review. It's unlikely -that such iomap_begin bugs will survive to affect users, so backporting -this fix seems unnecessary. - -Fixes: ae259a9c8593 ("fs: introduce iomap infrastructure") -Signed-off-by: Andreas Gruenbacher -Reviewed-by: Christoph Hellwig -Reviewed-by: Darrick J. Wong -Signed-off-by: Darrick J. Wong -Signed-off-by: Sasha Levin ---- - fs/iomap/apply.c | 13 +++++++++---- - 1 file changed, 9 insertions(+), 4 deletions(-) - -diff --git a/fs/iomap/apply.c b/fs/iomap/apply.c -index 76925b40b5fd2..26ab6563181fc 100644 ---- a/fs/iomap/apply.c -+++ b/fs/iomap/apply.c -@@ -46,10 +46,14 @@ iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags, - ret = ops->iomap_begin(inode, pos, length, flags, &iomap, &srcmap); - if (ret) - return ret; -- if (WARN_ON(iomap.offset > pos)) -- return -EIO; -- if (WARN_ON(iomap.length == 0)) -- return -EIO; -+ if (WARN_ON(iomap.offset > pos)) { -+ written = -EIO; -+ goto out; -+ } -+ if (WARN_ON(iomap.length == 0)) { -+ written = -EIO; -+ goto out; -+ } - - trace_iomap_apply_dstmap(inode, &iomap); - if (srcmap.type != IOMAP_HOLE) -@@ -80,6 +84,7 @@ iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned flags, - written = actor(inode, pos, length, data, &iomap, - srcmap.type != IOMAP_HOLE ? &srcmap : &iomap); - -+out: - /* - * Now the data has been copied, commit the range we've copied. This - * should not fail unless the filesystem has had a fatal error. --- -2.25.1 - diff --git a/queue-5.8/series b/queue-5.8/series index 844fa4fe976..c9acf7e47e4 100644 --- a/queue-5.8/series +++ b/queue-5.8/series @@ -211,7 +211,6 @@ media-cros-ec-cec-do-not-bail-on-device_init_wakeup-.patch xfs-preserve-rmapbt-swapext-block-reservation-from-f.patch xfs-don-t-eat-an-eio-enospc-writeback-error-when-scr.patch xfs-fix-reflink-quota-reservation-accounting-error.patch -iomap-make-sure-iomap_end-is-called-after-iomap_begi.patch rdma-rxe-skip-dgid-check-in-loopback-mode.patch pci-fix-pci_cfg_wait-queue-locking-problem.patch samples-bpf-fix-bpf-programs-with-kprobe-sys_connect.patch