update Documentation/filesystems/Locking for 2.6.27 changes

[linux-2.6-omap-h63xx.git] / Documentation / filesystems / Locking

diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index fe26cc978523959b468cd8fa5398eed5ef1b8559..8362860e21a7d6b4db3595e83905b32b25e55ecf 100644 (file)
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -90,10 +90,8 @@ of the locking scheme for directory operations.
 prototypes:
        struct inode *(*alloc_inode)(struct super_block *sb);
        void (*destroy_inode)(struct inode *);
-       void (*read_inode) (struct inode *);
        void (*dirty_inode) (struct inode *);
        int (*write_inode) (struct inode *, int);
-       void (*put_inode) (struct inode *);
        void (*drop_inode) (struct inode *);
        void (*delete_inode) (struct inode *);
        void (*put_super) (struct super_block *);
@@ -114,10 +112,8 @@ locking rules:
                        BKL     s_lock  s_umount
 alloc_inode:           no      no      no
 destroy_inode:         no
-read_inode:            no                              (see below)
 dirty_inode:           no                              (must not sleep)
 write_inode:           no
-put_inode:             no
 drop_inode:            no                              !!!inode_lock!!!
 delete_inode:          no
 put_super:             yes     yes     no
@@ -133,7 +129,6 @@ show_options:               no                              (vfsmount->sem)
 quota_read:            no      no      no              (see below)
 quota_write:           no      no      no              (see below)
 
-->read_inode() is not a method - it's a callback used in iget().
 ->remount_fs() will have the s_umount lock if it's already mounted.
 When called from get_sb_single, it does NOT have the s_umount lock.
 ->quota_read() and ->quota_write() functions are both guaranteed to
@@ -149,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).
@@ -224,7 +219,7 @@ against the page the filesystem should redirty the page with
 redirty_page_for_writepage(), then unlock the page and return zero.
 This may also be done to avoid internal deadlocks, but rarely.
 
-If the filesytem is called for sync then it must wait on any
+If the filesystem is called for sync then it must wait on any
 in-progress I/O and then start new I/O.
 
 The filesystem should unlock the page synchronously, before returning to the
@@ -414,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
@@ -436,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
@@ -514,16 +502,16 @@ prototypes:
        void (*open)(struct vm_area_struct*);
        void (*close)(struct vm_area_struct*);
        int (*fault)(struct vm_area_struct*, struct vm_fault *);
-       struct page *(*nopage)(struct vm_area_struct*, unsigned long, int *);
        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)
 open:          no      yes
 close:         no      yes
 fault:         no      yes
-nopage:                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
@@ -532,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
 
@@ -540,4 +533,3 @@ NULL.
 
 ipc/shm.c::shm_delete() - may need BKL.
 ->read() and ->write() in many drivers are (probably) missing BKL.
-drivers/sgi/char/graphics.c::sgi_graphics_nopage() - may need BKL.