[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3088368.1603790984@warthog.procyon.org.uk>
Date: Tue, 27 Oct 2020 09:29:44 +0000
From: David Howells <dhowells@...hat.com>
To: Christoph Hellwig <hch@....de>
Cc: dhowells@...hat.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Michael Ellerman <mpe@...erman.id.au>, x86@...nel.org,
Kees Cook <keescook@...omium.org>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-arch@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH 02/10] fs: don't allow splice read/write without explicit ops
Christoph Hellwig <hch@....de> wrote:
> default_file_splice_write is the last piece of generic code that uses
> set_fs to make the uaccess routines operate on kernel pointers. It
> implements a "fallback loop" for splicing from files that do not actually
> provide a proper splice_read method. The usual file systems and other
> high bandwith instances all provide a ->splice_read, so this just removes
> support for various device drivers and procfs/debugfs files. If splice
> support for any of those turns out to be important it can be added back
> by switching them to the iter ops and using generic_file_splice_read.
Hmmm... this causes the copy_file_range() syscall to fail with EINVAL in some
places where before it used to work.
For my part, it causes the generic/112 xfstest to fail with afs, but there may
be other places.
Is this a regression we need to fix in the VFS core? Or is it something we
need to fix in xfstests and assume userspace will fallback to doing it itself?
David
Powered by blists - more mailing lists