On Thu, Aug 29, 2019 at 11:22:58PM +0100, Al Viro wrote: > On Tue, Aug 27, 2019 at 06:27:35PM +0100, Al Viro wrote: > > > Most of them are actually pure bollocks - "it can never happen, but if it does, > > let's return -EWHATEVER to feel better". Some are crap like -EINTR, which is > > also bollocks - for one thing, process might've been closing files precisely > > because it's been hit by SIGKILL. For another, it's a destructor. It won't > > be retried by the caller - there's nothing called for that object afterwards. > > What you don't do in it won't be done at all. > > > > And some are "commit on final close" kind of thing, both with the hardware > > errors and parsing errors. > > FWIW, here's the picture for fs/*: 6 instances. > > afs_release(): > calls vfs_fsync() if file had been opened for write, tries to pass > the return value to caller. Job for ->flush(), AFAICS. > > coda_psdev_release(): > returns -1 in situation impossible after successful ->open(). > Can't happen without memory corruption. > > configfs_release_bin_file(): > discussed upthread > > dlm device_close(): > returns -ENOENT if dlm_find_lockspace_local(proc->lockspace) fails. > No idea if that can happen. > > reiserfs_file_release(): > tries to return an error if it can't free preallocated blocks. > > xfs_release(): > similar to the previous case. Not quite right. XFS only returns an error if there is data writeback failure or filesystem corruption or shutdown detected during whatever operation it is performing. We don't really care what is done with the error that we return; we're just returning an error because that's what the function prototype indicates we should do... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
