Re: [PATCH v9 0/4] VFS: In-kernel copy system call

On Tue, Nov 10, 2015 at 04:53:30PM -0500, Anna Schumaker wrote:

out:
	fdput(f_in);
out1:
	fdput(f_out);

The fdput()s are in the wrong order.  fdget(f_in) is first at the beginning, so
fdput(f_in) needs to be last at the end.

      /* this could be relaxed once a method supports cross-fs copies */
      if (inode_in->i_sb != inode_out->i_sb)
              return -EXDEV;

This allows the same superblock but different mounts --- is that intentional?
The commit message says otherwise: it says the vfs entry point requires the same
superblock and mount.


Was there a decision made on FMODE_PREAD and FMODE_PWRITE?  To me it seems
logical that the if the user explicitly specifies an offset, then the
corresponding mode should be checked.  That would check whether the file is
seekable or not, I believe.  Note that e.g. sys_sendfile() does the same thing.

On 2015-11-11 09:53, Eric Biggers wrote:

On Tue, Nov 10, 2015 at 04:53:30PM -0500, Anna Schumaker wrote:

quoted

       /* this could be relaxed once a method supports cross-fs copies */
       if (inode_in->i_sb != inode_out->i_sb)
               return -EXDEV;

This allows the same superblock but different mounts --- is that intentional?
The commit message says otherwise: it says the vfs entry point requires the same
superblock and mount.

This could be important for BTRFS (because of subvolumes, you can have multiple mounts that have the same SB, and as of right now, it can be hard to tell the difference between a nested subvolume and a separate mount point).  We do support cross-subvolume reflinks, but I'm not sure if that works between subvolumes mounted at different places (if it doesn't, I may have to look into getting that changed).