On Thu, 23 Jan 2025 at 03:03, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> What's the point of re-walking the same trajectory in dcache again
> and why would it yield something different this time around?
Nfs4 skips revalidate on last component and returns EOPENSTALE from
its ->open() if it turned out to be wrong. All components leading up
to that were revalidated and the invalid dentry dropped, so what's
really needed is just redoing the last component.
There was an optimization which tried to do this bug eventually got
removed because it was buggy (fac7d1917dfd ("fix EOPENSTALE bug in
do_last()")). That leaves the choice of redoing the cached lookup
(which should succeed again) or starting from scratch. I see no point
in doing the latter, although the rarity of this event probably means
that no one would ever notice the difference.
> IDGI. We *can't* get to open callback without having already dealt
> with leaving RCU mode - any chance of having walked into the wrong
> place due to lack of locking has already been excluded when we'd
> successfully left RCU mode; otherwise we would've gotten to that
> check with error already equal to -ECHILD.
Right. The point is to not do LOOKUP_REVALIDATE unless we really need
to. Otherwise EOPENSTALE would just be equivalent to ESTALE.
Thanks,
Miklos
>
> What sequence of events do you have in mind?
