Re: EBADF returned from close() by FUSE

[The 8472 <kernel@infinite-source.de>]

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.