You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The fuse directio call path is as follows
fuse_read_fill+0xa8/0xb0
fuse_send_read+0x3f/0xb0
fuse_direct_io+0x34a/0x5f0
__fuse_direct_read+0x4e/0x70
fuse_file_read_iter+0x9e/0x140
new_sync_read+0xde/0x120
__vfs_read+0x27/0x40
vfs_read+0x94/0x190
ksys_read+0x4e/0xd0
under the direct io path, fuse initiates a request whose request size is determined
by the combination of the user-supplied buffer size and max_read mount parameters.
size_t nmax = write ? fc->max_write : fc->max_read;
size_t count = iov_iter_count(iter);
size_t nbytes = min(count, nmax);
nres = fuse_send_read(req, io, pos, nbytes, owner);
so we have a problem with the checking of the request size in the code, we always
compare the request size with MAX_BUFFER_SIZE, but in fact the maximum value of the
request size depends on max_read, in virtiofs scenario max_read is UINT_MAX by default,
and in fuse scenario it is possible to adjust max_read by the mounting parameter.
the current implementation of fuse-backend-rs uses a fixed buffer to store the fuse response
the default value of this buffer is as follows, but in fact, the kernel in the direct io path,
the size of the request may be larger than the length of this buffer, which leads to the buffer
is not enough to fill the read content, resulting in read failure. so here we limit the size of
max_read to the length of our buffer so that the fuse kernel will not send requests that exceed
the length of the buffer. in virtiofs scene max_read can't be adjusted, his default is UINT_MAX,
but we don't have to worry about it, because the buffer is allocated by the kernel driver, we
just use this buffer to fill the response, so we don't need to do any adjustment.
Signed-off-by: zyfjeff <zyfjeff@linux.alibaba.com>
0 commit comments