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