A filesystem is represented in memory using dentries and inodes.  Inodes are
the objects that represent the underlying files (and also directories).  A
dentry is an object with a string name (d_name), a pointer to an inode
(d_inode), and a pointer to the parent dentry (d_parent).

So a tree such as

	/
	|
	foo
	|   \
	bar  bar2

is represented by four inodes: one each for foo, bar, and bar2, and the root;
and three dentries: one linking bar to foo, one linking bar2 to foo, and one
linking foo to the root.  The first of those dentries, for example, has a name
of "bar", a d_inode pointing to the underlying file bar, and a d_parent
pointing to the dentry for foo (which in turn would have a d_parent pointing to
the dentry for the root).  The root dentry has a d_parent that points to
itself.

Note that the mapping from dentries to inodes given by d_inode is in general a
many-to-one mapping; a single file may be pointed to by multiple paths in the
same filesystem (called "hard links"), in which case it will not be deleted
as long as any such path exists.

Files and directories may also be opened by processes, of course, and a struct
file is used to represent this.  The struct file contains a pointer to the
dentry.  The underlying file will also not be deleted as long as there are
processes holding the file open, even though that file may no longer be
accessible by any path in the filesystem.

Inodes in addition have i_sb pointers that point to the superblock, a structure
representing the underlying filesystem (usually representing either the
physical filesystem stored on a local partition, or a filesystem on a remote
system, in the case of NFS).

The namespace that a process sees, however, is normally made up of more than
just one filesystem; instead it is patched together from multiple filesystems
that are mounted on top of each other.  The structure of mountpoints is
represented by a tree of vfsmount structures, one for each mountpoint.

In addition to links to parent and child vfsmounts, each vfsmount contains:
	mnt_root: a pointer to the dentry that is the *root* of the vfsmount.
	mnt_mountpoint: a pointer to the dentry that this vfsmount is
		mounted on.

The relationship between vfsmounts and underlying filesystems is also
many-to-one; using mount --bind one can mount the same filesystem in multiple
places, resulting in multiple vfsmounts that share the same dentries, inodes,
and superblock.

In addition, it is possible for different processes to see entirely different
namespaces; if we create a new task by calling clone (see the clone(2) man
page) with the CLONE_NEWNS flag, then that process will be given its own copy
of its parent's tree of vfsmounts.  The root of the namespace is the vfsmount
pointed to by task->namespace->root.  (Though task->fs->root task->fs->rootmnt
is where lookups actually start, and may point somewhere different from
task->namespace->root if we've done a chroot.)

So, to look up an absolute path (e.g., "/foo/bar"), what we do is:
	1. Start at the task->fs->rootmnt vfsmount, and the dentry
	   task->fs->root.
	2. Look for a dentry "foo" whose d_parent is this dentry
	   and whose name is "foo".
	3. Check to see if there's something mounted on the dentry we just
	   found; if so, look up whatever's mounted there and replace the
	   current vfsmount by that vfsmount and the new dentry by its root
	   dentry.
	4. Repeat step 2 for "bar" and the resulting vfsmount and dentry.

Step 3 is the complicated bit.  The dentry we found at step 2 could actually be
referenced from multiple places in multiple different namespaces.  In each of
those places, it could have different filesystems mounted on it (or could have
nothing mounted on it at all).  So there's no way to determine what is mounted
on a dentry if all we know is the dentry; we also have to have a vfsmount.

So instead what we do is look up the dentry and vfsmount in a hash table; the
result is a vfsmount showing what (if anything) is mounted in the given dentry
in the given vfsmount.

It is also possible to mount a filesystem at a dentry and then to mount another
filesystem on top of that mount, hiding the first filesystem.  So once we've
found a vfsmount that is mounted at the dentry, we need to repeat the lookup
for the new vfsmount and its root dentry to see whether something else is
mounted there, and we repeat this process until we find a vfsmount with a root
dentry that doesn't have anything else mounted on it.

You can see this process performed by, e.g., namei.c:follow_mount().

Note that at each stage of a lookup it's not just the dentry that we need, it's
the pair of a dentry and a vfsmount.  Thus the struct nameidata, which, among
other things, contains a dentry and vfsmount, can be used to hold the state of
a lookup in progress.

Additional notes
^^^^^^^^^^^^^^^^

Details on the task_struct, defined in include/linux/sched.h:  it contains
struct fs_struct *fs and struct namespace *namespace fields:

struct fs_struct {
	atomic_t count;
	rwlock_t lock;
	int umask;
	struct dentry * root, * pwd, * altroot;
	struct vfsmount * rootmnt, * pwdmnt, * altrootmnt;
};

struct namespace {
	atomic_t                count;
	struct vfsmount *       root;
	struct list_head        list;
	struct rw_semaphore     sem;
};

sys_chroot() calls set_fs_root, which only changes fs->root and fs->rootmnt.
Note that it doesn't actually change the current working directory (as
represented by pwd and pwdmnt), so that directory, along with any files
the task has open, are still accessible despite the chroot.

The namespace-related work of sys_clone seems to be done by copy_namespace,
which sets both the tsk->namespace and the tsk->fs stuff.

Details of the vfsmount: from include/linux/mount.h:
struct vfsmount
{
	struct list_head mnt_hash;
	struct vfsmount *mnt_parent;    /* fs we are mounted on */
	struct dentry *mnt_mountpoint;  /* dentry of mountpoint */
	struct dentry *mnt_root;        /* root of the mounted tree */
	struct super_block *mnt_sb;     /* pointer to superblock */
	struct list_head mnt_mounts;    /* list of children, anchored here */
	struct list_head mnt_child;     /* and going through their mnt_child */
	atomic_t mnt_count;
	int mnt_flags;
	char *mnt_devname;              /* Name of device e.g. /dev/dsk/hda1 */
	struct list_head mnt_list;
};

there's also mntget and mntput, which (in the case where the reference count
goes to zero), dput's mnt_root, free_vfsmnt(mnt) (free mnt_devname, mnt),
deactivate_super(mnt_sb) (confusing, but basically another put)

Note that the dentry of the root of a filesystem has a d_parent pointer that
just points to itself--so to traverse up you again need to know where you are
in the vfsmount tree.

sys_mount
^^^^^^^^^

First, sys_mount() itself just copies arguments from the user, then calls
do_mount() (under BKL) to do the real work.  After some sanity checks and
stuff, do_mount() calls path_lookup() to resolve the path.  The remaining work
is done by either do_remount, do_loopback (the --bind case), do_move_mount, or
do_add_mount():

do_remount doesn't interest me at the moment.

do_loopback (which I'm assuming for now is called with recurse == 0) calls
path_lookup to get the path we're mount --bind'ing.  It takes a lock on
current->namespace->sem, then calls check_mnt() on the vfsmounts on both paths,
which checks that the target vfsmount is still attached to the current
namespace (I assume to rule out the possibility that something's been unmounted
since we first looked them up), then runs clone_mnt(), which returns a new
vfsmount holding a reference to the old mount's superblock and to the dentry
that the new vfsmount will be rooted at, and whose mnt_parent temporarily
points to itself, and mnt_root points to the source dentry.  Then it calls
graft_tree(), which inserts the new mount into the tree at the location given
by "nd" as follows:
	First, it downs nd->dentry->d_inode->i_sem, and checks that the inode
		is still good (by checking for IS_DEADDIR());
	Then it takes the vfsmount_lock, and makes sure the dentry is either
		a root dentry or is hashed.
	Then it calls attach_mnt(mnt, nd), which sets mnt's mnt_parent (taking
		a reference), mnt_mountpoint to the dentry we're mounting on,
		adds mnt to the mount_hashtable (hashed on the target mount
		and dentry), and to the list of the target mount's children,
		and finally increments the target dentry's d_mounted.
	Finally, graft_tree() adds the new mnt to a list of all mnt's in
		the namespace (which is used to generate /proc/mounts).

lookup_mount: given a mnt and a dentry, uses the mount_hashtable to return
something that is mounted under mnt at that dentry.

follow_down: given a **mnt and **dentry, replace **mnt and **dentry by results
of lookup_mnt (and mnt_root of that), if found; return 0 and leave unchanged
otherwise.

follow_up: goes in the other direction, replacing mount by mnt_parent and
dentry by mnt_mountpoint.

(I find the terminology a bit backwards here as I imagine mounts as being
stacked "on top" of the underlying mountpoints.)

follow_mount: same as follow_down, but continues until it gets to something
that isn't a mountpoint.  Seems to be called at every step of a path lookup
(see link_path_walk).