| Message ID | 20200629095118.1366261-1-agruenba@redhat.com (mailing list archive) |
|---|---|
| State | Deferred, archived |
| Headers | show |
| Series | [v3] iomap: Make sure iomap_end is called after iomap_begin | expand |
On Mon, Jun 29, 2020 at 11:51:18AM +0200, Andreas Gruenbacher wrote: > 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 <agruenba@redhat.com> Looks good: Reviewed-by: Christoph Hellwig <hch@lst.de>
On Mon, Jun 29, 2020 at 11:51:18AM +0200, Andreas Gruenbacher wrote: > 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 <agruenba@redhat.com> Looks ok, Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> --D > --- > 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 76925b40b5fd..26ab6563181f 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. > > base-commit: 69119673bd50b176ded34032fadd41530fb5af21 > -- > 2.26.2 >
diff --git a/fs/iomap/apply.c b/fs/iomap/apply.c index 76925b40b5fd..26ab6563181f 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.
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 <agruenba@redhat.com> --- fs/iomap/apply.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) base-commit: 69119673bd50b176ded34032fadd41530fb5af21