On Fri, Mar 27, 2020 at 10:01:14AM -0400, Vivek Goyal wrote:
> On Thu, Mar 26, 2020 at 08:09:05AM +0800, Liu Bo wrote:
>
> [..]
> > > +/*
> > > + * Find first mapping in the tree and free it and return it. Do not add
> > > + * it back to free pool. If fault == true, this function should be called
> > > + * with fi->i_mmap_sem held.
> > > + */
> > > +static struct fuse_dax_mapping *inode_reclaim_one_dmap(struct fuse_conn *fc,
> > > + struct inode *inode,
> > > + bool fault)
> > > +{
> > > + struct fuse_inode *fi = get_fuse_inode(inode);
> > > + struct fuse_dax_mapping *dmap;
> > > + int ret;
> > > +
> > > + if (!fault)
> > > + down_write(&fi->i_mmap_sem);
> > > +
> > > + /*
> > > + * Make sure there are no references to inode pages using
> > > + * get_user_pages()
> > > + */
> > > + ret = fuse_break_dax_layouts(inode, 0, 0);
> >
> > Hi Vivek,
> >
> > This patch is enabling inline reclaim for fault path, but fault path
> > has already holds a locked exceptional entry which I believe the above
> > fuse_break_dax_layouts() needs to wait for, can you please elaborate
> > on how this can be avoided?
> >
>
> Hi Liubo,
>
> Can you please point to the exact lock you are referring to. I will
> check it out. Once we got rid of needing to take inode lock in
> reclaim path, that opended the door to do inline reclaim in fault
> path as well. But I was not aware of this exceptional entry lock.
Hi Vivek,
dax_iomap_{pte,pmd}_fault has called grab_mapping_entry to get a
locked entry, when this fault gets into inline reclaim, would
fuse_break_dax_layouts wait for the locked exceptional entry which is
locked in dax_iomap_{pte,pmd}_fault?
thanks,
liubo
