[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201201145728.GA11144@nautica>
Date: Tue, 1 Dec 2020 15:57:28 +0100
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: Eric Van Hensbergen <ericvh@...il.com>,
Latchesar Ionkov <lucho@...kov.net>,
v9fs-developer@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs: 9p: add generic splice_read file operations
Toke Høiland-Jørgensen wrote on Tue, Dec 01, 2020:
> The v9fs file operations were missing the splice_read operations, which
> breaks sendfile() of files on such a filesystem. I discovered this while
> trying to load an eBPF program using iproute2 inside a 'virtme' environment
> which uses 9pfs for the virtual file system. iproute2 relies on sendfile()
> with an AF_ALG socket to hash files, which was erroring out in the virtual
> environment.
>
> Since generic_file_splice_read() seems to just implement splice_read in
> terms of the read_iter operation, I simply added the generic implementation
> to the file operations, which fixed the error I was seeing. A quick grep
> indicates that this is what most other file systems do as well.
Good catch, might as well do that.
I'm surprised you didn't hit the same problem with splice_write?
I see iter_file_splice_write being used for it on many filesystems,
it's probably better to add both?
> The only caveat is that my test case was only hitting the
> v9fs_file_operations_dotl implementation. I added it to the other file
> operations structs as well because it seemed like the sensible thing to do
> given that they all implement read_iter, but those are only compile tested.
The logic is close enough that it should work, I'll run it through in
cached mode at least first though (just mount with cache=loose or
cache=fscache to hit v9fs_cached_file_operations_dotl yourself if you
want to)
non-dotl operations are harder to test, I don't have any server
compatible either so we'll have to trust it works close enough...
(note you can write comments such as this one after the three dashes
line before the diff chunk so maintainers can reply without having it in
commit message itself)
--
Dominique
Powered by blists - more mailing lists