Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1505960

Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up

Show all headers | View raw

On Fri, Oct 21, 2016 at 11:12:11AM +0200, Miklos Szeredi wrote:
> On Thu, Oct 20, 2016 at 04:54:08PM -0400, Vivek Goyal wrote:
> > On Thu, Oct 20, 2016 at 04:46:30PM -0400, Vivek Goyal wrote:
> > 
> > [..]
> > > > +static ssize_t ovl_read_iter(struct kiocb *iocb, struct iov_iter *to)
> > > > +{
> > > > +	struct file *file = iocb->ki_filp;
> > > > +	bool isupper = OVL_TYPE_UPPER(ovl_path_type(file->f_path.dentry));
> > > > +	ssize_t ret = -EINVAL;
> > > > +
> > > > +	if (likely(!isupper)) {
> > > > +		const struct file_operations *fop = ovl_real_fop(file);
> > > > +
> > > > +		if (likely(fop->read_iter))
> > > > +			ret = fop->read_iter(iocb, to);
> > > > +	} else {
> > > > +		struct file *upperfile = filp_clone_open(file);
> > > > +
> > > 
> > > IIUC, every read of lower file will call filp_clone_open(). Looking at the
> > > code of filp_clone_open(), I am concerned about the overhead of this call.
> > > Is it significant? Don't want to be paying too much of penalty for read
> > > operation on lower files. That would be a common case for containers.
> > > 
> > 
> > Looks like I read the code in reverse. So if I open a file read-only,
> > and if it has not been copied up, I will simply call read_iter() on
> > lower filesystem. But if file has been copied up, then I will call
> > filp_clone_open() and pay the cost. And this will continue till this
> > file is closed by caller. 
> > 
> > When file is opened again, by that time it is upper file and we will
> > install real fop in file (instead of overlay fop).
> 
> Right.
> 
> The lockdep issue seems to be real, we can't take i_mutex and s_vfs_rename_mutex
> while mmap_sem is locked.  Fortunately copy up doesn't need mmap_sem, so we can
> do it while unlocked and retry the mmap.
> 
> Here's an incremental workaround patch.
> 
> I don't like adding such workarounds to the VFS/MM but they are really cheap for
> the non-overlay case and there doesn't appear to be an alternative in this case.

This incremental patch does fix the locking warning issue I was seeing.

Vivek

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-20 22:50 +0200
  Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-20 23:00 +0200
    Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-21 11:00 +0200
      Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-21 22:20 +0200
        Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-22 09:30 +0200
          Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-22 17:40 +0200
            Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Miklos Szeredi <miklos@szeredi.hu> - 2016-10-24 10:20 +0200
    Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Miklos Szeredi <miklos@szeredi.hu> - 2016-10-21 11:20 +0200
      Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-21 15:40 +0200
  Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-21 11:20 +0200
    Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Miklos Szeredi <miklos@szeredi.hu> - 2016-10-21 11:40 +0200
      Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-21 15:20 +0200

csiph-web