30 files changed, 1190 insertions, 459 deletions
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX
index 4303614b5add..8c624a18f67d 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -96,8 +96,6 @@ seq_file.txt
        - how to use the seq_file API
 sharedsubtree.txt
        - a description of shared subtrees for namespaces.
-smbfs.txt
-        - info on using filesystems with the SMB protocol (Win 3.11 and NT).
 spufs.txt
        - info and mount options for the SPU filesystem used on Cell.
 sysfs-pci.txt
diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt
index f9765e8cf086..b22abba78fed 100644
--- a/Documentation/filesystems/9p.txt
+++ b/Documentation/filesystems/9p.txt
@@ -111,7 +111,7 @@ OPTIONS
                This can be used to share devices/named pipes/sockets between
                hosts.  This functionality will be expanded in later versions.
-  access        there are three access modes.
+  access        there are four access modes.
                        user  = if a user tries to access a file on v9fs
                                filesystem for the first time, v9fs sends an
                                attach command (Tattach) for that user.
@@ -120,6 +120,8 @@ OPTIONS
                                the files on the mounted filesystem
                        any   = v9fs does single attach and performs all
                                operations as one user
+                        client = ACL based access check on the 9p client
+                                 side for access validation
  cachetag      cache tag to use the specified persistent cache.
                cache tags for existing cache sessions can be listed at
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 2db4283efa8d..61b31acb9176 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -9,24 +9,30 @@ be able to use diff(1).
 --------------------------- dentry_operations --------------------------
 prototypes:
-        int (*d_revalidate)(struct dentry *, int);
+        int (*d_revalidate)(struct dentry *, struct nameidata *);
-        int (*d_hash) (struct dentry *, struct qstr *);
+        int (*d_hash)(const struct dentry *, const struct inode *,
-        int (*d_compare) (struct dentry *, struct qstr *, struct qstr *);
+                        struct qstr *);
+        int (*d_compare)(const struct dentry *, const struct inode *,
+                        const struct dentry *, const struct inode *,
+                        unsigned int, const char *, const struct qstr *);
        int (*d_delete)(struct dentry *);
        void (*d_release)(struct dentry *);
        void (*d_iput)(struct dentry *, struct inode *);
        char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
+        struct vfsmount *(*d_automount)(struct path *path);
+        int (*d_manage)(struct dentry *, bool);
 locking rules:
-        none have BKL
+                rename_lock     ->d_lock        may block       rcu-walk
-                dcache_lock     rename_lock     ->d_lock        may block
+d_revalidate:   no              no              yes (ref-walk)  maybe
-d_revalidate:   no              no              no              yes
+d_hash          no              no              no              maybe
-d_hash          no              no              no              yes
+d_compare:      yes             no              no              maybe
-d_compare:      no              yes             no              no 
+d_delete:       no              yes             no              no
-d_delete:       yes             no              yes             no
+d_release:      no              no              yes             no
-d_release:      no              no              no              yes
+d_iput:         no              no              yes             no
-d_iput:         no              no              no              yes
 d_dname:        no              no              no              no
+d_automount:    no              no              yes             no
+d_manage:       no              no              yes (ref-walk)  maybe
 --------------------------- inode_operations --------------------------- 
 prototypes:
@@ -42,18 +48,22 @@ ata *);
        int (*rename) (struct inode *, struct dentry *,
                        struct inode *, struct dentry *);
        int (*readlink) (struct dentry *, char __user *,int);
-        int (*follow_link) (struct dentry *, struct nameidata *);
+        void * (*follow_link) (struct dentry *, struct nameidata *);
+        void (*put_link) (struct dentry *, struct nameidata *, void *);
        void (*truncate) (struct inode *);
-        int (*permission) (struct inode *, int, struct nameidata *);
+        int (*permission) (struct inode *, int, unsigned int);
+        int (*check_acl)(struct inode *, int, unsigned int);
        int (*setattr) (struct dentry *, struct iattr *);
        int (*getattr) (struct vfsmount *, struct dentry *, struct kstat *);
        int (*setxattr) (struct dentry *, const char *,const void *,size_t,int);
        ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);
        ssize_t (*listxattr) (struct dentry *, char *, size_t);
        int (*removexattr) (struct dentry *, const char *);
+        void (*truncate_range)(struct inode *, loff_t, loff_t);
+        int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len);
 locking rules:
-        all may block, none have BKL
+        all may block
                i_mutex(inode)
 lookup:         yes
 create:         yes
@@ -66,19 +76,23 @@ rmdir:		yes (both)	(see below)
 rename:         yes (all)       (see below)
 readlink:       no
 follow_link:    no
+put_link:       no
 truncate:       yes             (see below)
 setattr:        yes
-permission:     no
+permission:     no (may not block if called in rcu-walk mode)
+check_acl:      no
 getattr:        no
 setxattr:       yes
 getxattr:       no
 listxattr:      no
 removexattr:    yes
+truncate_range: yes
+fiemap:         no
        Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
 victim.
        cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
        ->truncate() is never called directly - it's a callback, not a
-method. It's called by vmtruncate() - library function normally used by
+method. It's called by vmtruncate() - deprecated library function used by
 ->setattr(). Locking information above applies to that call (i.e. is
 inherited from ->setattr() - vmtruncate() is used when ATTR_SIZE had been
 passed).
@@ -91,7 +105,7 @@ prototypes:
        struct inode *(*alloc_inode)(struct super_block *sb);
        void (*destroy_inode)(struct inode *);
        void (*dirty_inode) (struct inode *);
-        int (*write_inode) (struct inode *, int);
+        int (*write_inode) (struct inode *, struct writeback_control *wbc);
        int (*drop_inode) (struct inode *);
        void (*evict_inode) (struct inode *);
        void (*put_super) (struct super_block *);
@@ -105,16 +119,16 @@ prototypes:
        int (*show_options)(struct seq_file *, struct vfsmount *);
        ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
        ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
+        int (*bdev_try_to_free_page)(struct super_block*, struct page*, gfp_t);
 locking rules:
        All may block [not true, see below]
-        None have BKL
                        s_umount
 alloc_inode:
 destroy_inode:
 dirty_inode:                            (must not sleep)
 write_inode:
-drop_inode:                             !!!inode_lock!!!
+drop_inode:                             !!!inode->i_lock!!!
 evict_inode:
 put_super:              write
 write_super:            read
@@ -127,6 +141,7 @@ umount_begin:		no
 show_options:           no              (namespace_sem)
 quota_read:             no              (see below)
 quota_write:            no              (see below)
+bdev_try_to_free_page:  no              (see below)
 ->statfs() has s_umount (shared) when called by ustat(2) (native or
 compat), but that's an accident of bad API; s_umount is used to pin
@@ -139,19 +154,23 @@ be the only ones operating on the quota file by the quota code (via
 dqio_sem) (unless an admin really wants to screw up something and
 writes to quota files with quotas on). For other details about locking
 see also dquot_operations section.
+->bdev_try_to_free_page is called from the ->releasepage handler of
+the block device inode.  See there for more details.
 --------------------------- file_system_type ---------------------------
 prototypes:
        int (*get_sb) (struct file_system_type *, int,
                       const char *, void *, struct vfsmount *);
+        struct dentry *(*mount) (struct file_system_type *, int,
+                       const char *, void *);
        void (*kill_sb) (struct super_block *);
 locking rules:
-                may block       BKL
+                may block
-get_sb          yes             no
+mount           yes
-kill_sb         yes             no
+kill_sb         yes
->get_sb() returns error or 0 with locked superblock attached to the vfsmount
+->mount() returns ERR_PTR or the root dentry; its superblock should be locked
-(exclusive on ->s_umount).
+on return.
 ->kill_sb() takes a write-locked superblock, does all shutdown work on it,
 unlocks and drops the reference.
@@ -173,28 +192,38 @@ prototypes:
        sector_t (*bmap)(struct address_space *, sector_t);
        int (*invalidatepage) (struct page *, unsigned long);
        int (*releasepage) (struct page *, int);
+        void (*freepage)(struct page *);
        int (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
                        loff_t offset, unsigned long nr_segs);
-        int (*launder_page) (struct page *);
+        int (*get_xip_mem)(struct address_space *, pgoff_t, int, void **,
+                                unsigned long *);
+        int (*migratepage)(struct address_space *, struct page *, struct page *);
+        int (*launder_page)(struct page *);
+        int (*is_partially_uptodate)(struct page *, read_descriptor_t *, unsigned long);
+        int (*error_remove_page)(struct address_space *, struct page *);
 locking rules:
-        All except set_page_dirty may block
+        All except set_page_dirty and freepage may block
-                        BKL     PageLocked(page)        i_mutex
+                        PageLocked(page)        i_mutex
-writepage:              no      yes, unlocks (see below)
+writepage:              yes, unlocks (see below)
-readpage:               no      yes, unlocks
+readpage:               yes, unlocks
-sync_page:              no      maybe
+sync_page:              maybe
-writepages:             no
+writepages:
-set_page_dirty          no      no
+set_page_dirty          no
-readpages:              no
+readpages:
-write_begin:            no      locks the page          yes
+write_begin:            locks the page          yes
-write_end:              no      yes, unlocks            yes
+write_end:              yes, unlocks            yes
-perform_write:          no      n/a                     yes
+bmap:
-bmap:                   no
+invalidatepage:         yes
-invalidatepage:         no      yes
+releasepage:            yes
-releasepage:            no      yes
+freepage:               yes
-direct_IO:              no
+direct_IO:
-launder_page:           no      yes
+get_xip_mem:                                    maybe
+migratepage:            yes (both)
+launder_page:           yes
+is_partially_uptodate:  yes
+error_remove_page:      yes
        ->write_begin(), ->write_end(), ->sync_page() and ->readpage()
 may be called from the request handler (/dev/loop).
@@ -274,9 +303,8 @@ under spinlock (it cannot block) and is sometimes called with the page
 not locked.
        ->bmap() is currently used by legacy ioctl() (FIBMAP) provided by some
-filesystems and by the swapper. The latter will eventually go away. All
+filesystems and by the swapper. The latter will eventually go away.  Please,
-instances do not actually need the BKL. Please, keep it that way and don't
+keep it that way and don't breed new callers.
-breed new callers.
        ->invalidatepage() is called when the filesystem must attempt to drop
 some or all of the buffers from the page when it is being truncated.  It
@@ -288,55 +316,44 @@ buffers from the page in preparation for freeing it.  It returns zero to
 indicate that the buffers are (or may be) freeable.  If ->releasepage is zero,
 the kernel assumes that the fs has no private interest in the buffers.
+        ->freepage() is called when the kernel is done dropping the page
+from the page cache.
        ->launder_page() may be called prior to releasing a page if
 it is still found to be dirty. It returns zero if the page was successfully
 cleaned, or an error value if not. Note that in order to prevent the page
 getting mapped back in and redirtied, it needs to be kept locked
 across the entire operation.
-        Note: currently almost all instances of address_space methods are
-using BKL for internal serialization and that's one of the worst sources
-of contention. Normally they are calling library functions (in fs/buffer.c)
-and pass foo_get_block() as a callback (on local block-based filesystems,
-indeed). BKL is not needed for library stuff and is usually taken by
-foo_get_block(). It's an overkill, since block bitmaps can be protected by
-internal fs locking and real critical areas are much smaller than the areas
-filesystems protect now.
 ----------------------- file_lock_operations ------------------------------
 prototypes:
-        void (*fl_insert)(struct file_lock *);  /* lock insertion callback */
-        void (*fl_remove)(struct file_lock *);  /* lock removal callback */
        void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
        void (*fl_release_private)(struct file_lock *);
 locking rules:
-                        BKL     may block
+                        file_lock_lock  may block
-fl_insert:              yes     no
+fl_copy_lock:           yes             no
-fl_remove:              yes     no
+fl_release_private:     maybe           no
-fl_copy_lock:           yes     no
-fl_release_private:     yes     yes
 ----------------------- lock_manager_operations ---------------------------
 prototypes:
        int (*fl_compare_owner)(struct file_lock *, struct file_lock *);
        void (*fl_notify)(struct file_lock *);  /* unblock callback */
-        void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
+        int (*fl_grant)(struct file_lock *, struct file_lock *, int);
        void (*fl_release_private)(struct file_lock *);
        void (*fl_break)(struct file_lock *); /* break_lease callback */
+        int (*fl_change)(struct file_lock **, int);
 locking rules:
-                        BKL     may block
+                        file_lock_lock  may block
-fl_compare_owner:       yes     no
+fl_compare_owner:       yes             no
-fl_notify:              yes     no
+fl_notify:              yes             no
-fl_copy_lock:           yes     no
+fl_grant:               no              no
-fl_release_private:     yes     yes
+fl_release_private:     maybe           no
-fl_break:               yes     no
+fl_break:               yes             no
+fl_change               yes             no
-        Currently only NFSD and NLM provide instances of this class. None of the
-them block. If you have out-of-tree instances - please, show up. Locking
-in that area will change.
 --------------------------- buffer_head -----------------------------------
 prototypes:
        void (*b_end_io)(struct buffer_head *bh, int uptodate);
@@ -349,21 +366,36 @@ call this method upon the IO completion.
 --------------------------- block_device_operations -----------------------
 prototypes:
-        int (*open) (struct inode *, struct file *);
+        int (*open) (struct block_device *, fmode_t);
-        int (*release) (struct inode *, struct file *);
+        int (*release) (struct gendisk *, fmode_t);
-        int (*ioctl) (struct inode *, struct file *, unsigned, unsigned long);
+        int (*ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
+        int (*compat_ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
+        int (*direct_access) (struct block_device *, sector_t, void **, unsigned long *);
        int (*media_changed) (struct gendisk *);
+        void (*unlock_native_capacity) (struct gendisk *);
        int (*revalidate_disk) (struct gendisk *);
+        int (*getgeo)(struct block_device *, struct hd_geometry *);
+        void (*swap_slot_free_notify) (struct block_device *, unsigned long);
 locking rules:
-                        BKL     bd_sem
+                        bd_mutex
-open:                   yes     yes
+open:                   yes
-release:                yes     yes
+release:                yes
-ioctl:                  yes     no
+ioctl:                  no
-media_changed:          no      no
+compat_ioctl:           no
-revalidate_disk:        no      no
+direct_access:          no
+media_changed:          no
+unlock_native_capacity: no
+revalidate_disk:        no
+getgeo:                 no
+swap_slot_free_notify:  no      (see below)
+media_changed, unlock_native_capacity and revalidate_disk are called only from
+check_disk_change().
+swap_slot_free_notify is called with swap_lock and sometimes the page lock
+held.
-The last two are called only from check_disk_change().
 --------------------------- file_operations -------------------------------
 prototypes:
@@ -395,34 +427,22 @@ prototypes:
        unsigned long (*get_unmapped_area)(struct file *, unsigned long,
                        unsigned long, unsigned long, unsigned long);
        int (*check_flags)(int);
+        int (*flock) (struct file *, int, struct file_lock *);
+        ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *,
+                        size_t, unsigned int);
+        ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *,
+                        size_t, unsigned int);
+        int (*setlease)(struct file *, long, struct file_lock **);
+        long (*fallocate)(struct file *, int, loff_t, loff_t);
 };
 locking rules:
-        All may block.
+        All may block except for ->setlease.
-                        BKL
+        No VFS locks held on entry except for ->fsync and ->setlease.
-llseek:                 no      (see below)
-read:                   no
+->fsync() has i_mutex on inode.
-aio_read:               no
-write:                  no
+->setlease has the file_list_lock held and must not sleep.
-aio_write:              no
-readdir:                no
-poll:                   no
-unlocked_ioctl:         no
-compat_ioctl:           no
-mmap:                   no
-open:                   no
-flush:                  no
-release:                no
-fsync:                  no      (see below)
-aio_fsync:              no
-fasync:                 no
-lock:                   yes
-readv:                  no
-writev:                 no
-sendfile:               no
-sendpage:               no
-get_unmapped_area:      no
-check_flags:            no
 ->llseek() locking has moved from llseek to the individual llseek
 implementations.  If your fs is not using generic_file_llseek, you
@@ -432,17 +452,10 @@ mutex or just to use i_size_read() instead.
 Note: this does not protect the file->f_pos against concurrent modifications
 since this is something the userspace has to take care about.
-Note: ext2_release() was *the* source of contention on fs-intensive
+->fasync() is responsible for maintaining the FASYNC bit in filp->f_flags.
-loads and dropping BKL on ->release() helps to get rid of that (we still
+Most instances call fasync_helper(), which does that maintenance, so it's
-grab BKL for cases when we close a file that had been opened r/w, but that
+not normally something one needs to worry about.  Return values > 0 will be
-can and should be done using the internal locking with smaller critical areas).
+mapped to zero in the VFS layer.
-Current worst offender is ext2_get_block()...
->fasync() is called without BKL protection, and is responsible for
-maintaining the FASYNC bit in filp->f_flags.  Most instances call
-fasync_helper(), which does that maintenance, so it's not normally
-something one needs to worry about.  Return values > 0 will be mapped to
-zero in the VFS layer.
 ->readdir() and ->ioctl() on directories must be changed. Ideally we would
 move ->readdir() to inode_operations and use a separate method for directory
@@ -453,8 +466,6 @@ components. And there are other reasons why the current interface is a mess...
 ->read on directories probably must go away - we should just enforce -EISDIR
 in sys_read() and friends.
->fsync() has i_mutex on inode.
 --------------------------- dquot_operations -------------------------------
 prototypes:
        int (*write_dquot) (struct dquot *);
@@ -489,12 +500,12 @@ prototypes:
        int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
 locking rules:
-                BKL     mmap_sem        PageLocked(page)
+                mmap_sem        PageLocked(page)
-open:           no      yes
+open:           yes
-close:          no      yes
+close:          yes
-fault:          no      yes             can return with page locked
+fault:          yes             can return with page locked
-page_mkwrite:   no      yes             can return with page locked
+page_mkwrite:   yes             can return with page locked
-access:         no      yes
+access:         yes
        ->fault() is called when a previously not present pte is about
 to be faulted in. The filesystem must find and return the page associated
@@ -521,6 +532,3 @@ VM_IO | VM_PFNMAP VMAs.
 (if you break something or notice that it is broken and do not fix it yourself
 - at least put it here)
-ipc/shm.c::shm_delete() - may need BKL.
->read() and ->write() in many drivers are (probably) missing BKL.
diff --git a/Documentation/filesystems/adfs.txt b/Documentation/filesystems/adfs.txt
index 9e8811f92b84..5949766353f7 100644
--- a/Documentation/filesystems/adfs.txt
+++ b/Documentation/filesystems/adfs.txt
@@ -9,6 +9,9 @@ Mount options for ADFS
                will be nnn.  Default 0700.
  othmask=nnn   The permission mask for ADFS 'other' permissions
                will be nnn.  Default 0077.
+  ftsuffix=n    When ftsuffix=0, no file type suffix will be applied.
+                When ftsuffix=1, a hexadecimal suffix corresponding to
+                the RISC OS file type will be added.  Default 0.
 Mapping of ADFS permissions to Linux permissions
 ------------------------------------------------
@@ -55,3 +58,18 @@ Mapping of ADFS permissions to Linux permissions
  You can therefore tailor the permission translation to whatever you
  desire the permissions should be under Linux.
+RISC OS file type suffix
+------------------------
+  RISC OS file types are stored in bits 19..8 of the file load address.
+  To enable non-RISC OS systems to be used to store files without losing
+  file type information, a file naming convention was devised (initially
+  for use with NFS) such that a hexadecimal suffix of the form ,xyz
+  denoted the file type: e.g. BasicFile,ffb is a BASIC (0xffb) file.  This
+  naming convention is now also used by RISC OS emulators such as RPCEmu.
+  Mounting an ADFS disc with option ftsuffix=1 will cause appropriate file
+  type suffixes to be appended to file names read from a directory.  If the
+  ftsuffix option is zero or omitted, no file type suffixes will be added.
diff --git a/Documentation/filesystems/autofs4-mount-control.txt b/Documentation/filesystems/autofs4-mount-control.txt
index 51986bf08a4d..4c95935cbcf4 100644
--- a/Documentation/filesystems/autofs4-mount-control.txt
+++ b/Documentation/filesystems/autofs4-mount-control.txt
@@ -309,7 +309,7 @@ ioctlfd field set to the descriptor obtained from the open call.
 AUTOFS_DEV_IOCTL_TIMEOUT_CMD
 ----------------------------
-Set the expire timeout for mounts withing an autofs mount point.
+Set the expire timeout for mounts within an autofs mount point.
 The call requires an initialized struct autofs_dev_ioctl with the
 ioctlfd field set to the descriptor obtained from the open call.
diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt
index 1902c57b72ef..a167ab876c35 100644
--- a/Documentation/filesystems/caching/netfs-api.txt
+++ b/Documentation/filesystems/caching/netfs-api.txt
@@ -95,7 +95,7 @@ restraints as possible on how an index is structured and where it is placed in
 the tree.  The netfs can even mix indices and data files at the same level, but
 it's not recommended.
-Each index entry consists of a key of indeterminate length plus some auxilliary
+Each index entry consists of a key of indeterminate length plus some auxiliary
 data, also of indeterminate length.
 There are some limits on indices:
@@ -203,23 +203,23 @@ This has the following fields:
     If the function is absent, a file size of 0 is assumed.
- (6) A function to retrieve auxilliary data from the netfs [optional].
+ (6) A function to retrieve auxiliary data from the netfs [optional].
     This function will be called with the netfs data that was passed to the
-     cookie acquisition function and the maximum length of auxilliary data that
+     cookie acquisition function and the maximum length of auxiliary data that
-     it may provide.  It should write the auxilliary data into the given buffer
+     it may provide.  It should write the auxiliary data into the given buffer
     and return the quantity it wrote.
-     If this function is absent, the auxilliary data length will be set to 0.
+     If this function is absent, the auxiliary data length will be set to 0.
-     The length of the auxilliary data buffer may be dependent on the key
+     The length of the auxiliary data buffer may be dependent on the key
     length.  A netfs mustn't rely on being able to provide more than 400 bytes
     for both.
- (7) A function to check the auxilliary data [optional].
+ (7) A function to check the auxiliary data [optional].
     This function will be called to check that a match found in the cache for
-     this object is valid.  For instance with AFS it could check the auxilliary
+     this object is valid.  For instance with AFS it could check the auxiliary
     data against the data version number returned by the server to determine
     whether the index entry in a cache is still valid.
@@ -232,7 +232,7 @@ This has the following fields:
        (*) FSCACHE_CHECKAUX_NEEDS_UPDATE       - the entry requires update
        (*) FSCACHE_CHECKAUX_OBSOLETE           - the entry should be deleted
-     This function can also be used to extract data from the auxilliary data in
+     This function can also be used to extract data from the auxiliary data in
     the cache and copy it into the netfs's structures.
 (8) A pair of functions to manage contexts for the completion callback
diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt
index fabcb0e00f25..dd57bb6bb390 100644
--- a/Documentation/filesystems/configfs/configfs.txt
+++ b/Documentation/filesystems/configfs/configfs.txt
@@ -409,7 +409,7 @@ As a consequence of this, default_groups cannot be removed directly via
 rmdir(2).  They also are not considered when rmdir(2) on the parent
 group is checking for children.
-[Dependant Subsystems]
+[Dependent Subsystems]
 Sometimes other drivers depend on particular configfs items.  For
 example, ocfs2 mounts depend on a heartbeat region item.  If that
diff --git a/Documentation/filesystems/configfs/configfs_example_explicit.c b/Documentation/filesystems/configfs/configfs_example_explicit.c
index d428cc9f07f3..fd53869f5633 100644
--- a/Documentation/filesystems/configfs/configfs_example_explicit.c
+++ b/Documentation/filesystems/configfs/configfs_example_explicit.c
@@ -89,7 +89,7 @@ static ssize_t childless_storeme_write(struct childless *childless,
        char *p = (char *) page;
        tmp = simple_strtoul(p, &p, 10);
-        if (!p || (*p && (*p != '\n')))
+        if ((*p != '\0') && (*p != '\n'))
                return -EINVAL;
        if (tmp > INT_MAX)
diff --git a/Documentation/filesystems/dentry-locking.txt b/Documentation/filesystems/dentry-locking.txt
deleted file mode 100644
index 79334ed5daa7..000000000000
--- a/Documentation/filesystems/dentry-locking.txt
+++ /dev/null
@@ -1,174 +0,0 @@
-RCU-based dcache locking model
-==============================
-On many workloads, the most common operation on dcache is to look up a
-dentry, given a parent dentry and the name of the child. Typically,
-for every open(), stat() etc., the dentry corresponding to the
-pathname will be looked up by walking the tree starting with the first
-component of the pathname and using that dentry along with the next
-component to look up the next level and so on. Since it is a frequent
-operation for workloads like multiuser environments and web servers,
-it is important to optimize this path.
-Prior to 2.5.10, dcache_lock was acquired in d_lookup and thus in
-every component during path look-up. Since 2.5.10 onwards, fast-walk
-algorithm changed this by holding the dcache_lock at the beginning and
-walking as many cached path component dentries as possible. This
-significantly decreases the number of acquisition of
-dcache_lock. However it also increases the lock hold time
-significantly and affects performance in large SMP machines. Since
-2.5.62 kernel, dcache has been using a new locking model that uses RCU
-to make dcache look-up lock-free.
-The current dcache locking model is not very different from the
-existing dcache locking model. Prior to 2.5.62 kernel, dcache_lock
-protected the hash chain, d_child, d_alias, d_lru lists as well as
-d_inode and several other things like mount look-up. RCU-based changes
-affect only the way the hash chain is protected. For everything else
-the dcache_lock must be taken for both traversing as well as
-updating. The hash chain updates too take the dcache_lock.  The
-significant change is the way d_lookup traverses the hash chain, it
-doesn't acquire the dcache_lock for this and rely on RCU to ensure
-that the dentry has not been *freed*.
-Dcache locking details
-======================
-For many multi-user workloads, open() and stat() on files are very
-frequently occurring operations. Both involve walking of path names to
-find the dentry corresponding to the concerned file. In 2.4 kernel,
-dcache_lock was held during look-up of each path component. Contention
-and cache-line bouncing of this global lock caused significant
-scalability problems. With the introduction of RCU in Linux kernel,
-this was worked around by making the look-up of path components during
-path walking lock-free.
-Safe lock-free look-up of dcache hash table
-===========================================
-Dcache is a complex data structure with the hash table entries also
-linked together in other lists. In 2.4 kernel, dcache_lock protected
-all the lists. We applied RCU only on hash chain walking. The rest of
-the lists are still protected by dcache_lock.  Some of the important
-changes are :
-1. The deletion from hash chain is done using hlist_del_rcu() macro
-   which doesn't initialize next pointer of the deleted dentry and
-   this allows us to walk safely lock-free while a deletion is
-   happening.
-2. Insertion of a dentry into the hash table is done using
-   hlist_add_head_rcu() which take care of ordering the writes - the
-   writes to the dentry must be visible before the dentry is
-   inserted. This works in conjunction with hlist_for_each_rcu(),
-   which has since been replaced by hlist_for_each_entry_rcu(), while
-   walking the hash chain. The only requirement is that all
-   initialization to the dentry must be done before
-   hlist_add_head_rcu() since we don't have dcache_lock protection
-   while traversing the hash chain. This isn't different from the
-   existing code.
-3. The dentry looked up without holding dcache_lock by cannot be
-   returned for walking if it is unhashed. It then may have a NULL
-   d_inode or other bogosity since RCU doesn't protect the other
-   fields in the dentry. We therefore use a flag DCACHE_UNHASHED to
-   indicate unhashed dentries and use this in conjunction with a
-   per-dentry lock (d_lock). Once looked up without the dcache_lock,
-   we acquire the per-dentry lock (d_lock) and check if the dentry is
-   unhashed. If so, the look-up is failed. If not, the reference count
-   of the dentry is increased and the dentry is returned.
-4. Once a dentry is looked up, it must be ensured during the path walk
-   for that component it doesn't go away. In pre-2.5.10 code, this was
-   done holding a reference to the dentry. dcache_rcu does the same.
-   In some sense, dcache_rcu path walking looks like the pre-2.5.10
-   version.
-5. All dentry hash chain updates must take the dcache_lock as well as
-   the per-dentry lock in that order. dput() does this to ensure that
-   a dentry that has just been looked up in another CPU doesn't get
-   deleted before dget() can be done on it.
-6. There are several ways to do reference counting of RCU protected
-   objects. One such example is in ipv4 route cache where deferred
-   freeing (using call_rcu()) is done as soon as the reference count
-   goes to zero. This cannot be done in the case of dentries because
-   tearing down of dentries require blocking (dentry_iput()) which
-   isn't supported from RCU callbacks. Instead, tearing down of
-   dentries happen synchronously in dput(), but actual freeing happens
-   later when RCU grace period is over. This allows safe lock-free
-   walking of the hash chains, but a matched dentry may have been
-   partially torn down. The checking of DCACHE_UNHASHED flag with
-   d_lock held detects such dentries and prevents them from being
-   returned from look-up.
-Maintaining POSIX rename semantics
-==================================
-Since look-up of dentries is lock-free, it can race against a
-concurrent rename operation. For example, during rename of file A to
-B, look-up of either A or B must succeed.  So, if look-up of B happens
-after A has been removed from the hash chain but not added to the new
-hash chain, it may fail.  Also, a comparison while the name is being
-written concurrently by a rename may result in false positive matches
-violating rename semantics.  Issues related to race with rename are
-handled as described below :
-1. Look-up can be done in two ways - d_lookup() which is safe from
-   simultaneous renames and __d_lookup() which is not.  If
-   __d_lookup() fails, it must be followed up by a d_lookup() to
-   correctly determine whether a dentry is in the hash table or
-   not. d_lookup() protects look-ups using a sequence lock
-   (rename_lock).
-2. The name associated with a dentry (d_name) may be changed if a
-   rename is allowed to happen simultaneously. To avoid memcmp() in
-   __d_lookup() go out of bounds due to a rename and false positive
-   comparison, the name comparison is done while holding the
-   per-dentry lock. This prevents concurrent renames during this
-   operation.
-3. Hash table walking during look-up may move to a different bucket as
-   the current dentry is moved to a different bucket due to rename.
-   But we use hlists in dcache hash table and they are
-   null-terminated.  So, even if a dentry moves to a different bucket,
-   hash chain walk will terminate. [with a list_head list, it may not
-   since termination is when the list_head in the original bucket is
-   reached].  Since we redo the d_parent check and compare name while
-   holding d_lock, lock-free look-up will not race against d_move().
-4. There can be a theoretical race when a dentry keeps coming back to
-   original bucket due to double moves. Due to this look-up may
-   consider that it has never moved and can end up in a infinite loop.
-   But this is not any worse that theoretical livelocks we already
-   have in the kernel.
-Important guidelines for filesystem developers related to dcache_rcu
-====================================================================
-1. Existing dcache interfaces (pre-2.5.62) exported to filesystem
-   don't change. Only dcache internal implementation changes. However
-   filesystems *must not* delete from the dentry hash chains directly
-   using the list macros like allowed earlier. They must use dcache
-   APIs like d_drop() or __d_drop() depending on the situation.
-2. d_flags is now protected by a per-dentry lock (d_lock). All access
-   to d_flags must be protected by it.
-3. For a hashed dentry, checking of d_count needs to be protected by
-   d_lock.
-Papers and other documentation on dcache locking
-================================================
-1. Scaling dcache with RCU (http://linuxjournal.com/article.php?sid=7124).
-2. http://lse.sourceforge.net/locking/dcache/dcache.html
diff --git a/Documentation/filesystems/exofs.txt b/Documentation/filesystems/exofs.txt
index abd2a9b5b787..23583a136975 100644
--- a/Documentation/filesystems/exofs.txt
+++ b/Documentation/filesystems/exofs.txt
@@ -104,7 +104,15 @@ Where:
    exofs specific options: Options are separated by commas (,)
                pid=<integer> - The partition number to mount/create as
                                container of the filesystem.
-                                This option is mandatory.
+                                This option is mandatory. integer can be
+                                Hex by pre-pending an 0x to the number.
+                osdname=<id>  - Mount by a device's osdname.
+                                osdname is usually a 36 character uuid of the
+                                form "d2683732-c906-4ee1-9dbd-c10c27bb40df".
+                                It is one of the device's uuid specified in the
+                                mkfs.exofs format command.
+                                If this option is specified then the /dev/osdX
+                                above can be empty and is ignored.
                to=<integer>  - Timeout in ticks for a single command.
                                default is (60 * HZ) [for debugging only]
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt
index e1def1786e50..c79ec58fd7f6 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -97,7 +97,7 @@ Note: More extensive information for getting started with ext4 can be
 * Inode allocation using large virtual block groups via flex_bg
 * delayed allocation
 * large block (up to pagesize) support
-* efficent new ordered mode in JBD2 and ext4(avoid using buffer head to force
+* efficient new ordered mode in JBD2 and ext4(avoid using buffer head to force
  the ordering)
 [1] Filesystems with a block size of 1k may see a limit imposed by the
@@ -106,7 +106,7 @@ directory hash tree having a maximum depth of two.
 2.2 Candidate features for future inclusion
 * Online defrag (patches available but not well tested)
-* reduced mke2fs time via lazy itable initialization in conjuction with
+* reduced mke2fs time via lazy itable initialization in conjunction with
  the uninit_bg feature (capability to do this is available in e2fsprogs
  but a kernel thread to do lazy zeroing of unused inode table blocks
  after filesystem is first mounted is required for safety)
@@ -353,12 +353,61 @@ noauto_da_alloc		replacing existing files via patterns such as
                        system crashes before the delayed allocation
                        blocks are forced to disk.
-discard         Controls whether ext4 should issue discard/TRIM
+noinit_itable           Do not initialize any uninitialized inode table
+                        blocks in the background.  This feature may be
+                        used by installation CD's so that the install
+                        process can complete as quickly as possible; the
+                        inode table initialization process would then be
+                        deferred until the next time the  file system
+                        is unmounted.
+init_itable=n           The lazy itable init code will wait n times the
+                        number of milliseconds it took to zero out the
+                        previous block group's inode table.  This
+                        minimizes the impact on the systme performance
+                        while file system's inode table is being initialized.
+discard                 Controls whether ext4 should issue discard/TRIM
 nodiscard(*)            commands to the underlying block device when
                        blocks are freed.  This is useful for SSD devices
                        and sparse/thinly-provisioned LUNs, but it is off
                        by default until sufficient testing has been done.
+nouid32                 Disables 32-bit UIDs and GIDs.  This is for
+                        interoperability  with  older kernels which only
+                        store and expect 16-bit values.
+resize                  Allows to resize filesystem to the end of the last
+                        existing block group, further resize has to be done
+                        with resize2fs either online, or offline. It can be
+                        used only with conjunction with remount.
+block_validity          This options allows to enables/disables the in-kernel
+noblock_validity        facility for tracking filesystem metadata blocks
+                        within internal data structures. This allows multi-
+                        block allocator and other routines to quickly locate
+                        extents which might overlap with filesystem metadata
+                        blocks. This option is intended for debugging
+                        purposes and since it negatively affects the
+                        performance, it is off by default.
+dioread_lock            Controls whether or not ext4 should use the DIO read
+dioread_nolock          locking. If the dioread_nolock option is specified
+                        ext4 will allocate uninitialized extent before buffer
+                        write and convert the extent to initialized after IO
+                        completes. This approach allows ext4 code to avoid
+                        using inode mutex, which improves scalability on high
+                        speed storages. However this does not work with nobh
+                        option and the mount will fail. Nor does it work with
+                        data journaling and dioread_nolock option will be
+                        ignored with kernel warning. Note that dioread_nolock
+                        code path is only used for extent-based files.
+                        Because of the restrictions this options comprises
+                        it is off by default (e.g. dioread_lock).
+i_version               Enable 64-bit inode version support. This option is
+                        off by default.
 Data Mode
 =========
 There are 3 different data modes:
@@ -386,6 +435,176 @@ needs to be read from and written to disk at the same time where it
 outperforms all others modes.  Currently ext4 does not have delayed
 allocation support if this data journalling mode is selected.
+/proc entries
+=============
+Information about mounted ext4 file systems can be found in
+/proc/fs/ext4.  Each mounted filesystem will have a directory in
+/proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or
+/proc/fs/ext4/dm-0).   The files in each per-device directory are shown
+in table below.
+Files in /proc/fs/ext4/<devname>
+..............................................................................
+ File            Content
+ mb_groups       details of multiblock allocator buddy cache of free blocks
+..............................................................................
+/sys entries
+============
+Information about mounted ext4 file systems can be found in
+/sys/fs/ext4.  Each mounted filesystem will have a directory in
+/sys/fs/ext4 based on its device name (i.e., /sys/fs/ext4/hdc or
+/sys/fs/ext4/dm-0).   The files in each per-device directory are shown
+in table below.
+Files in /sys/fs/ext4/<devname>
+(see also Documentation/ABI/testing/sysfs-fs-ext4)
+..............................................................................
+ File                         Content
+ delayed_allocation_blocks    This file is read-only and shows the number of
+                              blocks that are dirty in the page cache, but
+                              which do not have their location in the
+                              filesystem allocated yet.
+ inode_goal                   Tuning parameter which (if non-zero) controls
+                              the goal inode used by the inode allocator in
+                              preference to all other allocation heuristics.
+                              This is intended for debugging use only, and
+                              should be 0 on production systems.
+ inode_readahead_blks         Tuning parameter which controls the maximum
+                              number of inode table blocks that ext4's inode
+                              table readahead algorithm will pre-read into
+                              the buffer cache
+ lifetime_write_kbytes        This file is read-only and shows the number of
+                              kilobytes of data that have been written to this
+                              filesystem since it was created.
+ max_writeback_mb_bump        The maximum number of megabytes the writeback
+                              code will try to write out before move on to
+                              another inode.
+ mb_group_prealloc            The multiblock allocator will round up allocation
+                              requests to a multiple of this tuning parameter if
+                              the stripe size is not set in the ext4 superblock
+ mb_max_to_scan               The maximum number of extents the multiblock
+                              allocator will search to find the best extent
+ mb_min_to_scan               The minimum number of extents the multiblock
+                              allocator will search to find the best extent
+ mb_order2_req                Tuning parameter which controls the minimum size
+                              for requests (as a power of 2) where the buddy
+                              cache is used
+ mb_stats                     Controls whether the multiblock allocator should
+                              collect statistics, which are shown during the
+                              unmount. 1 means to collect statistics, 0 means
+                              not to collect statistics
+ mb_stream_req                Files which have fewer blocks than this tunable
+                              parameter will have their blocks allocated out
+                              of a block group specific preallocation pool, so
+                              that small files are packed closely together.
+                              Each large file will have its blocks allocated
+                              out of its own unique preallocation pool.
+ session_write_kbytes         This file is read-only and shows the number of
+                              kilobytes of data that have been written to this
+                              filesystem since it was mounted.
+..............................................................................
+Ioctls
+======
+There is some Ext4 specific functionality which can be accessed by applications
+through the system call interfaces. The list of all Ext4 specific ioctls are
+shown in the table below.
+Table of Ext4 specific ioctls
+..............................................................................
+ Ioctl                        Description
+ EXT4_IOC_GETFLAGS            Get additional attributes associated with inode.
+                              The ioctl argument is an integer bitfield, with
+                              bit values described in ext4.h. This ioctl is an
+                              alias for FS_IOC_GETFLAGS.
+ EXT4_IOC_SETFLAGS            Set additional attributes associated with inode.
+                              The ioctl argument is an integer bitfield, with
+                              bit values described in ext4.h. This ioctl is an
+                              alias for FS_IOC_SETFLAGS.
+ EXT4_IOC_GETVERSION
+ EXT4_IOC_GETVERSION_OLD
+                              Get the inode i_generation number stored for
+                              each inode. The i_generation number is normally
+                              changed only when new inode is created and it is
+                              particularly useful for network filesystems. The
+                              '_OLD' version of this ioctl is an alias for
+                              FS_IOC_GETVERSION.
+ EXT4_IOC_SETVERSION
+ EXT4_IOC_SETVERSION_OLD
+                              Set the inode i_generation number stored for
+                              each inode. The '_OLD' version of this ioctl
+                              is an alias for FS_IOC_SETVERSION.
+ EXT4_IOC_GROUP_EXTEND        This ioctl has the same purpose as the resize
+                              mount option. It allows to resize filesystem
+                              to the end of the last existing block group,
+                              further resize has to be done with resize2fs,
+                              either online, or offline. The argument points
+                              to the unsigned logn number representing the
+                              filesystem new block count.
+ EXT4_IOC_MOVE_EXT            Move the block extents from orig_fd (the one
+                              this ioctl is pointing to) to the donor_fd (the
+                              one specified in move_extent structure passed
+                              as an argument to this ioctl). Then, exchange
+                              inode metadata between orig_fd and donor_fd.
+                              This is especially useful for online
+                              defragmentation, because the allocator has the
+                              opportunity to allocate moved blocks better,
+                              ideally into one contiguous extent.
+ EXT4_IOC_GROUP_ADD           Add a new group descriptor to an existing or
+                              new group descriptor block. The new group
+                              descriptor is described by ext4_new_group_input
+                              structure, which is passed as an argument to
+                              this ioctl. This is especially useful in
+                              conjunction with EXT4_IOC_GROUP_EXTEND,
+                              which allows online resize of the filesystem
+                              to the end of the last existing block group.
+                              Those two ioctls combined is used in userspace
+                              online resize tool (e.g. resize2fs).
+ EXT4_IOC_MIGRATE             This ioctl operates on the filesystem itself.
+                              It converts (migrates) ext3 indirect block mapped
+                              inode to ext4 extent mapped inode by walking
+                              through indirect block mapping of the original
+                              inode and converting contiguous block ranges
+                              into ext4 extents of the temporary inode. Then,
+                              inodes are swapped. This ioctl might help, when
+                              migrating from ext3 to ext4 filesystem, however
+                              suggestion is to create fresh ext4 filesystem
+                              and copy data from the backup. Note, that
+                              filesystem has to support extents for this ioctl
+                              to work.
+ EXT4_IOC_ALLOC_DA_BLKS       Force all of the delay allocated blocks to be
+                              allocated to preserve application-expected ext3
+                              behaviour. Note that this will also start
+                              triggering a write of the data blocks, but this
+                              behaviour may change in the future as it is
+                              not necessary and has been done this way only
+                              for sake of simplicity.
+..............................................................................
 References
 ==========
diff --git a/Documentation/filesystems/gfs2-uevents.txt b/Documentation/filesystems/gfs2-uevents.txt
index fd966dc9979a..d81889669293 100644
--- a/Documentation/filesystems/gfs2-uevents.txt
+++ b/Documentation/filesystems/gfs2-uevents.txt
@@ -62,7 +62,7 @@ be fixed.
 The REMOVE uevent is generated at the end of an unsuccessful mount
 or at the end of a umount of the filesystem. All REMOVE uevents will
-have been preceeded by at least an ADD uevent for the same fileystem,
+have been preceded by at least an ADD uevent for the same fileystem,
 and unlike the other uevents is generated automatically by the kernel's
 kobject subsystem.
diff --git a/Documentation/filesystems/gfs2.txt b/Documentation/filesystems/gfs2.txt
index 0b59c0200912..4cda926628aa 100644
--- a/Documentation/filesystems/gfs2.txt
+++ b/Documentation/filesystems/gfs2.txt
@@ -11,7 +11,7 @@ their I/O so file system consistency is maintained.  One of the nifty
 features of GFS is perfect consistency -- changes made to the file system
 on one machine show up immediately on all other machines in the cluster.
-GFS uses interchangable inter-node locking mechanisms, the currently
+GFS uses interchangeable inter-node locking mechanisms, the currently
 supported mechanisms are:
  lock_nolock -- allows gfs to be used as a local file system
diff --git a/Documentation/filesystems/nfs/00-INDEX b/Documentation/filesystems/nfs/00-INDEX
index 3225a5662114..a57e12411d2a 100644
--- a/Documentation/filesystems/nfs/00-INDEX
+++ b/Documentation/filesystems/nfs/00-INDEX
@@ -12,6 +12,8 @@ nfs-rdma.txt
        - how to install and setup the Linux NFS/RDMA client and server software
 nfsroot.txt
        - short guide on setting up a diskless box with NFS root filesystem.
+pnfs.txt
+        - short explanation of some of the internals of the pnfs client code
 rpc-cache.txt
        - introduction to the caching mechanisms in the sunrpc layer.
 idmapper.txt
diff --git a/Documentation/filesystems/nfs/idmapper.txt b/Documentation/filesystems/nfs/idmapper.txt
index c3852041a21f..b9b4192ea8b5 100644
--- a/Documentation/filesystems/nfs/idmapper.txt
+++ b/Documentation/filesystems/nfs/idmapper.txt
@@ -6,7 +6,7 @@ Id mapper is used by NFS to translate user and group ids into names, and to
 translate user and group names into ids.  Part of this translation involves
 performing an upcall to userspace to request the information.  Id mapper will
 user request-key to perform this upcall and cache the result.  The program
-/usr/sbin/nfs.upcall should be called by request-key, and will perform the
+/usr/sbin/nfs.idmap should be called by request-key, and will perform the
 translation and initialize a key with the resulting information.
 NFS_USE_NEW_IDMAPPER must be selected when configuring the kernel to use this
@@ -20,12 +20,12 @@ direct the upcall.  The following line should be added:
 #OP     TYPE    DESCRIPTION     CALLOUT INFO    PROGRAM ARG1 ARG2 ARG3 ...
 #====== ======= =============== =============== ===============================
-create  id_resolver     *       *               /usr/sbin/nfs.upcall %k %d 600
+create  id_resolver     *       *               /usr/sbin/nfs.idmap %k %d 600
-This will direct all id_resolver requests to the program /usr/sbin/nfs.upcall.
+This will direct all id_resolver requests to the program /usr/sbin/nfs.idmap.
 The last parameter, 600, defines how many seconds into the future the key will
-expire.  This parameter is optional for /usr/sbin/nfs.upcall.  When the timeout
+expire.  This parameter is optional for /usr/sbin/nfs.idmap.  When the timeout
-is not specified, nfs.upcall will default to 600 seconds.
+is not specified, nfs.idmap will default to 600 seconds.
 id mapper uses for key descriptions:
          uid:  Find the UID for the given user
@@ -39,29 +39,29 @@ would edit your request-key.conf so it look similar to this:
 #OP     TYPE    DESCRIPTION     CALLOUT INFO    PROGRAM ARG1 ARG2 ARG3 ...
 #====== ======= =============== =============== ===============================
-create  id_resolver     uid:*   *               /some/other/program  %k %d 600
+create  id_resolver     uid:*   *               /some/other/program %k %d 600
-create  id_resolver     *       *               /usr/sbin/nfs.upcall %k %d 600
+create  id_resolver     *       *               /usr/sbin/nfs.idmap %k %d 600
 Notice that the new line was added above the line for the generic program.
 request-key will find the first matching line and corresponding program.  In
 this case, /some/other/program will handle all uid lookups and
-/usr/sbin/nfs.upcall will handle gid, user, and group lookups.
+/usr/sbin/nfs.idmap will handle gid, user, and group lookups.
 See <file:Documentation/keys-request-keys.txt> for more information about the
 request-key function.
-==========
+=========
-nfs.upcall
+nfs.idmap
-==========
+=========
-nfs.upcall is designed to be called by request-key, and should not be run "by
+nfs.idmap is designed to be called by request-key, and should not be run "by
 hand".  This program takes two arguments, a serialized key and a key
 description.  The serialized key is first converted into a key_serial_t, and
 then passed as an argument to keyctl_instantiate (both are part of keyutils.h).
-The actual lookups are performed by functions found in nfsidmap.h.  nfs.upcall
+The actual lookups are performed by functions found in nfsidmap.h.  nfs.idmap
 determines the correct function to call by looking at the first part of the
 description string.  For example, a uid lookup description will appear as
 "uid:user@domain".
-nfs.upcall will return 0 if the key was instantiated, and non-zero otherwise.
+nfs.idmap will return 0 if the key was instantiated, and non-zero otherwise.
diff --git a/Documentation/filesystems/nfs/pnfs.txt b/Documentation/filesystems/nfs/pnfs.txt
new file mode 100644
index 000000000000..983e14abe7e9
--- /dev/null
+++ b/Documentation/filesystems/nfs/pnfs.txt
@@ -0,0 +1,55 @@
+Reference counting in pnfs:
+==========================
+The are several inter-related caches.  We have layouts which can
+reference multiple devices, each of which can reference multiple data servers.
+Each data server can be referenced by multiple devices.  Each device
+can be referenced by multiple layouts.  To keep all of this straight,
+we need to reference count.
+struct pnfs_layout_hdr
+----------------------
+The on-the-wire command LAYOUTGET corresponds to struct
+pnfs_layout_segment, usually referred to by the variable name lseg.
+Each nfs_inode may hold a pointer to a cache of of these layout
+segments in nfsi->layout, of type struct pnfs_layout_hdr.
+We reference the header for the inode pointing to it, across each
+outstanding RPC call that references it (LAYOUTGET, LAYOUTRETURN,
+LAYOUTCOMMIT), and for each lseg held within.
+Each header is also (when non-empty) put on a list associated with
+struct nfs_client (cl_layouts).  Being put on this list does not bump
+the reference count, as the layout is kept around by the lseg that
+keeps it in the list.
+deviceid_cache
+--------------
+lsegs reference device ids, which are resolved per nfs_client and
+layout driver type.  The device ids are held in a RCU cache (struct
+nfs4_deviceid_cache).  The cache itself is referenced across each
+mount.  The entries (struct nfs4_deviceid) themselves are held across
+the lifetime of each lseg referencing them.
+RCU is used because the deviceid is basically a write once, read many
+data structure.  The hlist size of 32 buckets needs better
+justification, but seems reasonable given that we can have multiple
+deviceid's per filesystem, and multiple filesystems per nfs_client.
+The hash code is copied from the nfsd code base.  A discussion of
+hashing and variations of this algorithm can be found at:
+http://groups.google.com/group/comp.lang.c/browse_thread/thread/9522965e2b8d3809
+data server cache
+-----------------
+file driver devices refer to data servers, which are kept in a module
+level cache.  Its reference is held over the lifetime of the deviceid
+pointing to it.
+lseg
+----
+lseg maintains an extra reference corresponding to the NFS_LSEG_VALID
+bit which holds it in the pnfs_layout_hdr's list.  When the final lseg
+is removed from the pnfs_layout_hdr's list, the NFS_LAYOUT_DESTROYED
+bit is set, preventing any new lsegs from being added.
diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
index ac2a261c5f7d..791af8dac065 100644
--- a/Documentation/filesystems/ntfs.txt
+++ b/Documentation/filesystems/ntfs.txt
@@ -350,7 +350,7 @@ Note the "Should sync?" parameter "nosync" means that the two mirrors are
 already in sync which will be the case on a clean shutdown of Windows.  If the
 mirrors are not clean, you can specify the "sync" option instead of "nosync"
 and the Device-Mapper driver will then copy the entirety of the "Source Device"
-to the "Target Device" or if you specified multipled target devices to all of
+to the "Target Device" or if you specified multiple target devices to all of
 them.
 Once you have your table, save it in a file somewhere (e.g. /etc/ntfsvolume1),
@@ -457,6 +457,11 @@ ChangeLog
 Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
+2.1.30:
+        - Fix writev() (it kept writing the first segment over and over again
+          instead of moving onto subsequent segments).
+        - Fix crash in ntfs_mft_record_alloc() when mapping the new extent mft
+          record failed.
 2.1.29:
        - Fix a deadlock when mounting read-write.
 2.1.28:
diff --git a/Documentation/filesystems/ocfs2.txt b/Documentation/filesystems/ocfs2.txt
index 5393e6611691..9ed920a8cd79 100644
--- a/Documentation/filesystems/ocfs2.txt
+++ b/Documentation/filesystems/ocfs2.txt
@@ -80,7 +80,7 @@ user_xattr	(*)	Enables Extended User Attributes.
 nouser_xattr            Disables Extended User Attributes.
 acl                     Enables POSIX Access Control Lists support.
 noacl           (*)     Disables POSIX Access Control Lists support.
-resv_level=2    (*)     Set how agressive allocation reservations will be.
+resv_level=2    (*)     Set how aggressive allocation reservations will be.
                        Valid values are between 0 (reservations off) to 8
                        (maximum space for reservations).
 dir_resv_level= (*)     By default, directory reservations will scale with file
diff --git a/Documentation/filesystems/path-lookup.txt b/Documentation/filesystems/path-lookup.txt
new file mode 100644
index 000000000000..3571667c7105
--- /dev/null
+++ b/Documentation/filesystems/path-lookup.txt
@@ -0,0 +1,382 @@
+Path walking and name lookup locking
+====================================
+Path resolution is the finding a dentry corresponding to a path name string, by
+performing a path walk. Typically, for every open(), stat() etc., the path name
+will be resolved. Paths are resolved by walking the namespace tree, starting
+with the first component of the pathname (eg. root or cwd) with a known dentry,
+then finding the child of that dentry, which is named the next component in the
+path string. Then repeating the lookup from the child dentry and finding its
+child with the next element, and so on.
+Since it is a frequent operation for workloads like multiuser environments and
+web servers, it is important to optimize this code.
+Path walking synchronisation history:
+Prior to 2.5.10, dcache_lock was acquired in d_lookup (dcache hash lookup) and
+thus in every component during path look-up. Since 2.5.10 onwards, fast-walk
+algorithm changed this by holding the dcache_lock at the beginning and walking
+as many cached path component dentries as possible. This significantly
+decreases the number of acquisition of dcache_lock. However it also increases
+the lock hold time significantly and affects performance in large SMP machines.
+Since 2.5.62 kernel, dcache has been using a new locking model that uses RCU to
+make dcache look-up lock-free.
+All the above algorithms required taking a lock and reference count on the
+dentry that was looked up, so that may be used as the basis for walking the
+next path element. This is inefficient and unscalable. It is inefficient
+because of the locks and atomic operations required for every dentry element
+slows things down. It is not scalable because many parallel applications that
+are path-walk intensive tend to do path lookups starting from a common dentry
+(usually, the root "/" or current working directory). So contention on these
+common path elements causes lock and cacheline queueing.
+Since 2.6.38, RCU is used to make a significant part of the entire path walk
+(including dcache look-up) completely "store-free" (so, no locks, atomics, or
+even stores into cachelines of common dentries). This is known as "rcu-walk"
+path walking.
+Path walking overview
+=====================
+A name string specifies a start (root directory, cwd, fd-relative) and a
+sequence of elements (directory entry names), which together refer to a path in
+the namespace. A path is represented as a (dentry, vfsmount) tuple. The name
+elements are sub-strings, separated by '/'.
+Name lookups will want to find a particular path that a name string refers to
+(usually the final element, or parent of final element). This is done by taking
+the path given by the name's starting point (which we know in advance -- eg.
+current->fs->cwd or current->fs->root) as the first parent of the lookup. Then
+iteratively for each subsequent name element, look up the child of the current
+parent with the given name and if it is not the desired entry, make it the
+parent for the next lookup.
+A parent, of course, must be a directory, and we must have appropriate
+permissions on the parent inode to be able to walk into it.
+Turning the child into a parent for the next lookup requires more checks and
+procedures. Symlinks essentially substitute the symlink name for the target
+name in the name string, and require some recursive path walking.  Mount points
+must be followed into (thus changing the vfsmount that subsequent path elements
+refer to), switching from the mount point path to the root of the particular
+mounted vfsmount. These behaviours are variously modified depending on the
+exact path walking flags.
+Path walking then must, broadly, do several particular things:
+- find the start point of the walk;
+- perform permissions and validity checks on inodes;
+- perform dcache hash name lookups on (parent, name element) tuples;
+- traverse mount points;
+- traverse symlinks;
+- lookup and create missing parts of the path on demand.
+Safe store-free look-up of dcache hash table
+============================================
+Dcache name lookup
+------------------
+In order to lookup a dcache (parent, name) tuple, we take a hash on the tuple
+and use that to select a bucket in the dcache-hash table. The list of entries
+in that bucket is then walked, and we do a full comparison of each entry
+against our (parent, name) tuple.
+The hash lists are RCU protected, so list walking is not serialised with
+concurrent updates (insertion, deletion from the hash). This is a standard RCU
+list application with the exception of renames, which will be covered below.
+Parent and name members of a dentry, as well as its membership in the dcache
+hash, and its inode are protected by the per-dentry d_lock spinlock. A
+reference is taken on the dentry (while the fields are verified under d_lock),
+and this stabilises its d_inode pointer and actual inode. This gives a stable
+point to perform the next step of our path walk against.
+These members are also protected by d_seq seqlock, although this offers
+read-only protection and no durability of results, so care must be taken when
+using d_seq for synchronisation (see seqcount based lookups, below).
+Renames
+-------
+Back to the rename case. In usual RCU protected lists, the only operations that
+will happen to an object is insertion, and then eventually removal from the
+list. The object will not be reused until an RCU grace period is complete.
+This ensures the RCU list traversal primitives can run over the object without
+problems (see RCU documentation for how this works).
+However when a dentry is renamed, its hash value can change, requiring it to be
+moved to a new hash list. Allocating and inserting a new alias would be
+expensive and also problematic for directory dentries. Latency would be far to
+high to wait for a grace period after removing the dentry and before inserting
+it in the new hash bucket. So what is done is to insert the dentry into the
+new list immediately.
+However, when the dentry's list pointers are updated to point to objects in the
+new list before waiting for a grace period, this can result in a concurrent RCU
+lookup of the old list veering off into the new (incorrect) list and missing
+the remaining dentries on the list.
+There is no fundamental problem with walking down the wrong list, because the
+dentry comparisons will never match. However it is fatal to miss a matching
+dentry. So a seqlock is used to detect when a rename has occurred, and so the
+lookup can be retried.
+         1      2      3
+        +---+  +---+  +---+
+hlist-->| N-+->| N-+->| N-+->
+head <--+-P |<-+-P |<-+-P |
+        +---+  +---+  +---+
+Rename of dentry 2 may require it deleted from the above list, and inserted
+into a new list. Deleting 2 gives the following list.
+         1             3
+        +---+         +---+     (don't worry, the longer pointers do not
+hlist-->| N-+-------->| N-+->    impose a measurable performance overhead
+head <--+-P |<--------+-P |      on modern CPUs)
+        +---+         +---+
+          ^      2      ^
+          |    +---+    |
+          |    | N-+----+
+          +----+-P |
+               +---+
+This is a standard RCU-list deletion, which leaves the deleted object's
+pointers intact, so a concurrent list walker that is currently looking at
+object 2 will correctly continue to object 3 when it is time to traverse the
+next object.
+However, when inserting object 2 onto a new list, we end up with this:
+         1             3
+        +---+         +---+
+hlist-->| N-+-------->| N-+->
+head <--+-P |<--------+-P |
+        +---+         +---+
+                 2
+               +---+
+               | N-+---->
+          <----+-P |
+               +---+
+Because we didn't wait for a grace period, there may be a concurrent lookup
+still at 2. Now when it follows 2's 'next' pointer, it will walk off into
+another list without ever having checked object 3.
+A related, but distinctly different, issue is that of rename atomicity versus
+lookup operations. If a file is renamed from 'A' to 'B', a lookup must only
+find either 'A' or 'B'. So if a lookup of 'A' returns NULL, a subsequent lookup
+of 'B' must succeed (note the reverse is not true).
+Between deleting the dentry from the old hash list, and inserting it on the new
+hash list, a lookup may find neither 'A' nor 'B' matching the dentry. The same
+rename seqlock is also used to cover this race in much the same way, by
+retrying a negative lookup result if a rename was in progress.
+Seqcount based lookups
+----------------------
+In refcount based dcache lookups, d_lock is used to serialise access to
+the dentry, stabilising it while comparing its name and parent and then
+taking a reference count (the reference count then gives a stable place to
+start the next part of the path walk from).
+As explained above, we would like to do path walking without taking locks or
+reference counts on intermediate dentries along the path. To do this, a per
+dentry seqlock (d_seq) is used to take a "coherent snapshot" of what the dentry
+looks like (its name, parent, and inode). That snapshot is then used to start
+the next part of the path walk. When loading the coherent snapshot under d_seq,
+care must be taken to load the members up-front, and use those pointers rather
+than reloading from the dentry later on (otherwise we'd have interesting things
+like d_inode going NULL underneath us, if the name was unlinked).
+Also important is to avoid performing any destructive operations (pretty much:
+no non-atomic stores to shared data), and to recheck the seqcount when we are
+"done" with the operation. Retry or abort if the seqcount does not match.
+Avoiding destructive or changing operations means we can easily unwind from
+failure.
+What this means is that a caller, provided they are holding RCU lock to
+protect the dentry object from disappearing, can perform a seqcount based
+lookup which does not increment the refcount on the dentry or write to
+it in any way. This returned dentry can be used for subsequent operations,
+provided that d_seq is rechecked after that operation is complete.
+Inodes are also rcu freed, so the seqcount lookup dentry's inode may also be
+queried for permissions.
+With this two parts of the puzzle, we can do path lookups without taking
+locks or refcounts on dentry elements.
+RCU-walk path walking design
+============================
+Path walking code now has two distinct modes, ref-walk and rcu-walk. ref-walk
+is the traditional[*] way of performing dcache lookups using d_lock to
+serialise concurrent modifications to the dentry and take a reference count on
+it. ref-walk is simple and obvious, and may sleep, take locks, etc while path
+walking is operating on each dentry. rcu-walk uses seqcount based dentry
+lookups, and can perform lookup of intermediate elements without any stores to
+shared data in the dentry or inode. rcu-walk can not be applied to all cases,
+eg. if the filesystem must sleep or perform non trivial operations, rcu-walk
+must be switched to ref-walk mode.
+[*] RCU is still used for the dentry hash lookup in ref-walk, but not the full
+    path walk.
+Where ref-walk uses a stable, refcounted ``parent'' to walk the remaining
+path string, rcu-walk uses a d_seq protected snapshot. When looking up a
+child of this parent snapshot, we open d_seq critical section on the child
+before closing d_seq critical section on the parent. This gives an interlocking
+ladder of snapshots to walk down.
+     proc 101
+      /----------------\
+     / comm:    "vi"    \
+    /  fs.root: dentry0  \
+    \  fs.cwd:  dentry2  /
+     \                  /
+      \----------------/
+So when vi wants to open("/home/npiggin/test.c", O_RDWR), then it will
+start from current->fs->root, which is a pinned dentry. Alternatively,
+"./test.c" would start from cwd; both names refer to the same path in
+the context of proc101.
+     dentry 0
+    +---------------------+   rcu-walk begins here, we note d_seq, check the
+    | name:    "/"        |   inode's permission, and then look up the next
+    | inode:   10         |   path element which is "home"...
+    | children:"home", ...|
+    +---------------------+
+              |
+     dentry 1 V
+    +---------------------+   ... which brings us here. We find dentry1 via
+    | name:    "home"     |   hash lookup, then note d_seq and compare name
+    | inode:   678        |   string and parent pointer. When we have a match,
+    | children:"npiggin"  |   we now recheck the d_seq of dentry0. Then we
+    +---------------------+   check inode and look up the next element.
+              |
+     dentry2  V
+    +---------------------+   Note: if dentry0 is now modified, lookup is
+    | name:    "npiggin"  |   not necessarily invalid, so we need only keep a
+    | inode:   543        |   parent for d_seq verification, and grandparents
+    | children:"a.c", ... |   can be forgotten.
+    +---------------------+
+              |
+     dentry3  V
+    +---------------------+   At this point we have our destination dentry.
+    | name:    "a.c"      |   We now take its d_lock, verify d_seq of this
+    | inode:   14221      |   dentry. If that checks out, we can increment
+    | children:NULL       |   its refcount because we're holding d_lock.
+    +---------------------+
+Taking a refcount on a dentry from rcu-walk mode, by taking its d_lock,
+re-checking its d_seq, and then incrementing its refcount is called
+"dropping rcu" or dropping from rcu-walk into ref-walk mode.
+It is, in some sense, a bit of a house of cards. If the seqcount check of the
+parent snapshot fails, the house comes down, because we had closed the d_seq
+section on the grandparent, so we have nothing left to stand on. In that case,
+the path walk must be fully restarted (which we do in ref-walk mode, to avoid
+live locks). It is costly to have a full restart, but fortunately they are
+quite rare.
+When we reach a point where sleeping is required, or a filesystem callout
+requires ref-walk, then instead of restarting the walk, we attempt to drop rcu
+at the last known good dentry we have. Avoiding a full restart in ref-walk in
+these cases is fundamental for performance and scalability because blocking
+operations such as creates and unlinks are not uncommon.
+The detailed design for rcu-walk is like this:
+* LOOKUP_RCU is set in nd->flags, which distinguishes rcu-walk from ref-walk.
+* Take the RCU lock for the entire path walk, starting with the acquiring
+  of the starting path (eg. root/cwd/fd-path). So now dentry refcounts are
+  not required for dentry persistence.
+* synchronize_rcu is called when unregistering a filesystem, so we can
+  access d_ops and i_ops during rcu-walk.
+* Similarly take the vfsmount lock for the entire path walk. So now mnt
+  refcounts are not required for persistence. Also we are free to perform mount
+  lookups, and to assume dentry mount points and mount roots are stable up and
+  down the path.
+* Have a per-dentry seqlock to protect the dentry name, parent, and inode,
+  so we can load this tuple atomically, and also check whether any of its
+  members have changed.
+* Dentry lookups (based on parent, candidate string tuple) recheck the parent
+  sequence after the child is found in case anything changed in the parent
+  during the path walk.
+* inode is also RCU protected so we can load d_inode and use the inode for
+  limited things.
+* i_mode, i_uid, i_gid can be tested for exec permissions during path walk.
+* i_op can be loaded.
+* When the destination dentry is reached, drop rcu there (ie. take d_lock,
+  verify d_seq, increment refcount).
+* If seqlock verification fails anywhere along the path, do a full restart
+  of the path lookup in ref-walk mode. -ECHILD tends to be used (for want of
+  a better errno) to signal an rcu-walk failure.
+The cases where rcu-walk cannot continue are:
+* NULL dentry (ie. any uncached path element)
+* Following links
+It may be possible eventually to make following links rcu-walk aware.
+Uncached path elements will always require dropping to ref-walk mode, at the
+very least because i_mutex needs to be grabbed, and objects allocated.
+Final note:
+"store-free" path walking is not strictly store free. We take vfsmount lock
+and refcounts (both of which can be made per-cpu), and we also store to the
+stack (which is essentially CPU-local), and we also have to take locks and
+refcount on final dentry.
+The point is that shared data, where practically possible, is not locked
+or stored into. The result is massive improvements in performance and
+scalability of path resolution.
+Interesting statistics
+======================
+The following table gives rcu lookup statistics for a few simple workloads
+(2s12c24t Westmere, debian non-graphical system). Ungraceful are attempts to
+drop rcu that fail due to d_seq failure and requiring the entire path lookup
+again. Other cases are successful rcu-drops that are required before the final
+element, nodentry for missing dentry, revalidate for filesystem revalidate
+routine requiring rcu drop, permission for permission check requiring drop,
+and link for symlink traversal requiring drop.
+     rcu-lookups     restart  nodentry          link  revalidate  permission
+bootup     47121           0      4624          1010       10283        7852
+dbench  25386793           0   6778659(26.7%)     55         549        1156
+kbuild   2696672          10     64442(2.3%)  108764(4.0%)     1        1590
+git diff   39605           0        28             2           0         106
+vfstest 24185492        4945    708725(2.9%) 1076136(4.4%)     0        2651
+What this shows is that failed rcu-walk lookups, ie. ones that are restarted
+entirely with ref-walk, are quite rare. Even the "vfstest" case which
+specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to exercise
+such races is not showing a huge amount of restarts.
+Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where
+the reference count needs to be taken for some reason. This is either because
+we have reached the target of the path walk, or because we have encountered a
+condition that can't be resolved in rcu-walk mode.  Ideally, we drop rcu-walk
+only when we have reached the target dentry, so the other statistics show where
+this does not happen.
+Note that a graceful drop from rcu-walk mode due to something such as the
+dentry not existing (which can be common) is not necessarily a failure of
+rcu-walk scheme, because some elements of the path may have been walked in
+rcu-walk mode. The further we get from common path elements (such as cwd or
+root), the less contended the dentry is likely to be. The closer we are to
+common path elements, the more likely they will exist in dentry cache.
+Papers and other documentation on dcache locking
+================================================
+1. Scaling dcache with RCU (http://linuxjournal.com/article.php?sid=7124).
+2. http://lse.sourceforge.net/locking/dcache/dcache.html
diff --git a/Documentation/filesystems/pohmelfs/network_protocol.txt b/Documentation/filesystems/pohmelfs/network_protocol.txt
index 40ea6c295afb..65e03dd44823 100644
--- a/Documentation/filesystems/pohmelfs/network_protocol.txt
+++ b/Documentation/filesystems/pohmelfs/network_protocol.txt
@@ -20,7 +20,7 @@ Commands can be embedded into transaction command (which in turn has own command
 so one can extend protocol as needed without breaking backward compatibility as long
 as old commands are supported. All string lengths include tail 0 byte.
-All commans are transfered over the network in big-endian. CPU endianess is used at the end peers.
+All commands are transferred over the network in big-endian. CPU endianess is used at the end peers.
 @cmd - command number, which specifies command to be processed. Following
        commands are used currently:
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting
index b12c89538680..6e29954851a2 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -216,7 +216,6 @@ had ->revalidate()) add calls in ->follow_link()/->readlink().
 ->d_parent changes are not protected by BKL anymore.  Read access is safe
 if at least one of the following is true:
        * filesystem has no cross-directory rename()
-        * dcache_lock is held
        * we know that parent had been locked (e.g. we are looking at
 ->d_parent of ->lookup() argument).
        * we are called from ->rename().
@@ -299,11 +298,14 @@ be used instead.  It gets called whenever the inode is evicted, whether it has
 remaining links or not.  Caller does *not* evict the pagecache or inode-associated
 metadata buffers; getting rid of those is responsibility of method, as it had
 been for ->delete_inode().
-        ->drop_inode() returns int now; it's called on final iput() with inode_lock
-held and it returns true if filesystems wants the inode to be dropped.  As before,
+        ->drop_inode() returns int now; it's called on final iput() with
-generic_drop_inode() is still the default and it's been updated appropriately.
+inode->i_lock held and it returns true if filesystems wants the inode to be
-generic_delete_inode() is also alive and it consists simply of return 1.  Note that
+dropped.  As before, generic_drop_inode() is still the default and it's been
-all actual eviction work is done by caller after ->drop_inode() returns.
+updated appropriately.  generic_delete_inode() is also alive and it consists
+simply of return 1.  Note that all actual eviction work is done by caller after
+->drop_inode() returns.
        clear_inode() is gone; use end_writeback() instead.  As before, it must
 be called exactly once on each call of ->evict_inode() (as it used to be for
 each call of ->delete_inode()).  Unlike before, if you are using inode-associated
@@ -318,3 +320,90 @@ if it's zero is not *and* *never* *had* *been* enough.  Final unlink() and iput(
 may happen while the inode is in the middle of ->write_inode(); e.g. if you blindly
 free the on-disk inode, you may end up doing that while ->write_inode() is writing
 to it.
+---
+[mandatory]
+        .d_delete() now only advises the dcache as to whether or not to cache
+unreferenced dentries, and is now only called when the dentry refcount goes to
+0. Even on 0 refcount transition, it must be able to tolerate being called 0,
+1, or more times (eg. constant, idempotent).
+---
+[mandatory]
+        .d_compare() calling convention and locking rules are significantly
+changed. Read updated documentation in Documentation/filesystems/vfs.txt (and
+look at examples of other filesystems) for guidance.
+---
+[mandatory]
+        .d_hash() calling convention and locking rules are significantly
+changed. Read updated documentation in Documentation/filesystems/vfs.txt (and
+look at examples of other filesystems) for guidance.
+---
+[mandatory]
+        dcache_lock is gone, replaced by fine grained locks. See fs/dcache.c
+for details of what locks to replace dcache_lock with in order to protect
+particular things. Most of the time, a filesystem only needs ->d_lock, which
+protects *all* the dcache state of a given dentry.
+--
+[mandatory]
+        Filesystems must RCU-free their inodes, if they can have been accessed
+via rcu-walk path walk (basically, if the file can have had a path name in the
+vfs namespace).
+        i_dentry and i_rcu share storage in a union, and the vfs expects
+i_dentry to be reinitialized before it is freed, so an:
+  INIT_LIST_HEAD(&inode->i_dentry);
+must be done in the RCU callback.
+--
+[recommended]
+        vfs now tries to do path walking in "rcu-walk mode", which avoids
+atomic operations and scalability hazards on dentries and inodes (see
+Documentation/filesystems/path-lookup.txt). d_hash and d_compare changes
+(above) are examples of the changes required to support this. For more complex
+filesystem callbacks, the vfs drops out of rcu-walk mode before the fs call, so
+no changes are required to the filesystem. However, this is costly and loses
+the benefits of rcu-walk mode. We will begin to add filesystem callbacks that
+are rcu-walk aware, shown below. Filesystems should take advantage of this
+where possible.
+--
+[mandatory]
+        d_revalidate is a callback that is made on every path element (if
+the filesystem provides it), which requires dropping out of rcu-walk mode. This
+may now be called in rcu-walk mode (nd->flags & LOOKUP_RCU). -ECHILD should be
+returned if the filesystem cannot handle rcu-walk. See
+Documentation/filesystems/vfs.txt for more details.
+        permission and check_acl are inode permission checks that are called
+on many or all directory inodes on the way down a path walk (to check for
+exec permission). These must now be rcu-walk aware (flags & IPERM_FLAG_RCU).
+See Documentation/filesystems/vfs.txt for more details.
+ 
+--
+[mandatory]
+        In ->fallocate() you must check the mode option passed in.  If your
+filesystem does not support hole punching (deallocating space in the middle of a
+file) you must return -EOPNOTSUPP if FALLOC_FL_PUNCH_HOLE is set in mode.
+Currently you can only have FALLOC_FL_PUNCH_HOLE with FALLOC_FL_KEEP_SIZE set,
+so the i_size should not change when hole punching, even when puching the end of
+a file off.
+--
+[mandatory]
+--
+[mandatory]
+        ->get_sb() is gone.  Switch to use of ->mount().  Typically it's just
+a matter of switching from calling get_sb_... to mount_... and changing the
+function type.  If you were doing it manually, just switch from setting ->mnt_root
+to some pointer to returning that pointer.  On errors return ERR_PTR(...).
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index a6aca8740883..60740e8ecb37 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -136,6 +136,7 @@ Table 1-1: Process specific entries in /proc
 statm          Process memory status information
 status         Process status in human readable form
 wchan          If CONFIG_KALLSYMS is set, a pre-decoded wchan
+ pagemap        Page table
 stack          Report full stack trace, enable via CONFIG_STACKTRACE
 smaps          a extension based on maps, showing the memory consumption of
                each mapping
@@ -370,17 +371,25 @@ Shared_Dirty:          0 kB
 Private_Clean:         0 kB
 Private_Dirty:         0 kB
 Referenced:          892 kB
+Anonymous:             0 kB
 Swap:                  0 kB
 KernelPageSize:        4 kB
 MMUPageSize:           4 kB
+Locked:              374 kB
-The first  of these lines shows  the same information  as is displayed for the
-mapping in /proc/PID/maps.  The remaining lines show  the size of the mapping,
+The first of these lines shows the same information as is displayed for the
-the amount of the mapping that is currently resident in RAM, the "proportional
+mapping in /proc/PID/maps.  The remaining lines show the size of the mapping
-set size” (divide each shared page by the number of processes sharing it), the
+(size), the amount of the mapping that is currently resident in RAM (RSS), the
-number of clean and dirty shared pages in the mapping, and the number of clean
+process' proportional share of this mapping (PSS), the number of clean and
-and dirty private pages in the mapping.  The "Referenced" indicates the amount
+dirty private pages in the mapping.  Note that even a page which is part of a
-of memory currently marked as referenced or accessed.
+MAP_SHARED mapping, but has only a single pte mapped, i.e.  is currently used
+by only one process, is accounted as private and not as shared.  "Referenced"
+indicates the amount of memory currently marked as referenced or accessed.
+"Anonymous" shows the amount of memory that does not belong to any file.  Even
+a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE
+and a page is modified, the file page is replaced by a private anonymous copy.
+"Swap" shows how much would-be-anonymous memory is also used, but out on
+swap.
 This file is only present if the CONFIG_MMU kernel configuration option is
 enabled.
@@ -397,6 +406,9 @@ To clear the bits for the file mapped pages associated with the process
    > echo 3 > /proc/PID/clear_refs
 Any other value written to /proc/PID/clear_refs will have no effect.
+The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags
+using /proc/kpageflags and number of times a page is mapped using
+/proc/kpagecount. For detailed explanation, see Documentation/vm/pagemap.txt.
 1.2 Kernel data
 ---------------
@@ -531,7 +543,7 @@ just those considered 'most important'.  The new vectors are:
  their statistics are used by kernel developers and interested users to
  determine the occurrence of interrupts of the given type.
-The above IRQ vectors are displayed only when relevent.  For example,
+The above IRQ vectors are displayed only when relevant.  For example,
 the threshold vector does not exist on x86_64 platforms.  Others are
 suppressed when the system is a uniprocessor.  As of this writing, only
 i386 and x86_64 platforms support the new IRQ vector displays.
@@ -659,6 +671,8 @@ varies by architecture and compile options.  The following is from a
 > cat /proc/meminfo
+The "Locked" indicates whether the mapping is locked in memory or not.
 MemTotal:     16344972 kB
 MemFree:      13634064 kB
@@ -822,7 +836,6 @@ Provides counts of softirq handlers serviced since boot time, for each cpu.
 TASKLET:          0          0          0        290
   SCHED:      27035      26983      26971      26746
 HRTIMER:          0          0          0          0
-     RCU:       1678       1769       2178       2250
 1.3 IDE devices in /proc/ide
@@ -1170,6 +1183,30 @@ Table 1-12: Files in /proc/fs/ext4/<devname>
 mb_groups       details of multiblock allocator buddy cache of free blocks
 ..............................................................................
+2.0 /proc/consoles
+------------------
+Shows registered system console lines.
+To see which character device lines are currently used for the system console
+/dev/console, you may simply look into the file /proc/consoles:
+  > cat /proc/consoles
+  tty0                 -WU (ECp)       4:7
+  ttyS0                -W- (Ep)        4:64
+The columns are:
+  device               name of the device
+  operations           R = can do read operations
+                       W = can do write operations
+                       U = can do unblank
+  flags                E = it is enabled
+                       C = it is preferred console
+                       B = it is primary boot console
+                       p = it is used for printk buffer
+                       b = it is not a TTY but a Braille device
+                       a = it is safe to use when cpu is offline
+  major:minor          major and minor number of the device separated by a colon
 ------------------------------------------------------------------------------
 Summary
@@ -1285,11 +1322,15 @@ scaled linearly with /proc/<pid>/oom_score_adj.
 Writing to /proc/<pid>/oom_score_adj or /proc/<pid>/oom_adj will change the
 other with its scaled value.
+The value of /proc/<pid>/oom_score_adj may be reduced no lower than the last
+value set by a CAP_SYS_RESOURCE process. To reduce the value any lower
+requires CAP_SYS_RESOURCE.
 NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see
 Documentation/feature-removal-schedule.txt.
 Caveat: when a parent task is selected, the oom killer will sacrifice any first
-generation children with seperate address spaces instead, if possible.  This
+generation children with separate address spaces instead, if possible.  This
 avoids servers and important system daemons from being killed and loses the
 minimal amount of work.
diff --git a/Documentation/filesystems/romfs.txt b/Documentation/filesystems/romfs.txt
index 2d2a7b2a16b9..e2b07cc9120a 100644
--- a/Documentation/filesystems/romfs.txt
+++ b/Documentation/filesystems/romfs.txt
@@ -17,8 +17,7 @@ comparison, an actual rescue disk used up 3202 blocks with ext2, while
 with romfs, it needed 3079 blocks.
 To create such a file system, you'll need a user program named
-genromfs.  It is available via anonymous ftp on sunsite.unc.edu and
+genromfs. It is available on http://romfs.sourceforge.net/
-its mirrors, in the /pub/Linux/system/recovery/ directory.
 As the name suggests, romfs could be also used (space-efficiently) on
 various read-only media, like (E)EPROM disks if someone will have the
diff --git a/Documentation/filesystems/sharedsubtree.txt b/Documentation/filesystems/sharedsubtree.txt
index fc0e39af43c3..4ede421c9687 100644
--- a/Documentation/filesystems/sharedsubtree.txt
+++ b/Documentation/filesystems/sharedsubtree.txt
@@ -62,10 +62,10 @@ replicas continue to be exactly same.
        # mount /dev/sd0  /tmp/a
        #ls /tmp/a
-        t1 t2 t2
+        t1 t2 t3
        #ls /mnt/a
-        t1 t2 t2
+        t1 t2 t3
        Note that the mount has propagated to the mount at /mnt as well.
diff --git a/Documentation/filesystems/smbfs.txt b/Documentation/filesystems/smbfs.txt
deleted file mode 100644
index 194fb0decd2c..000000000000
--- a/Documentation/filesystems/smbfs.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-Smbfs is a filesystem that implements the SMB protocol, which is the
-protocol used by Windows for Workgroups, Windows 95 and Windows NT.
-Smbfs was inspired by Samba, the program written by Andrew Tridgell
-that turns any Unix host into a file server for DOS or Windows clients.
-Smbfs is a SMB client, but uses parts of samba for its operation. For
-more info on samba, including documentation, please go to
-http://www.samba.org/ and then on to your nearest mirror.
diff --git a/Documentation/filesystems/squashfs.txt b/Documentation/filesystems/squashfs.txt
index 66699afd66ca..d4d41465a0b1 100644
--- a/Documentation/filesystems/squashfs.txt
+++ b/Documentation/filesystems/squashfs.txt
@@ -59,12 +59,15 @@ obtained from this site also.
 3. SQUASHFS FILESYSTEM DESIGN
 -----------------------------
-A squashfs filesystem consists of a maximum of eight parts, packed together on a byte
+A squashfs filesystem consists of a maximum of nine parts, packed together on a
-alignment:
+byte alignment:
         ---------------
        |  superblock   |
        |---------------|
+        |  compression  |
+        |    options    |
+        |---------------|
        |  datablocks   |
        |  & fragments  |
        |---------------|
@@ -91,7 +94,14 @@ the source directory, and checked for duplicates.  Once all file data has been
 written the completed inode, directory, fragment, export and uid/gid lookup
 tables are written.
-3.1 Inodes
+3.1 Compression options
+-----------------------
+Compressors can optionally support compression specific options (e.g.
+dictionary size).  If non-default compression options have been used, then
+these are stored here.
+3.2 Inodes
 ----------
 Metadata (inodes and directories) are compressed in 8Kbyte blocks.  Each
@@ -114,7 +124,7 @@ directory inode are defined: inodes optimised for frequently occurring
 regular files and directories, and extended types where extra
 information has to be stored.
-3.2 Directories
+3.3 Directories
 ---------------
 Like inodes, directories are packed into compressed metadata blocks, stored
@@ -144,7 +154,7 @@ decompressed to do a lookup irrespective of the length of the directory.
 This scheme has the advantage that it doesn't require extra memory overhead
 and doesn't require much extra storage on disk.
-3.3 File data
+3.4 File data
 -------------
 Regular files consist of a sequence of contiguous compressed blocks, and/or a
@@ -163,7 +173,7 @@ Larger files use multiple slots, with 1.75 TiB files using all 8 slots.
 The index cache is designed to be memory efficient, and by default uses
 16 KiB.
-3.4 Fragment lookup table
+3.5 Fragment lookup table
 -------------------------
 Regular files can contain a fragment index which is mapped to a fragment
@@ -173,7 +183,7 @@ A second index table is used to locate these.  This second index table for
 speed of access (and because it is small) is read at mount time and cached
 in memory.
-3.5 Uid/gid lookup table
+3.6 Uid/gid lookup table
 ------------------------
 For space efficiency regular files store uid and gid indexes, which are
@@ -182,7 +192,7 @@ stored compressed into metadata blocks.  A second index table is used to
 locate these.  This second index table for speed of access (and because it
 is small) is read at mount time and cached in memory.
-3.6 Export table
+3.7 Export table
 ----------------
 To enable Squashfs filesystems to be exportable (via NFS etc.) filesystems
@@ -196,7 +206,7 @@ This table is stored compressed into metadata blocks.  A second index table is
 used to locate these.  This second index table for speed of access (and because
 it is small) is read at mount time and cached in memory.
-3.7 Xattr table
+3.8 Xattr table
 ---------------
 The xattr table contains extended attributes for each inode.  The xattrs
@@ -209,7 +219,7 @@ or if it is stored out of line (in which case the value field stores a
 reference to where the actual value is stored).  This allows large values
 to be stored out of line improving scanning and lookup performance and it
 also allows values to be de-duplicated, the value being stored once, and
-all other occurences holding an out of line reference to that value.
+all other occurrences holding an out of line reference to that value.
 The xattr lists are packed into compressed 8K metadata blocks.
 To reduce overhead in inodes, rather than storing the on-disk
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index 5d1335faec2d..597f728e7b4e 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -39,10 +39,12 @@ userspace. Top-level directories in sysfs represent the common
 ancestors of object hierarchies; i.e. the subsystems the objects
 belong to. 
-Sysfs internally stores the kobject that owns the directory in the
+Sysfs internally stores a pointer to the kobject that implements a
->d_fsdata pointer of the directory's dentry. This allows sysfs to do
+directory in the sysfs_dirent object associated with the directory. In
-reference counting directly on the kobject when the file is opened and
+the past this kobject pointer has been used by sysfs to do reference
-closed. 
+counting directly on the kobject whenever the file is opened or closed.
+With the current sysfs implementation the kobject reference count is
+only modified directly by the function sysfs_schedule_callback().
 Attributes
@@ -60,7 +62,7 @@ values of the same type.
 Mixing types, expressing multiple lines of data, and doing fancy
 formatting of data is heavily frowned upon. Doing these things may get
-you publically humiliated and your code rewritten without notice. 
+you publicly humiliated and your code rewritten without notice. 
 An attribute definition is simply:
@@ -208,9 +210,9 @@ Other notes:
  is 4096. 
 - show() methods should return the number of bytes printed into the
-  buffer. This is the return value of snprintf().
+  buffer. This is the return value of scnprintf().
- show() should always use snprintf(). 
+- show() should always use scnprintf().
 - store() should return the number of bytes used from the buffer. If the
  entire buffer has been used, just return the count argument.
@@ -229,7 +231,7 @@ A very simple (and naive) implementation of a device attribute is:
 static ssize_t show_name(struct device *dev, struct device_attribute *attr,
                         char *buf)
 {
-        return snprintf(buf, PAGE_SIZE, "%s\n", dev->name);
+        return scnprintf(buf, PAGE_SIZE, "%s\n", dev->name);
 }
 static ssize_t store_name(struct device *dev, struct device_attribute *attr,
diff --git a/Documentation/filesystems/ubifs.txt b/Documentation/filesystems/ubifs.txt
index 12fedb7834c6..d7b13b01e980 100644
--- a/Documentation/filesystems/ubifs.txt
+++ b/Documentation/filesystems/ubifs.txt
@@ -82,12 +82,12 @@ Mount options
 bulk_read               read more in one go to take advantage of flash
                        media that read faster sequentially
 no_bulk_read (*)        do not bulk-read
-no_chk_data_crc         skip checking of CRCs on data nodes in order to
+no_chk_data_crc (*)     skip checking of CRCs on data nodes in order to
                        improve read performance. Use this option only
                        if the flash media is highly reliable. The effect
                        of this option is that corruption of the contents
                        of a file can go unnoticed.
-chk_data_crc (*)        do not skip checking CRCs on data nodes
+chk_data_crc            do not skip checking CRCs on data nodes
 compr=none              override default compressor and set it to "none"
 compr=lzo               override default compressor and set it to "lzo"
 compr=zlib              override default compressor and set it to "zlib"
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index ed7e5efc06d8..21a7dc467bba 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -95,10 +95,11 @@ functions:
   extern int unregister_filesystem(struct file_system_type *);
 The passed struct file_system_type describes your filesystem. When a
-request is made to mount a device onto a directory in your filespace,
+request is made to mount a filesystem onto a directory in your namespace,
-the VFS will call the appropriate get_sb() method for the specific
+the VFS will call the appropriate mount() method for the specific
-filesystem. The dentry for the mount point will then be updated to
+filesystem.  New vfsmount referring to the tree returned by ->mount()
-point to the root inode for the new filesystem.
+will be attached to the mountpoint, so that when pathname resolution
+reaches the mountpoint it will jump into the root of that vfsmount.
 You can see all filesystems that are registered to the kernel in the
 file /proc/filesystems.
@@ -107,14 +108,14 @@ file /proc/filesystems.
 struct file_system_type
 -----------------------
-This describes the filesystem. As of kernel 2.6.22, the following
+This describes the filesystem. As of kernel 2.6.39, the following
 members are defined:
 struct file_system_type {
        const char *name;
        int fs_flags;
-        int (*get_sb) (struct file_system_type *, int,
+        struct dentry (*mount) (struct file_system_type *, int,
-                       const char *, void *, struct vfsmount *);
+                       const char *, void *);
        void (*kill_sb) (struct super_block *);
        struct module *owner;
        struct file_system_type * next;
@@ -128,11 +129,11 @@ struct file_system_type {
  fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.)
-  get_sb: the method to call when a new instance of this
+  mount: the method to call when a new instance of this
        filesystem should be mounted
  kill_sb: the method to call when an instance of this filesystem
-        should be unmounted
+        should be shut down
  owner: for internal VFS use: you should initialize this to THIS_MODULE in
        most cases.
@@ -141,7 +142,7 @@ struct file_system_type {
  s_lock_key, s_umount_key: lockdep-specific
-The get_sb() method has the following arguments:
+The mount() method has the following arguments:
  struct file_system_type *fs_type: describes the filesystem, partly initialized
        by the specific filesystem code
@@ -153,32 +154,39 @@ The get_sb() method has the following arguments:
  void *data: arbitrary mount options, usually comes as an ASCII
        string (see "Mount Options" section)
-  struct vfsmount *mnt: a vfs-internal representation of a mount point
+The mount() method must return the root dentry of the tree requested by
+caller.  An active reference to its superblock must be grabbed and the
+superblock must be locked.  On failure it should return ERR_PTR(error).
-The get_sb() method must determine if the block device specified
+The arguments match those of mount(2) and their interpretation
-in the dev_name and fs_type contains a filesystem of the type the method
+depends on filesystem type.  E.g. for block filesystems, dev_name is
-supports. If it succeeds in opening the named block device, it initializes a
+interpreted as block device name, that device is opened and if it
-struct super_block descriptor for the filesystem contained by the block device.
+contains a suitable filesystem image the method creates and initializes
-On failure it returns an error.
+struct super_block accordingly, returning its root dentry to caller.
+->mount() may choose to return a subtree of existing filesystem - it
+doesn't have to create a new one.  The main result from the caller's
+point of view is a reference to dentry at the root of (sub)tree to
+be attached; creation of new superblock is a common side effect.
 The most interesting member of the superblock structure that the
-get_sb() method fills in is the "s_op" field. This is a pointer to
+mount() method fills in is the "s_op" field. This is a pointer to
 a "struct super_operations" which describes the next level of the
 filesystem implementation.
-Usually, a filesystem uses one of the generic get_sb() implementations
+Usually, a filesystem uses one of the generic mount() implementations
-and provides a fill_super() method instead. The generic methods are:
+and provides a fill_super() callback instead. The generic variants are:
-  get_sb_bdev: mount a filesystem residing on a block device
+  mount_bdev: mount a filesystem residing on a block device
-  get_sb_nodev: mount a filesystem that is not backed by a device
+  mount_nodev: mount a filesystem that is not backed by a device
-  get_sb_single: mount a filesystem which shares the instance between
+  mount_single: mount a filesystem which shares the instance between
        all mounts
-A fill_super() method implementation has the following arguments:
+A fill_super() callback implementation has the following arguments:
-  struct super_block *sb: the superblock structure. The method fill_super()
+  struct super_block *sb: the superblock structure. The callback
        must initialize this properly.
  void *data: arbitrary mount options, usually comes as an ASCII
@@ -246,7 +254,7 @@ or bottom half).
        should be synchronous or not, not all filesystems check this flag.
  drop_inode: called when the last access to the inode is dropped,
-        with the inode_lock spinlock held.
+        with the inode->i_lock spinlock held.
        This method should be either NULL (normal UNIX filesystem
        semantics) or "generic_delete_inode" (for filesystems that do not
@@ -325,7 +333,8 @@ struct inode_operations {
        void * (*follow_link) (struct dentry *, struct nameidata *);
        void (*put_link) (struct dentry *, struct nameidata *, void *);
        void (*truncate) (struct inode *);
-        int (*permission) (struct inode *, int, struct nameidata *);
+        int (*permission) (struct inode *, int, unsigned int);
+        int (*check_acl)(struct inode *, int, unsigned int);
        int (*setattr) (struct dentry *, struct iattr *);
        int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
        int (*setxattr) (struct dentry *, const char *,const void *,size_t,int);
@@ -414,6 +423,13 @@ otherwise noted.
  permission: called by the VFS to check for access rights on a POSIX-like
        filesystem.
+        May be called in rcu-walk mode (flags & IPERM_FLAG_RCU). If in rcu-walk
+        mode, the filesystem must check the permission without blocking or
+        storing to the inode.
+        If a situation is encountered that rcu-walk cannot handle, return
+        -ECHILD and it will be called again in ref-walk mode.
  setattr: called by the VFS to set attributes for a file. This method
        is called by chmod(2) and related system calls.
@@ -534,6 +550,7 @@ struct address_space_operations {
        sector_t (*bmap)(struct address_space *, sector_t);
        int (*invalidatepage) (struct page *, unsigned long);
        int (*releasepage) (struct page *, int);
+        void (*freepage)(struct page *);
        ssize_t (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
                        loff_t offset, unsigned long nr_segs);
        struct page* (*get_xip_page)(struct address_space *, sector_t,
@@ -660,11 +677,10 @@ struct address_space_operations {
  releasepage: releasepage is called on PagePrivate pages to indicate
        that the page should be freed if possible.  ->releasepage
        should remove any private data from the page and clear the
-        PagePrivate flag.  It may also remove the page from the
+        PagePrivate flag. If releasepage() fails for some reason, it must
-        address_space.  If this fails for some reason, it may indicate
+        indicate failure with a 0 return value.
-        failure with a 0 return value.
+        releasepage() is used in two distinct though related cases.  The
-        This is used in two distinct though related cases.  The first
+        first is when the VM finds a clean page with no active users and
-        is when the VM finds a clean page with no active users and
        wants to make it a free page.  If ->releasepage succeeds, the
        page will be removed from the address_space and become free.
@@ -679,6 +695,12 @@ struct address_space_operations {
        need to ensure this.  Possibly it can clear the PageUptodate
        bit if it cannot free private data yet.
+  freepage: freepage is called once the page is no longer visible in
+        the page cache in order to allow the cleanup of any private
+        data. Since it may be called by the memory reclaimer, it
+        should not assume that the original address_space mapping still
+        exists, and it should not block.
  direct_IO: called by the generic read/write routines to perform
        direct_IO - that is IO requests which bypass the page cache
        and transfer data directly between the storage and the
@@ -841,12 +863,17 @@ defined:
 struct dentry_operations {
        int (*d_revalidate)(struct dentry *, struct nameidata *);
-        int (*d_hash) (struct dentry *, struct qstr *);
+        int (*d_hash)(const struct dentry *, const struct inode *,
-        int (*d_compare) (struct dentry *, struct qstr *, struct qstr *);
+                        struct qstr *);
-        int (*d_delete)(struct dentry *);
+        int (*d_compare)(const struct dentry *, const struct inode *,
+                        const struct dentry *, const struct inode *,
+                        unsigned int, const char *, const struct qstr *);
+        int (*d_delete)(const struct dentry *);
        void (*d_release)(struct dentry *);
        void (*d_iput)(struct dentry *, struct inode *);
        char *(*d_dname)(struct dentry *, char *, int);
+        struct vfsmount *(*d_automount)(struct path *);
+        int (*d_manage)(struct dentry *, bool);
 };
  d_revalidate: called when the VFS needs to revalidate a dentry. This
@@ -854,13 +881,45 @@ struct dentry_operations {
        dcache. Most filesystems leave this as NULL, because all their
        dentries in the dcache are valid
-  d_hash: called when the VFS adds a dentry to the hash table
+        d_revalidate may be called in rcu-walk mode (nd->flags & LOOKUP_RCU).
+        If in rcu-walk mode, the filesystem must revalidate the dentry without
+        blocking or storing to the dentry, d_parent and d_inode should not be
+        used without care (because they can go NULL), instead nd->inode should
+        be used.
+        If a situation is encountered that rcu-walk cannot handle, return
+        -ECHILD and it will be called again in ref-walk mode.
+  d_hash: called when the VFS adds a dentry to the hash table. The first
+        dentry passed to d_hash is the parent directory that the name is
+        to be hashed into. The inode is the dentry's inode.
-  d_compare: called when a dentry should be compared with another
+        Same locking and synchronisation rules as d_compare regarding
+        what is safe to dereference etc.
-  d_delete: called when the last reference to a dentry is
+  d_compare: called to compare a dentry name with a given name. The first
-        deleted. This means no-one is using the dentry, however it is
+        dentry is the parent of the dentry to be compared, the second is
-        still valid and in the dcache
+        the parent's inode, then the dentry and inode (may be NULL) of the
+        child dentry. len and name string are properties of the dentry to be
+        compared. qstr is the name to compare it with.
+        Must be constant and idempotent, and should not take locks if
+        possible, and should not or store into the dentry or inodes.
+        Should not dereference pointers outside the dentry or inodes without
+        lots of care (eg.  d_parent, d_inode, d_name should not be used).
+        However, our vfsmount is pinned, and RCU held, so the dentries and
+        inodes won't disappear, neither will our sb or filesystem module.
+        ->i_sb and ->d_sb may be used.
+        It is a tricky calling convention because it needs to be called under
+        "rcu-walk", ie. without any locks or references on things.
+  d_delete: called when the last reference to a dentry is dropped and the
+        dcache is deciding whether or not to cache it. Return 1 to delete
+        immediately, or 0 to cache the dentry. Default is NULL which means to
+        always cache a reachable dentry. d_delete must be constant and
+        idempotent.
  d_release: called when a dentry is really deallocated
@@ -881,6 +940,43 @@ struct dentry_operations {
        at the end of the buffer, and returns a pointer to the first char.
        dynamic_dname() helper function is provided to take care of this.
+  d_automount: called when an automount dentry is to be traversed (optional).
+        This should create a new VFS mount record and return the record to the
+        caller.  The caller is supplied with a path parameter giving the
+        automount directory to describe the automount target and the parent
+        VFS mount record to provide inheritable mount parameters.  NULL should
+        be returned if someone else managed to make the automount first.  If
+        the vfsmount creation failed, then an error code should be returned.
+        If -EISDIR is returned, then the directory will be treated as an
+        ordinary directory and returned to pathwalk to continue walking.
+        If a vfsmount is returned, the caller will attempt to mount it on the
+        mountpoint and will remove the vfsmount from its expiration list in
+        the case of failure.  The vfsmount should be returned with 2 refs on
+        it to prevent automatic expiration - the caller will clean up the
+        additional ref.
+        This function is only used if DCACHE_NEED_AUTOMOUNT is set on the
+        dentry.  This is set by __d_instantiate() if S_AUTOMOUNT is set on the
+        inode being added.
+  d_manage: called to allow the filesystem to manage the transition from a
+        dentry (optional).  This allows autofs, for example, to hold up clients
+        waiting to explore behind a 'mountpoint' whilst letting the daemon go
+        past and construct the subtree there.  0 should be returned to let the
+        calling process continue.  -EISDIR can be returned to tell pathwalk to
+        use this directory as an ordinary directory and to ignore anything
+        mounted on it and not to check the automount flag.  Any other error
+        code will abort pathwalk completely.
+        If the 'rcu_walk' parameter is true, then the caller is doing a
+        pathwalk in RCU-walk mode.  Sleeping is not permitted in this mode,
+        and the caller can be asked to leave it and call again by returing
+        -ECHILD.
+        This function is only used if DCACHE_MANAGE_TRANSIT is set on the
+        dentry being transited from.
 Example :
 static char *pipefs_dname(struct dentry *dent, char *buffer, int buflen)
@@ -904,14 +1000,11 @@ manipulate dentries:
        the usage count)
  dput: close a handle for a dentry (decrements the usage count). If
-        the usage count drops to 0, the "d_delete" method is called
+        the usage count drops to 0, and the dentry is still in its
-        and the dentry is placed on the unused list if the dentry is
+        parent's hash, the "d_delete" method is called to check whether
-        still in its parents hash list. Putting the dentry on the
+        it should be cached. If it should not be cached, or if the dentry
-        unused list just means that if the system needs some RAM, it
+        is not hashed, it is deleted. Otherwise cached dentries are put
-        goes through the unused list of dentries and deallocates them.
+        into an LRU list to be reclaimed on memory shortage.
-        If the dentry has already been unhashed and the usage count
-        drops to 0, in this case the dentry is deallocated after the
-        "d_delete" method is called
  d_drop: this unhashes a dentry from its parents hash list. A
        subsequent call to dput() will deallocate the dentry if its
diff --git a/Documentation/filesystems/xfs-delayed-logging-design.txt b/Documentation/filesystems/xfs-delayed-logging-design.txt
index 96d0df28bed3..2ce36439c09f 100644
--- a/Documentation/filesystems/xfs-delayed-logging-design.txt
+++ b/Documentation/filesystems/xfs-delayed-logging-design.txt
@@ -42,7 +42,7 @@ the aggregation of all the previous changes currently held only in the log.
 This relogging technique also allows objects to be moved forward in the log so
 that an object being relogged does not prevent the tail of the log from ever
 moving forward.  This can be seen in the table above by the changing
-(increasing) LSN of each subsquent transaction - the LSN is effectively a
+(increasing) LSN of each subsequent transaction - the LSN is effectively a
 direct encoding of the location in the log of the transaction.
 This relogging is also used to implement long-running, multiple-commit
@@ -338,7 +338,7 @@ the same time another transaction modifies the item and inserts the log item
 into the new CIL, then checkpoint transaction commit code cannot use log items
 to store the list of log vectors that need to be written into the transaction.
 Hence log vectors need to be able to be chained together to allow them to be
-detatched from the log items. That is, when the CIL is flushed the memory
+detached from the log items. That is, when the CIL is flushed the memory
 buffer and log vector attached to each log item needs to be attached to the
 checkpoint context so that the log item can be released. In diagrammatic form,
 the CIL would look like this before the flush:
@@ -577,7 +577,7 @@ only becomes unpinned when all the transactions complete and there are no
 pending transactions. Thus the pinning and unpinning of a log item is symmetric
 as there is a 1:1 relationship with transaction commit and log item completion.
-For delayed logging, however, we have an assymetric transaction commit to
+For delayed logging, however, we have an asymmetric transaction commit to
 completion relationship. Every time an object is relogged in the CIL it goes
 through the commit process without a corresponding completion being registered.
 That is, we now have a many-to-one relationship between transaction commit and
@@ -780,7 +780,7 @@ With delayed logging, there are new steps inserted into the life cycle:
 From this, it can be seen that the only life cycle differences between the two
 logging methods are in the middle of the life cycle - they still have the same
 beginning and end and execution constraints. The only differences are in the
-commiting of the log items to the log itself and the completion processing.
+committing of the log items to the log itself and the completion processing.
 Hence delayed logging should not introduce any constraints on log item
 behaviour, allocation or freeing that don't already exist.
@@ -791,21 +791,3 @@ mount option. Fundamentally, there is no reason why the log manager would not
 be able to swap methods automatically and transparently depending on load
 characteristics, but this should not be necessary if delayed logging works as
 designed.
-Roadmap:
-2.6.37 Remove experimental tag from mount option
-        => should be roughly 6 months after initial merge
-        => enough time to:
-                => gain confidence and fix problems reported by early
-                   adopters (a.k.a. guinea pigs)
-                => address worst performance regressions and undesired
-                   behaviours
-                => start tuning/optimising code for parallelism
-                => start tuning/optimising algorithms consuming
-                   excessive CPU time
-2.6.39 Switch default mount option to use delayed logging
-        => should be roughly 12 months after initial merge
-        => enough time to shake out remaining problems before next round of
-           enterprise distro kernel rebases