Re: EBADF returned from close() by FUSE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux