Re: [RFC] EOPENSTALE handling in path_openat()

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

On Tue, Jan 21, 2025 at 01:07:38PM +0100, Miklos Szeredi wrote:
> On Sun, 19 Jan 2025 at 06:40, Al Viro <viro@zeniv.linux.org.uk> wrote:
> 
> > Miklos, could you recall what was the original intent of that?
> > Do we want to keep that logics there, or should it just turn into
> > "map -ENOPENSTALE to -ESTALE??
> 
> I think the intent was to prevent a full LOOKUP_REVAL if this happened
> on the first try in do_filp_open().  I still think that makes sense,
> but needs a comment since it's not obvious.

For that to have happened we need the following sequence:
	* we started in RCU mode
	* we'd run into something that needs fallback to non-RCU (e.g.
open() callback itself)
	* we had successfully switched to non-lazy mode - grabbed
references, etc.
	* we got to call of open() callback and that returned us -EOPENSTALE.

What's the point of re-walking the same trajectory in dcache again
and why would it yield something different this time around?

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.

What sequence of events do you have in mind?