Re: EBADF returned from close() by FUSE

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

On 19-04-2024 23:29, Antonio SJ Musumeci wrote:
>> 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.

I'm writing to a linux mailing list, am I not? And referring to linux-specific
manpages, not the POSIX ones. The way the linux kernel chooses to pass
what FUSE sends to userspace is under its control.

I would like linux to adhere more closely to its own API contract or improve its
documentation.

>> 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.

That seems hardly relevant to this case here.

>> 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.

If other things can cause this too, then yes of course, a more general
solution would be fine too for my purposes.
Should I have written to another list? Or filed a report on bugzilla instead?

>> 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.

I don't understand what would be broken here. In a previous mail you agreed
that FUSE servers have no business sending EBADF and should have a
bug filed against them. If that's the case then sanitizing problematic cases
should be ok.

The libfuse documentation even notes that servers should not assume errors
from flush get delivered to userspace.