[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20190520125355.GA28008@redhat.com>
Date: Mon, 20 May 2019 08:53:55 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Eric Ren <ericdotren@...il.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, linux-nvdimm@...ts.01.org, miklos@...redi.hu,
stefanha@...hat.com, dgilbert@...hat.com, swhiteho@...hat.com
Subject: Re: [PATCH v2 26/30] fuse: Add logic to free up a memory range
On Sun, May 19, 2019 at 03:48:05PM +0800, Eric Ren wrote:
> Hi,
>
> @@ -1784,8 +1822,23 @@ static int fuse_iomap_begin(struct inode *inode,
> > loff_t pos, loff_t length,
> > if (pos >= i_size_read(inode))
> > goto iomap_hole;
> >
> > - alloc_dmap = alloc_dax_mapping(fc);
> > - if (!alloc_dmap)
> > + /* Can't do reclaim in fault path yet due to lock ordering.
> > + * Read path takes shared inode lock and that's not
> > sufficient
> > + * for inline range reclaim. Caller needs to drop lock,
> > wait
> > + * and retry.
> > + */
> > + if (flags & IOMAP_FAULT || !(flags & IOMAP_WRITE)) {
> > + alloc_dmap = alloc_dax_mapping(fc);
> > + if (!alloc_dmap)
> > + return -ENOSPC;
> > + } else {
> > + alloc_dmap = alloc_dax_mapping_reclaim(fc, inode);
> >
>
> alloc_dmap could be NULL as follows:
>
> alloc_dax_mapping_reclaim
> -->fuse_dax_reclaim_first_mapping
> -->fuse_dax_reclaim_first_mapping_locked
> --> fuse_dax_interval_tree_iter_first ==> return NULL
> and
>
> IS_ERR(NULL) is false, so we may miss that error case.
Hi Eric,
Good catch. I will fix it next version.
Thanks
Vivek
Powered by blists - more mailing lists