Page MenuHomeFreeBSD

fusefs: fix two bugs regarding _PC_MIN_HOLE_SIZE
ClosedPublic

Authored by asomers on Apr 3 2024, 8:06 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Dec 25, 12:23 AM
Unknown Object (File)
Mon, Dec 2, 7:22 AM
Unknown Object (File)
Mon, Dec 2, 7:22 AM
Unknown Object (File)
Mon, Dec 2, 7:07 AM
Unknown Object (File)
Mon, Dec 2, 6:47 AM
Unknown Object (File)
Nov 22 2024, 1:36 AM
Unknown Object (File)
Oct 31 2024, 4:41 PM
Unknown Object (File)
Oct 9 2024, 1:43 AM
Subscribers

Details

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:
This revision was not accepted when it landed; it landed in state Needs Review.Jun 24 2024, 4:07 PM
This revision was automatically updated to reflect the committed changes.
sys/fs/fuse/fuse_vnops.c
1827

err is gua

1827

Oops, not sure what this was going to be. It was waiting as an unsubmitted draft.