Re: [RFC] Re: broken userland ABI in configfs binary attributes

[Al Viro <viro@zeniv.linux.org.uk>]

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