On Thu, Jun 18, 2020 at 3:39 AM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote:
> On Mon, Jun 15, 2020 at 06:02:44PM +0200, Andreas Gruenbacher wrote:
> > Make sure iomap_end is always called when iomap_begin succeeds: the
> > filesystem may take locks in iomap_begin and release them in iomap_end,
> > for example.
> >
> > Signed-off-by: Andreas Gruenbacher <agruenba@xxxxxxxxxx>
> > ---
> > fs/iomap/apply.c | 9 +++++----
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/iomap/apply.c b/fs/iomap/apply.c
> > index 76925b40b5fd..c00a14d825db 100644
> > --- a/fs/iomap/apply.c
> > +++ b/fs/iomap/apply.c
> > @@ -46,10 +46,10 @@ 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) || WARN_ON(iomap.length == 0)) {
>
> <urk> Forgot to actually review the original patch. :P
>
> Why combine these WARN_ON? Before, you could distinguish between your
> iomap_begin method returning zero length vs. bad offset.
Right, the WARN_ONs shouldn't both report the same line number. I'll
send an update.
Thanks,
Andreas
