Re: EBADF returned from close() by FUSE

[Antonio SJ Musumeci <trapexit@spawn.link>]

On 4/19/24 15:45, The 8472 wrote:
> Syscalls have documentation. Errors and their semantics are part
> of the documentation. If the kernel cannot actually provide
> the documented semantics because it passes errors through without
> sanitizing them then this should at least be documented
> for each affected syscall.
And that documentation is *different* depending on the platform. The 
clean vision you seem to have about errnos is not real. There are 
conventions... not strong contracts. I had this exact debate days ago 
about `link`. The claim that if link isn't supported by the OS FUSE 
should return EPERM. But this just isn't standard the way people think 
it is. Not on paper. And if a FUSE server wants to return EPERM then it 
can. I don't see why the kernel needs to get in the business of reading 
the mind of the server author.
>
> Proper API documentation and stability guarantees are important
> so we can write robust software against them.
>
> Note that write(2) documents
>
>      Other errors may occur, depending on the object connected to fd.
>
> close(2) has no such note.

Your idea is laudable but not realistic. errnos are not even fully 
consistent across devices or filesystem. Yes, there are norms and some 
standards but they are not enforced by some central arbiter across all 
forms of *nix.

> That does not mean userspace should be exposed to the entirety
> of the mess. And in my opinion EIO is better than EBADF because
> the former "merely" indicates that something went wrong relating
> to a particular file. EBADF indicates that the file descriptor
> table of the process may have been corrupted.

"should"... but it is exposed to it. *Most* software doesn't even 
attempt to handle errors intelligently and just return the error up the 
stack blindly. EIO is about as generic as can be and I've seen it used 
many times as the "catch all" error making it meaningless. Further 
incentivizing client software to behave as they do... not paying 
attention. I will again point out that I've seen EXDEV treated like any 
random other error several times in my career by important pieces of 
software made by major vendors.

> Will try. But the kernel should imo also do its part fulfilling its API
> contract.
Then you are barking up the wrong tree. This isn't an issue unique to 
FUSE. FUSE just makes it more obvious to you because anyone can write a 
FUSE server and return (almost) anything they want.
> That it requires perhaps some thought to do it properly does not seem
> sufficient to me to dismiss the request to provide a proper
> abstraction boundary with reliable semantics that match its documentation.

I simply don't see what you could do to "do it properly." I am trying to 
argue there is no such thing. And again it would require breaking every 
single FUSE server.