Merge commit 'v2.6.28-rc2' into x86/pci-ioapic-boot-irq-quirks

1 files changed, 11 insertions, 11 deletions

diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 8b22d7d8b991..8362860e21a7 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -144,8 +144,8 @@ prototypes:
         void (*kill_sb) (struct super_block *);
 locking rules:
                 may block       BKL
-get_sb          yes             yes
-kill_sb         yes             yes
+get_sb          yes             no
+kill_sb         yes             no
 
 ->get_sb() returns error or 0 with locked superblock attached to the vfsmount
 (exclusive on ->s_umount).
@@ -409,12 +409,12 @@ ioctl:			yes	(see below)
 unlocked_ioctl:         no      (see below)
 compat_ioctl:           no
 mmap:                   no
-open:                   maybe   (see below)
+open:                   no
 flush:                  no
 release:                no
 fsync:                  no      (see below)
 aio_fsync:              no
-fasync:                 yes     (see below)
+fasync:                 no
 lock:                   yes
 readv:                  no
 writev:                 no
@@ -431,13 +431,6 @@ For many filesystems, it is probably safe to acquire the inode
 semaphore.  Note some filesystems (i.e. remote ones) provide no
 protection for i_size so you will need to use the BKL.
 
-->open() locking is in-transit: big lock partially moved into the methods.
-The only exception is ->open() in the instances of file_operations that never
-end up in ->i_fop/->proc_fops, i.e. ones that belong to character devices
-(chrdev_open() takes lock before replacing ->f_op and calling the secondary
-method. As soon as we fix the handling of module reference counters all
-instances of ->open() will be called without the BKL.
-
 Note: ext2_release() was *the* source of contention on fs-intensive
 loads and dropping BKL on ->release() helps to get rid of that (we still
 grab BKL for cases when we close a file that had been opened r/w, but that
@@ -510,6 +503,7 @@ prototypes:
         void (*close)(struct vm_area_struct*);
         int (*fault)(struct vm_area_struct*, struct vm_fault *);
         int (*page_mkwrite)(struct vm_area_struct *, struct page *);
+        int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
 
 locking rules:
                 BKL     mmap_sem        PageLocked(page)
@@ -517,6 +511,7 @@ open:		no	yes
 close:          no      yes
 fault:          no      yes
 page_mkwrite:   no      yes             no
+access:         no      yes
 
         ->page_mkwrite() is called when a previously read-only page is
 about to become writeable. The file system is responsible for
@@ -525,6 +520,11 @@ taking to lock out truncate, the page range should be verified to be
 within i_size. The page mapping should also be checked that it is not
 NULL.
 
+        ->access() is called when get_user_pages() fails in
+acces_process_vm(), typically used to debug a process through
+/proc/pid/mem or ptrace.  This function is needed only for
+VM_IO | VM_PFNMAP VMAs.
+
 ================================================================================
                         Dubious stuff