From: Ian Kent <raven@themaw.net>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Miklos Szeredi <miklos@szeredi.hu>,
David Howells <dhowells@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Leonardo Chiquitto <leonardo.lists@gmail.com>,
autofs@linux.kernel.org
Subject: Re: [PATCH] vfs: automount should ignore LOOKUP_FOLLOW
Date: Fri, 09 Sep 2011 11:37:44 +0800 [thread overview]
Message-ID: <1315539464.3952.45.camel@perseus.themaw.net> (raw)
In-Reply-To: <20110908215425.GW2203@ZenIV.linux.org.uk>
On Thu, 2011-09-08 at 22:54 +0100, Al Viro wrote:
> On Thu, Sep 08, 2011 at 01:19:49PM -0700, Linus Torvalds wrote:
>
> > >> I'm inclined to apply the patch as a regression fix, but I'll let this
> > >> thread try to convince me for another day..
> > >
> > > IIRC, that matches traditional SunOS behaviour and it actually does make
> > > sense; you want wildcard expansion and ls -l to be doable even when there's
> > > a stuck NFS server. ?IOW, non-triggering lstat(2) is a matter of usability...
> >
> > non-triggering lstat() isn't the issue, afaik. We never trigger on lstat.
> >
> > nontriggering *stat()* is the issue. We didn't *use* to trigger on
> > stat() either. Now in 2.6.38+ we do.
>
> Yes. Again, IIRC that's what SunOS implementation had been doing all along;
> I think the reason was that stat()+open()+fstat() getting different results
> for stat and fstat would spook quite a few programs, but I could be easily
> wrong on that.
Yes, that the sort of problem that we see.
For example, find(1) has had problems with this sort of inconsistency
with before and after comparisons it makes as it walks the directory
tree.
Ian
next prev parent reply other threads:[~2011-09-09 3:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-05 16:06 Miklos Szeredi
2011-09-05 16:37 ` David Howells
2011-09-05 17:02 ` Miklos Szeredi
2011-09-06 3:53 ` Ian Kent
2011-09-06 4:03 ` Ian Kent
2011-09-06 8:09 ` Miklos Szeredi
2011-09-06 14:38 ` Ian Kent
2011-09-06 15:39 ` Miklos Szeredi
2011-09-08 12:36 ` Ian Kent
2011-09-08 13:38 ` Miklos Szeredi
2011-09-08 17:42 ` Linus Torvalds
2011-09-08 19:50 ` Al Viro
2011-09-08 20:19 ` Linus Torvalds
2011-09-08 21:54 ` Al Viro
2011-09-09 3:37 ` Ian Kent [this message]
2011-09-09 3:33 ` Ian Kent
2011-09-09 3:18 ` Ian Kent
2011-09-22 12:29 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1315539464.3952.45.camel@perseus.themaw.net \
--to=raven@themaw.net \
--cc=autofs@linux.kernel.org \
--cc=dhowells@redhat.com \
--cc=leonardo.lists@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®