On 19-04-2024 13:42, Antonio SJ Musumeci wrote:
On 4/19/24 01:55, The 8472 wrote:
On 19-04-2024 05:30, Antonio SJ Musumeci wrote:
I can't see how the kernel could meaningfully know of or limit errors
coming from the FUSE server without compromising the nature of the
technology. So in that sense... yes, it is intentional.
File descriptor numbers are not a FUSE-managed resource, so I was hoping
it would reserve error codes that are documented to signal incorrect
access to that resource and convert external errors to another code (e.g. EIO).
This would then signal that the file descriptor itself was valid but the underlying
resource encountered an error while performing the operation.
Anything can be a FUSE managed resource by proxy. [...]
I'm referring to the slots in the file descriptor table of a process (A) that is opening
a file on a FUSE filesystem. Whether a slot (FD number) is occupied or not
is between the kernel and that process, not the server (S).
Imo the kernel should only return EBADF when the process accesses an FD
that is not in its table, which tends to be a fatal error in multithreaded
programs.
If S internally accesses invalid file descriptors that has no
bearing on the state of the FD table of A. From A's perspective
some sort of IO error occurred in the underlying storage system
while releasing the FD, but it did use a valid file descriptor.
[...] There are a number of
situations where FUSE itself return errors but the largest surface area
for errors are from the FUSE server. And the server needs the ability to
return nearly anything.
I'm not talking about what the server is allowed to return. I'm referring
to which errors from the server get bubbled up verbatim through syscalls on
files that are a FUSE mount.
Is it necessary to pass through arbitrary FUSE errors, especially EBADF,
when a processes closes a file that's backed by fuse?
This shouldn't happen:
|openat(AT_FDCWD, "./fuse-test/foo", O_RDONLY|O_CLOEXEC) = 5 close(5) = -1 EBADF (Bad file descriptor)|
Errnos are not *really* standard. They vary by
kernel release, different OSes, different libcs, different filesystems,
etc. As I pointed out recently to someone the use of EPERM to mean a
filesystem doesn't support "link" is not defined everywhere. Including
POSIX IIRC. And given FUSE is a cross platform protocol it shouldn't,
within reason, be interpreting any errors sent from the server (IMO).
FUSE can send any errnos it wants over its client-server protocol.
But the kernel could still translate them to error codes that don't
have a documented meaning for a specific syscall.
