Messages in this thread | | | Date | Tue, 27 Oct 2020 08:55:41 +0100 | From | Greg KH <> | Subject | Re: problems with splice from /proc (was Linux 5.10-rc1) |
| |
On Tue, Oct 27, 2020 at 07:49:11AM +0000, Christoph Hellwig wrote: > On Tue, Oct 27, 2020 at 07:48:32AM +0100, Greg KH wrote: > > On Sun, Oct 25, 2020 at 03:40:27PM -0700, Linus Torvalds wrote: > > > The most interesting - to me - change here is Christoph's setf_fs() > > > removal (it got merged through Al Viro, as you can see in my mergelog > > > below). It's not a _huge_ change, but it's interesting because the > > > whole model of set_fs() to specify whether a userspace copy actually > > > goes to user space or kernel space goes back to pretty much the > > > original release of Linux, and while the name is entirely historic (it > > > hasn't used the %fs segment register in a long time), the concept has > > > remained. Until now. > > > > I told Al this yesterday, but figured I would mention it here for others > > to see. > > > > Commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit > > ops") from this patch series, is breaking the bionic test suite that > > does the following to verify that splice is working: > > > > int in = open("/proc/cpuinfo", O_RDONLY); > > ASSERT_NE(in, -1); > > > > TemporaryFile tf; > > ssize_t bytes_read = splice(in, nullptr, pipe_fds[1], nullptr, 8*1024, SPLICE_F_MORE | SPLICE_F_MOVE); > > ASSERT_NE(bytes_read, -1); > > > > Before this change, all works well but now splice fails on /proc files > > (and I'm guessing other virtual filesystems). > > > > I'll ask the bionic developers if they can change their test to some > > other file, but this is a regression and might show up in other "test > > platforms" as well. Using /proc for this is just so simple because > > these files are "always there" and don't require any housekeeping for > > test suites to worry about . > > Is this just a test or a real application? I already have the > infrastructure to support read_iter/write_iter on procfs and seq_files, > but due to the intrusiveness we decided to only fix instances on an as > needed basis. So we'll have everything ready once we pull the trigger.
This is just a test, part of the bionic test suite to verify that bionic is working properly, and is run on new kernels as a verification that nothing functional broke in the kernel update.
I don't know about "real applications" yet.
Do you have to implement this on a per-proc-file-basis, or will it work for the whole filesystem?
And are the patches public anywhere that I could test them out?
thanks,
greg k-h
| |