lkml.org 
[lkml]   [2012]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC] vfs: make fstatat retry on ESTALE errors from getattr call
    On Tue, 17 Apr 2012 15:12:20 +0200
    Miklos Szeredi <miklos@szeredi.hu> wrote:

    > Jeff Layton <jlayton@redhat.com> writes:
    >
    > >>
    > >> Won't something like fstatat(AT_FDCWD, "", &stat, AT_EMPTY_PATH) risk
    > >> looping forever there, or am I missing something?
    > >>
    > >
    > > To make sure I understand, that should be "shortcut" for a lookup of the
    > > cwd?
    > >
    > > So I guess the concern is that you'd do the above and get a successful
    > > lookup since you're just going to get back the cwd. At that point,
    > > you'd attempt the getattr and get ESTALE back. Then, you'd redo the
    > > lookup with LOOKUP_REVAL set -- but since we're operating on the
    > > cwd, we don't have a way to redo the lookup since we don't have a
    > > pathname that we can look up again...
    > >
    > > So yeah, I guess if you're sitting in a stale directory, something like
    > > that could loop eternally.
    > >
    > > Do you think the proposed check for fatal_signal_pending is enough to
    > > mitigate such a problem? Or do we need to limit the number of retries
    > > to address those sorts of loops?
    >
    > Lets step back a bit.
    >
    > The retry is needed when when we discover during ->getattr() that the
    > cached lookup returned a stale file handle.
    >
    > If the lookup wasn't cached or if there was no lookup at all
    > (stat(".") and friends) then retrying will not gain anything.
    >

    That's not necessarily the case, at least not with NFS. It's easily
    possible for you to do a full-fledged lookup over the wire, and then
    for that inode to be removed prior to issuing a call against the FH that
    you got back.

    > And that also means that retrying multiple times is pointless, since
    > after the first retry we are sure to have up-to-date attributes.
    >

    Again, it's not pointless. It's possible (though somewhat pathological)
    for you to hit the race above more than once in the same operation.
    Granted, it's an unlikely race but it is possible.

    > Unfortunately it's impossible for the filesystem to know whether a
    > ->getattr (or other inode operation) was perfromed after a cached or a
    > non-cached lookup.
    >
    > I'm not sure what the right interface for this would be. One would be
    > to just pass the "cached-or-not" information as a flag. That works for
    > getattr() but not for other operations.
    >
    > Another is to introduce atomic lookup+foo variants of these operations
    > just like for open. E.g. the lookup+getattr is called if the cached
    > lookup fails or if the cached lookup succeeds and the plain ->getattr
    > call returns ESTALE.
    >

    To do that would require protocol support that we simply don't have. We
    don't have a way to (for instance) say via NFS "give me the attributes
    for this filename". Well, at least not for NFSv3...

    With v4 you could theoretically construct a compound that does that,
    but you'd have to assume that the server won't release the reference to
    the inode midway through the compound. That's a reasonably safe
    assumption.

    While it's nice to consider new atomic ops like this, it's not really
    possible with earlier versions of NFS.

    --
    Jeff Layton <jlayton@redhat.com>


    \
     
     \ /
      Last update: 2012-04-17 15:35    [W:0.022 / U:0.168 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site