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.
In kernel/*: ftrace_graph_release() might return -ENOMEM. No idea whether it's
actually possible.
In net/*: none
In sound/*: 4 instances.
snd_pcm_oss_release():
if (snd_BUG_ON(!substream))
return -ENXIO;
IOW, whine in impossible case.
snd_pcm_release():
ditto.
sq_release():
if (file->f_mode & FMODE_WRITE) {
if (write_sq.busy)
rc = sq_fsync();
subsequently returns rc; sq_fsync() can return an error, both on timeout
and in case of interrupted wait.
snd_hwdep_release():
passes the return value of hwdep ->release() method; two of those
can return an error. snd_asihpi_hpi_release() is, AFAICS, impossible,
unless you manage to flip this module_param(enable_hpi_hwdep, bool, 0644);
off after opening a file. And snd_usX2Y_hwdep_pcm_release() calls
usX2Y_pcms_busy_check() and passes its return value out. No idea
whether that can be triggered.
In other words, the real mess is hidden in drivers/*...
