On Wednesday 02 of May 2012 18:33:37 David Sterba wrote: > On Tue, May 01, 2012 at 07:09:21PM +0200, Hubert Kario wrote: > > Let me rephrase it: > > > > People don't want to be able to do: > > > > mount /dev/lvm/btrfs /mnt/a -t btrfs -o subvol=volA > > mount /dev/lvm/btrfs /mnt/b -t btrfs -o subvol=volB > > cp --reflink=always /mnt/a/file /mnt/b > > > > Just like you can't do hardlinks over `mount --bind` mountpoints, you > > shouldn't be able to cp reflink over mountpoints. That's expected as this > > *does* break VFS semantics. > > Proposed fix (incremental on top of the cross-subvol): I'm a noob as far as kernel development is concerned so take my comments for what they're worth. > --- a/fs/btrfs/ioctl.c > +++ b/fs/btrfs/ioctl.c > @@ -2321,6 +2321,10 @@ static noinline long btrfs_ioctl_clone(struct file > *file, unsigned long srcfd, goto out_drop_write; > } > > + ret = -EXDEV; > + if (src_file->f_path.mnt != file->f_path.mnt) I'm not sure about this comparision. Is the f_path struct member used just as reference to some general kernel structure? > + goto out_fput; > + > src = src_file->f_dentry->d_inode; > > ret = -EINVAL; Other that that, looks OK. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
