Re: [PATCH v4 00/54] tree-in-dcache stuff

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

On Fri, Jan 30, 2026 at 11:57:43PM +0000, Al Viro wrote:

> Another thing to try (not as a suggestion of a fix, just an attempt to figure
> out how badly would the things break): in current mainline replace that
> 	ffs_mutex_lock(&ffs->mutex, file->f_flags & O_NONBLOCK)
> in ffs_ep0_open() with
> 	ffs_mutex_lock(&ffs->mutex, false)
> and see how badly do the things regress for userland.  Again, I'm not saying
> that this is a fix - just trying to get some sense of what's the userland
> is doing.

At a guess, quite badly.  ffs->mutex *is* way too heavy for that purpose -
that's a geniune bug.

State transitions in that thing are messy; AFAICS, the state is a combination
of ->opened and ->state, and transitions assume atomicity that just isn't there.

All updates of ->opened are process-synchronous; the nasty part is in the
FFS_DEACTIVATED handling.  We don't want it to coexist with ->opened > 0;
normally decrement of ->opened to 0 gets us into FFS_CLOSING immediately
and follows that with ffs_data_reset().  In -o no_disconnect mounts we switch
to FFS_DEACTIVATED instead.  On the next open() after that we want it to
transition to the same FFS_CLOSING + the same call of ffs_data_reset().

open() running into FFS_CLOSING fails; that happens until ffs_data_reset()
switches ->state to FFS_READ_DESCRIPTORS.

Things are complicated by ffs_func_set_alt() and ffs_func_disable() - these
can come with ->opened being zero and both contain this:
        if (ffs->state == FFS_DEACTIVATED) {
		ffs->state = FFS_CLOSING;
		INIT_WORK(&ffs->reset_work, ffs_reset_work);
		schedule_work(&ffs->reset_work);
		return -ENODEV;
	}
with s/return -ENODEV;/return;/ for ffs_func_disable().  The point, AFAICT,
is to avoid deadlocks from having ffs_data_reset() called in the locking
environment these two are called in.  At least ->set_alt() can be called
under a spinlock and ffs_data_reset() is blocking.

Another potentially troubling part is the check for FFS_ACTIVE in the
same functions, seeing that
                        ffs->state = FFS_ACTIVE;
                        mutex_unlock(&ffs->mutex);
 
                        ret = ffs_ready(ffs);
                        if (ret < 0) {
                                ffs->state = FFS_CLOSING;
                                return ret;
                        }
in ep0 write() happens with no exclusion with those (as the matter of
fact, that transition to FFS_CLOSING holds no locks at all)...