On Tue, Jan 22, 2019 at 07:49:42PM +0200, Amir Goldstein wrote:
> On Tue, Jan 22, 2019 at 6:28 PM Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
> >
> > On Tue, Jan 22, 2019 at 07:01:39AM +0200, Amir Goldstein wrote:
> > > Generalize the helper ovl_open_maybe_copy_up() and use it to copy up
> > > file with data before FS_IOC_SETFLAGS ioctl.
> > >
> > > Fixes: dab5ca8fd9dd ("ovl: add lsattr/chattr support")
> > > Cc: <stable@xxxxxxxxxxxxxxx> # v4.19
> > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
> >
> > What upper fs freeze protection you are referring to. I am unable to
> > see it in this new path.
> >
>
> Changed from calling ovl_copy_up_with_data() to calling
> ovl_maybe_copy_up().
> The former doesn't have ovl_want_write()/ovl_drop_write().
>
> The FS_IOC_SETFLAGS ioctl is a bit of an odd ball in vfs,
> which probably caused the confusion.
> File may be open O_RDONLY, but ioctl modifies the file.
> VFS does not call mnt_want_write_file() nor lock inode mutex,
> but fs-specific code for FS_IOC_SETFLAGS does.
> So ovl_ioctl() calls mnt_want_write_file() for the overlay file,
> and fs-specific code calls mnt_want_write_file() for upper fs
> file, but there was no call for ovl_want_write() for copy up
> duration which prevents overlayfs from copying up on a
> frozen upper fs.
Ok, thanks for the explanaiton. I understand it better now.
Acked-by: Vivek Goyal <vgoyal@xxxxxxxxxx>
Vivek
