From: Al Viro <viro@ftp.linux.org.uk>
To: Shaya Potter <spotter@cs.columbia.edu>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
Chaitanya Patti <crpatti@cs.sunysb.edu>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Is a NULL check missing in nfs_lookup?
Date: Fri, 5 Jan 2007 17:22:01 +0000 [thread overview]
Message-ID: <20070105172201.GB17561@ftp.linux.org.uk> (raw)
In-Reply-To: <1168017077.29243.38.camel@localhost.localdomain>
On Fri, Jan 05, 2007 at 12:11:17PM -0500, Shaya Potter wrote:
> ok, I guess what I don't understand is when are
>
> dentry->d_sb->s_root and nd->mnt->mnt_root not equivalent.
>
> I guess it would be "when crossing a mountpoint on the server", so I
> look at nfs_follow_mountpoint() and basically see that you create a new
> mountpoint and a new nd for that. And since superblock objects are only
> per "real" file system not per mount point, they will be different.
>
> I guess the question is, why shouldn't a dentry object know what
> vfsmount it belongs to is? Can it belong to multiple vfsmount objects?
Yes. dentry belongs to superblock. vfsmount refers to a subtree of some
superblock's dentry tree. There can be any number of vfsmounts refering
to subtrees of the same fs. Some might refer to the entire tree, some -
to its arbitrary subtrees (possibly as small as a single file). There
can be any number of vfsmounts refering to any given subtree.
Think what happens when you create a binding. Or when you clone an entire
namespace. (Pieces of) the same filesystem might be mounted in a lot
of places. vfsmount describes a part of unified tree delimited by
mountpoints; if the same fs (or its parts) are seen under several
mountpoints, you get vfsmounts that refer to the same fs instance, i.e.
the same superblock and dentry tree.
next prev parent reply other threads:[~2007-01-05 17:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-05 0:00 Is a NULL check missing in nfs_lookup? Chaitanya Patti
2007-01-05 0:47 ` Shaya Potter
2007-01-05 1:59 ` Josef Sipek
2007-01-07 14:13 ` Ian Kent
2007-01-05 12:22 ` Trond Myklebust
2007-01-05 15:00 ` Shaya Potter
2007-01-05 16:01 ` Trond Myklebust
2007-01-05 17:11 ` Shaya Potter
2007-01-05 17:22 ` Al Viro [this message]
2007-01-05 17:22 ` Matthew Wilcox
2007-01-06 7:36 ` Why not pass "vfsmount" to VFS functions? Tetsuo Handa
2007-01-05 19:10 ` Is a NULL check missing in nfs_lookup? Erez Zadok
2007-01-05 19:23 ` Matthew Wilcox
2007-01-05 19:41 ` Muli Ben-Yehuda
2007-01-05 20:13 ` Erez Zadok
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=20070105172201.GB17561@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=crpatti@cs.sunysb.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=spotter@cs.columbia.edu \
--cc=trond.myklebust@fys.uio.no \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.