Page MenuHomeFreeBSD

fusefs: fix two bugs regarding _PC_MIN_HOLE_SIZE
Needs ReviewPublic

Authored by asomers on Apr 3 2024, 8:06 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, May 8, 7:16 AM
Unknown Object (File)
Sat, May 4, 1:24 PM
Unknown Object (File)
Tue, Apr 30, 4:12 PM
Unknown Object (File)
Fri, Apr 26, 4:43 AM
Unknown Object (File)
Thu, Apr 25, 8:35 PM
Unknown Object (File)
Fri, Apr 19, 6:32 AM
Unknown Object (File)
Tue, Apr 16, 2:25 PM
Unknown Object (File)
Apr 12 2024, 3:29 AM
Subscribers

Details

Reviewers
emaste
Summary

Background:

If a user does pathconf(_, _PC_MIN_HOLE_SIZE) on a fusefs file system,
the kernel must actually issue a FUSE_LSEEK operation in order to
determine whether the server supports it. We cache that result, so we
only have to send FUSE_LSEEK the first time that _PC_MIN_HOLE_SIZE is
requested on any given mountpoint.

Problem 1:

Unlike fpathconf, pathconf operates on files that may not be open. But
FUSE_LSEEK requires the file to be open. As described in PR 278135,
FUSE_LSEEK cannot be sent for unopened files, causing _PC_MIN_HOLE_size
to wrongly report EINVAL. We never noticed that before because the
fusefs test suite only uses fpathconf, not pathconf. Fix this bug by
opening the file if necessary.

Problem 2:

On a completely sparse file, with no data blocks at all, FUSE_LSEEK with
SEEK_DATA would fail to ENXIO. That's correct behavior, but
fuse_vnop_pathconf wrongly interpreted that as "FUSE_LSEEK not
supported". Fix this bug by using SEEK_HOLE instead of SEEK_DATA, as
the former should work even for fully sparse or 0-length files.

PR: 278135
MFC after: 1 week
Sponsored by: Axcient

Test Plan

Test case added, plus manual testing with sysutils/fusefs-xfuse

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 56916
Build 53804: arc lint + arc unit

Event Timeline

sys/fs/fuse/fuse_vnops.c
1798

should we check the return value? I guess it doesn't matter, we'll just handle the error from the subsequent fuse_vnop_do_lseek. Is there any problem calling fuse_filehandle_close if there was an error here though?

sys/fs/fuse/fuse_vnops.c
1798

Hmm. Probably an efficiency problem, if not a functional one. I'll update to skip the fuse_filehandle_close in that case.

Actually, another problem is that EACCES, EINTEGRITY, and EIO errors won't be correctly reported. That problem predates this review, but I'll fix it now.

  • Skip the fuse_vnop_do_lseek and fuse_filehandle_close if
  • Two more fixes: