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

[Samuel Wu]

On Fri, Jan 30, 2026 at 3:55 PM Al Viro <viro at zeniv.linux.org.uk> wrote:

> So we have something that does O_NDELAY opens of ep0 *and* does not retry on
> EAGAIN?
>
> How lovely...  Could you slap
>         WARN_ON(ret == -EAGAIN);
> right before that
>         if (ret < 0)
>                 return ret;

Surprisingly ret == 0 every time, so no difference in dmesg logs with
this addition.

> in there and see which process is doing that?  Regression is a regression,
> odd userland or not, but I would like to see what is that userland actually
> trying to do there.
>
> *grumble*
>
> IMO at that point we have two problems - one is how to avoid a revert of the
> tail of tree-in-dcache series, another is how to deal with quite real
> preexisting bugs in functionfs.
>
> 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.

Ergo this didn't make a difference either.