From: Luis Henriques <lhenriques@suse.de>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Jeff Layton <jlayton@kernel.org>,
Nicolas Boichat <drinkcat@chromium.org>,
"Darrick J . Wong" <djwong@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Ian Lance Taylor <iant@google.com>,
Luis Lozano <llozano@chromium.org>,
Dave Chinner <david@fromorbit.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Trond Myklebust <trond.myklebust@hammerspace.com>,
Anna Schumaker <Anna.Schumaker@netapp.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Steve French <sfrench@samba.org>
Subject: Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
Date: Mon, 15 Feb 2021 14:51:26 +0000 [thread overview]
Message-ID: <878s7pl6z5.fsf@suse.de> (raw)
In-Reply-To: <CAOQ4uxiFGjdvX2-zh5o46pn7RZhvbGHH0wpzLPuPOom91FwWeQ@mail.gmail.com> (Amir Goldstein's message of "Mon, 15 Feb 2021 16:23:03 +0200")
Amir Goldstein <amir73il@gmail.com> writes:
> On Mon, Feb 15, 2021 at 2:21 PM Luis Henriques <lhenriques@suse.de> wrote:
>>
>> Luis Henriques <lhenriques@suse.de> writes:
>>
>> > Amir Goldstein <amir73il@gmail.com> writes:
>> >
>> >> On Fri, Feb 12, 2021 at 2:40 PM Luis Henriques <lhenriques@suse.de> wrote:
>> > ...
>> >>> Sure, I just wanted to point out that *maybe* there are other options than
>> >>> simply reverting that commit :-)
>> >>>
>> >>> Something like the patch below (completely untested!) should revert to the
>> >>> old behaviour in filesystems that don't implement the CFR syscall.
>> >>>
>> >>> Cheers,
>> >>> --
>> >>> Luis
>> >>>
>> >>> diff --git a/fs/read_write.c b/fs/read_write.c
>> >>> index 75f764b43418..bf5dccc43cc9 100644
>> >>> --- a/fs/read_write.c
>> >>> +++ b/fs/read_write.c
>> >>> @@ -1406,8 +1406,11 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>> >>> file_out, pos_out,
>> >>> len, flags);
>> >>>
>> >>> - return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> >>> - flags);
>> >>> + if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>> >>> + return -EXDEV;
>> >>> + else
>> >>> + generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> >>> + flags);
>> >>> }
>> >>>
>> >>
>> >> Which kernel is this patch based on?
>> >
>> > It was v5.11-rc7.
>> >
>> >> At this point, I am with Dave and Darrick on not falling back to
>> >> generic_copy_file_range() at all.
>> >>
>> >> We do not have proof of any workload that benefits from it and the
>> >> above patch does not protect from a wierd use case of trying to copy a file
>> >> from sysfs to sysfs.
>> >>
>> >
>> > Ok, cool. I can post a new patch doing just that. I guess that function
>> > do_copy_file_range() can be dropped in that case.
>> >
>> >> I am indecisive about what should be done with generic_copy_file_range()
>> >> called as fallback from within filesystems.
>> >>
>> >> I think the wise choice is to not do the fallback in any case, but this is up
>> >> to the specific filesystem maintainers to decide.
>> >
>> > I see what you mean. You're suggesting to have userspace handle all the
>> > -EOPNOTSUPP and -EXDEV errors. Would you rather have a patch that also
>> > removes all the calls to generic_copy_file_range() function? And that
>> > function can also be deleted too, of course.
>>
>> Here's a first stab at this patch. Hopefully I didn't forgot anything
>> here. Let me know if you prefer the more conservative approach, i.e. not
>> touching any of the filesystems and let them use generic_copy_file_range.
>>
>
> I'm fine with this one (modulu my comment below).
> CC'ing fuse/cifs/nfs maintainers.
> Though I don't think the FS maintainers should mind removing the fallback.
> It was added by "us" (64bf5ff58dff "vfs: no fallback for ->copy_file_range()")
Thanks for your review, Amir. I'll be posting v2 shortly.
Cheers,
--
Luis
>> Once everyone agrees on the final solution, I can follow-up with the
>> manpages update.
>>
>> Cheers,
>> --
>> Luis
>>
>> From e1b37e80b12601d56f792bd19377d3e5208188ef Mon Sep 17 00:00:00 2001
>> From: Luis Henriques <lhenriques@suse.de>
>> Date: Fri, 12 Feb 2021 18:03:23 +0000
>> Subject: [PATCH] vfs: prevent copy_file_range to copy across devices
>>
>> Nicolas Boichat reported an issue when trying to use the copy_file_range
>> syscall on a tracefs file. It failed silently because the file content is
>> generated on-the-fly (reporting a size of zero) and copy_file_range needs
>> to know in advance how much data is present.
>>
>> This commit effectively reverts 5dae222a5ff0 ("vfs: allow copy_file_range to
>> copy across devices"). Now the copy is done only if the filesystems for source
>> and destination files are the same and they implement this syscall.
>
> This paragraph is not true and confusing.
> This is not a revert and it does not revert the important part of cross-fs copy
> for which the original commit was for.
> Either rephrase this paragraph or remove it.
>
>>
>> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
>
> Please add a Link: to this discussion in lore.
>
>> Cc: Nicolas Boichat <drinkcat@chromium.org>
>> Signed-off-by: Luis Henriques <lhenriques@suse.de>
>> ---
>> fs/ceph/file.c | 21 +++------------
>> fs/cifs/cifsfs.c | 3 ---
>> fs/fuse/file.c | 21 +++------------
>> fs/nfs/nfs4file.c | 20 +++-----------
>> fs/read_write.c | 65 ++++++++--------------------------------------
>> include/linux/fs.h | 3 ---
>> 6 files changed, 20 insertions(+), 113 deletions(-)
>>
>> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
>> index 209535d5b8d3..639bd7bfaea9 100644
>> --- a/fs/ceph/file.c
>> +++ b/fs/ceph/file.c
>> @@ -2261,9 +2261,9 @@ static ssize_t ceph_do_objects_copy(struct ceph_inode_info *src_ci, u64 *src_off
>> return bytes;
>> }
>>
>> -static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
>> - struct file *dst_file, loff_t dst_off,
>> - size_t len, unsigned int flags)
>> +static ssize_t ceph_copy_file_range(struct file *src_file, loff_t src_off,
>> + struct file *dst_file, loff_t dst_off,
>> + size_t len, unsigned int flags)
>> {
>> struct inode *src_inode = file_inode(src_file);
>> struct inode *dst_inode = file_inode(dst_file);
>> @@ -2456,21 +2456,6 @@ static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
>> return ret;
>> }
>>
>> -static ssize_t ceph_copy_file_range(struct file *src_file, loff_t src_off,
>> - struct file *dst_file, loff_t dst_off,
>> - size_t len, unsigned int flags)
>> -{
>> - ssize_t ret;
>> -
>> - ret = __ceph_copy_file_range(src_file, src_off, dst_file, dst_off,
>> - len, flags);
>> -
>> - if (ret == -EOPNOTSUPP || ret == -EXDEV)
>> - ret = generic_copy_file_range(src_file, src_off, dst_file,
>> - dst_off, len, flags);
>> - return ret;
>> -}
>> -
>> const struct file_operations ceph_file_fops = {
>> .open = ceph_open,
>> .release = ceph_release,
>> diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
>> index e46da536ed33..8b869cc67443 100644
>> --- a/fs/cifs/cifsfs.c
>> +++ b/fs/cifs/cifsfs.c
>> @@ -1229,9 +1229,6 @@ static ssize_t cifs_copy_file_range(struct file *src_file, loff_t off,
>> len, flags);
>> free_xid(xid);
>>
>> - if (rc == -EOPNOTSUPP || rc == -EXDEV)
>> - rc = generic_copy_file_range(src_file, off, dst_file,
>> - destoff, len, flags);
>> return rc;
>> }
>>
>> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
>> index 8cccecb55fb8..0dd703278e49 100644
>> --- a/fs/fuse/file.c
>> +++ b/fs/fuse/file.c
>> @@ -3330,9 +3330,9 @@ static long fuse_file_fallocate(struct file *file, int mode, loff_t offset,
>> return err;
>> }
>>
>> -static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos_in,
>> - struct file *file_out, loff_t pos_out,
>> - size_t len, unsigned int flags)
>> +static ssize_t fuse_copy_file_range(struct file *file_in, loff_t pos_in,
>> + struct file *file_out, loff_t pos_out,
>> + size_t len, unsigned int flags)
>> {
>> struct fuse_file *ff_in = file_in->private_data;
>> struct fuse_file *ff_out = file_out->private_data;
>> @@ -3439,21 +3439,6 @@ static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos_in,
>> return err;
>> }
>>
>> -static ssize_t fuse_copy_file_range(struct file *src_file, loff_t src_off,
>> - struct file *dst_file, loff_t dst_off,
>> - size_t len, unsigned int flags)
>> -{
>> - ssize_t ret;
>> -
>> - ret = __fuse_copy_file_range(src_file, src_off, dst_file, dst_off,
>> - len, flags);
>> -
>> - if (ret == -EOPNOTSUPP || ret == -EXDEV)
>> - ret = generic_copy_file_range(src_file, src_off, dst_file,
>> - dst_off, len, flags);
>> - return ret;
>> -}
>> -
>> static const struct file_operations fuse_file_operations = {
>> .llseek = fuse_file_llseek,
>> .read_iter = fuse_file_read_iter,
>> diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c
>> index 57b3821d975a..60998209e310 100644
>> --- a/fs/nfs/nfs4file.c
>> +++ b/fs/nfs/nfs4file.c
>> @@ -133,9 +133,9 @@ nfs4_file_flush(struct file *file, fl_owner_t id)
>> }
>>
>> #ifdef CONFIG_NFS_V4_2
>> -static ssize_t __nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
>> - struct file *file_out, loff_t pos_out,
>> - size_t count, unsigned int flags)
>> +static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
>> + struct file *file_out, loff_t pos_out,
>> + size_t count, unsigned int flags)
>> {
>> struct nfs42_copy_notify_res *cn_resp = NULL;
>> struct nl4_server *nss = NULL;
>> @@ -189,20 +189,6 @@ static ssize_t __nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
>> return ret;
>> }
>>
>> -static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
>> - struct file *file_out, loff_t pos_out,
>> - size_t count, unsigned int flags)
>> -{
>> - ssize_t ret;
>> -
>> - ret = __nfs4_copy_file_range(file_in, pos_in, file_out, pos_out, count,
>> - flags);
>> - if (ret == -EOPNOTSUPP || ret == -EXDEV)
>> - ret = generic_copy_file_range(file_in, pos_in, file_out,
>> - pos_out, count, flags);
>> - return ret;
>> -}
>> -
>> static loff_t nfs4_file_llseek(struct file *filep, loff_t offset, int whence)
>> {
>> loff_t ret;
>> diff --git a/fs/read_write.c b/fs/read_write.c
>> index 75f764b43418..87bf9efd7f71 100644
>> --- a/fs/read_write.c
>> +++ b/fs/read_write.c
>> @@ -1358,58 +1358,6 @@ COMPAT_SYSCALL_DEFINE4(sendfile64, int, out_fd, int, in_fd,
>> }
>> #endif
>>
>> -/**
>> - * generic_copy_file_range - copy data between two files
>> - * @file_in: file structure to read from
>> - * @pos_in: file offset to read from
>> - * @file_out: file structure to write data to
>> - * @pos_out: file offset to write data to
>> - * @len: amount of data to copy
>> - * @flags: copy flags
>> - *
>> - * This is a generic filesystem helper to copy data from one file to another.
>> - * It has no constraints on the source or destination file owners - the files
>> - * can belong to different superblocks and different filesystem types. Short
>> - * copies are allowed.
>> - *
>> - * This should be called from the @file_out filesystem, as per the
>> - * ->copy_file_range() method.
>> - *
>> - * Returns the number of bytes copied or a negative error indicating the
>> - * failure.
>> - */
>> -
>> -ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
>> - struct file *file_out, loff_t pos_out,
>> - size_t len, unsigned int flags)
>> -{
>> - return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
>> - len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
>> -}
>> -EXPORT_SYMBOL(generic_copy_file_range);
>> -
>> -static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>> - struct file *file_out, loff_t pos_out,
>> - size_t len, unsigned int flags)
>> -{
>> - /*
>> - * Although we now allow filesystems to handle cross sb copy, passing
>> - * a file of the wrong filesystem type to filesystem driver can result
>> - * in an attempt to dereference the wrong type of ->private_data, so
>> - * avoid doing that until we really have a good reason. NFS defines
>> - * several different file_system_type structures, but they all end up
>> - * using the same ->copy_file_range() function pointer.
>> - */
>> - if (file_out->f_op->copy_file_range &&
>> - file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
>> - return file_out->f_op->copy_file_range(file_in, pos_in,
>> - file_out, pos_out,
>> - len, flags);
>> -
>> - return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> - flags);
>
> Please do not remove the big comment above - it is there for a reason.
>
> The case of !file_out->f_op->copy_file_range should return -EOPNOTSUPP
> because the outcome of -EXDEV for copy to/from the same fs is confusing.
>
> Either leave this helper and only remove generic_copy_file_range() or
> open code the same logic (including comment) in the caller.
>
>> -}
>> -
>> /*
>> * Performs necessary checks before doing a file copy
>> *
>> @@ -1474,6 +1422,14 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>> {
>> ssize_t ret;
>>
>> + /*
>> + * Allow the copy only if the filesystems for file_in and file_out are
>> + * the same, and copy_file_range is implemented.
>> + */
>
> This comment is wrong. See the big fat comment above to understand why.
> Also this check is in the wrong place because it misses the case of
> file_in->f_op->remap_file_range && !file_out->f_op->copy_file_range
>
> As I wrote above either leave the helper do_copy_file_range() or open
> code it in its current location.
>
>> + if (!file_out->f_op->copy_file_range ||
>> + (file_out->f_op->copy_file_range != file_in->f_op->copy_file_range))
>> + return -EXDEV;
>> +
>> if (flags != 0)
>> return -EINVAL;
>>
>> @@ -1513,8 +1469,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>> }
>> }
>>
>> - ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> - flags);
>> + ret = file_out->f_op->copy_file_range(file_in, pos_in,
>> + file_out, pos_out,
>> + len, flags);
>> WARN_ON_ONCE(ret == -EOPNOTSUPP);
>
> Please remove this line.
> filesystem ops can now return -EOPNOTSUPP.
>
> Thanks,
> Amir.
next prev parent reply other threads:[~2021-02-15 14:51 UTC|newest]
Thread overview: 136+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-12 4:43 [PATCH 0/6] Add generated flag to filesystem struct to block copy_file_range Nicolas Boichat
2021-02-12 4:44 ` [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated Nicolas Boichat
2021-02-12 7:46 ` Greg KH
2021-02-12 8:20 ` Nicolas Boichat
2021-02-12 8:37 ` Greg KH
2021-02-12 15:33 ` Ian Lance Taylor
2021-02-12 15:45 ` Greg KH
2021-02-12 15:59 ` Ian Lance Taylor
2021-02-12 16:28 ` Greg KH
2021-02-12 20:22 ` Ian Lance Taylor
2021-02-12 23:03 ` Dave Chinner
2021-02-12 23:07 ` Ian Lance Taylor
2021-02-12 23:27 ` Dave Chinner
2021-02-12 23:54 ` Darrick J. Wong
2021-02-15 0:38 ` Dave Chinner
2021-02-15 1:12 ` Ian Lance Taylor
2021-02-15 1:25 ` Nicolas Boichat
2021-02-15 5:56 ` Amir Goldstein
2021-02-15 8:30 ` Greg KH
2021-02-12 8:22 ` Amir Goldstein
2021-02-12 8:39 ` Greg KH
2021-02-12 12:05 ` Luis Henriques
2021-02-12 12:18 ` Greg KH
2021-02-12 12:41 ` Luis Henriques
2021-02-12 14:11 ` Greg KH
2021-02-12 15:01 ` Luis Henriques
2021-02-15 6:12 ` Amir Goldstein
2021-02-15 10:39 ` Luis Henriques
2021-02-15 12:22 ` Luis Henriques
2021-02-15 14:23 ` Amir Goldstein
2021-02-15 14:51 ` Luis Henriques [this message]
2021-02-15 15:43 ` [PATCH v2] vfs: prevent copy_file_range to copy across devices Luis Henriques
2021-02-15 16:02 ` Trond Myklebust
2021-02-16 0:25 ` Steve French
2021-02-15 16:34 ` Amir Goldstein
2021-02-15 16:53 ` Trond Myklebust
2021-02-15 17:24 ` Amir Goldstein
2021-02-15 18:57 ` Trond Myklebust
2021-02-15 19:43 ` Amir Goldstein
2021-02-16 11:17 ` Luis Henriques
2021-02-16 11:28 ` gregkh
2021-02-16 12:01 ` Luis Henriques
2021-02-16 12:08 ` Greg KH
2021-02-16 13:51 ` Amir Goldstein
2021-02-16 16:42 ` Luis Henriques
2021-02-16 17:44 ` Amir Goldstein
2021-02-16 18:55 ` Luis Henriques
2021-02-16 19:20 ` Amir Goldstein
2021-02-16 19:27 ` Anna Schumaker
2021-02-16 19:31 ` Steve French
2021-02-16 19:40 ` Amir Goldstein
2021-02-16 21:15 ` Steve French
2021-02-17 8:08 ` Amir Goldstein
2021-02-17 17:26 ` [PATCH v3] vfs: fix copy_file_range regression in cross-fs copies Luis Henriques
2021-02-17 20:47 ` Amir Goldstein
2021-02-18 0:56 ` Nicolas Boichat
2021-02-18 5:32 ` Olga Kornievskaia
2021-02-18 6:47 ` Amir Goldstein
2021-02-18 16:28 ` Olga Kornievskaia
2021-02-18 7:43 ` Christoph Hellwig
2021-02-18 0:50 ` [PATCH v2] vfs: prevent copy_file_range to copy across devices Andreas Dilger
2021-02-18 7:34 ` gregkh
2021-02-16 18:54 ` Andreas Dilger
2021-02-17 4:45 ` Nicolas Boichat
2021-02-18 7:42 ` Christoph Hellwig
2021-02-18 9:10 ` Amir Goldstein
2021-02-18 10:29 ` Luis Henriques
2021-02-18 12:15 ` Luis Henriques
2021-02-18 12:49 ` Amir Goldstein
2021-02-18 14:36 ` [PATCH v4] vfs: fix copy_file_range regression in cross-fs copies Luis Henriques
2021-02-18 14:58 ` Amir Goldstein
2021-02-18 15:17 ` [PATCH v5] " Luis Henriques
2021-02-18 15:53 ` Amir Goldstein
2021-02-18 16:35 ` Luis Henriques
2021-02-18 17:18 ` [PATCH v6] " Luis Henriques
2021-02-19 21:18 ` Olga Kornievskaia
2021-02-19 21:52 ` Amir Goldstein
2021-02-21 19:58 ` [PATCH v7] " Luis Henriques
2021-02-22 3:00 ` Nicolas Boichat
2021-02-22 10:24 ` [PATCH v8] " Luis Henriques
2021-02-22 10:46 ` Amir Goldstein
2021-02-22 16:25 ` dai.ngo
2021-02-23 10:32 ` Luis Henriques
2021-02-23 15:28 ` Amir Goldstein
2021-02-23 15:29 ` dai.ngo
2021-02-23 16:02 ` dai.ngo
2021-02-23 16:47 ` Amir Goldstein
2021-02-23 16:57 ` dai.ngo
[not found] ` <e3eed18b-fc7e-e687-608b-7f662017329c@oracle.com>
2021-02-23 17:33 ` Amir Goldstein
2021-02-24 0:13 ` dai.ngo
2021-02-23 17:56 ` Luis Henriques
2021-02-23 17:13 ` Olga Kornievskaia
2021-02-24 1:00 ` Olga Kornievskaia
2021-02-24 10:23 ` Luis Henriques
2021-02-24 10:44 ` Nicolas Boichat
2021-04-09 5:23 ` Nicolas Boichat
2021-04-09 13:39 ` Luis Henriques
2021-04-09 13:50 ` Amir Goldstein
2021-04-23 4:40 ` Nicolas Boichat
2021-05-03 8:54 ` Luis Henriques
2021-05-10 4:59 ` Amir Goldstein
2021-05-10 9:10 ` Luis Henriques
2021-02-24 14:23 ` [PATCH] copy_file_range.2: Kernel v5.12 updates Luis Henriques
2021-02-24 16:10 ` Amir Goldstein
2021-02-25 10:21 ` Luis Henriques
2021-02-26 10:13 ` Alejandro Colomar (man-pages)
2021-02-26 10:34 ` Amir Goldstein
2021-02-26 11:15 ` Alejandro Colomar (man-pages)
2021-02-26 13:59 ` Jeff Layton
2021-02-26 21:26 ` Alejandro Colomar (man-pages)
2021-02-26 22:18 ` Alejandro Colomar (man-pages)
2021-02-27 5:41 ` Amir Goldstein
2021-02-27 12:20 ` Alejandro Colomar (man-pages)
2021-02-27 13:49 ` [RFC v2] copy_file_range.2: Update cross-filesystem support for 5.12 Alejandro Colomar
2021-02-27 16:00 ` Amir Goldstein
2021-02-27 23:08 ` [PATCH] copy_file_range.2: Kernel v5.12 updates Steve French
2021-02-28 7:35 ` Amir Goldstein
2021-02-28 22:25 ` Steve French
2021-03-01 6:18 ` Amir Goldstein
2021-03-01 14:41 ` [RFC v3] copy_file_range.2: Update cross-filesystem support for 5.12 Alejandro Colomar
2021-03-01 14:58 ` Amir Goldstein
2021-03-04 9:38 ` [RFC v4] " Alejandro Colomar
2021-03-04 17:13 ` Darrick J. Wong
2021-03-04 18:24 ` Alejandro Colomar (man-pages)
2021-03-04 23:50 ` Darrick J. Wong
2021-02-24 7:15 ` [PATCH v4] vfs: fix copy_file_range regression in cross-fs copies Amir Goldstein
2021-02-24 8:30 ` Petr Vorel
2021-02-18 20:41 ` [PATCH v2] vfs: prevent copy_file_range to copy across devices Steve French
2021-02-12 23:15 ` [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated Dave Chinner
2021-02-12 7:54 ` Amir Goldstein
2021-02-12 4:44 ` [PATCH 2/6] proc: Add FS_GENERATED_CONTENT to filesystem flags Nicolas Boichat
2021-02-12 4:44 ` [PATCH 6/6] vfs: Disallow copy_file_range on generated file systems Nicolas Boichat
2021-02-12 4:53 ` Darrick J. Wong
2021-02-12 4:59 ` Darrick J. Wong
2021-02-12 5:24 ` Nicolas Boichat
2021-02-14 23:09 ` [PATCH 0/6] Add generated flag to filesystem struct to block copy_file_range Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878s7pl6z5.fsf@suse.de \
--to=lhenriques@suse.de \
--cc=Anna.Schumaker@netapp.com \
--cc=amir73il@gmail.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=drinkcat@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=iant@google.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llozano@chromium.org \
--cc=miklos@szeredi.hu \
--cc=sfrench@samba.org \
--cc=trond.myklebust@hammerspace.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).