patch-2.4.0-test4 linux/Documentation/filesystems/Locking
Next file: linux/Documentation/kernel-parameters.txt
Previous file: linux/Documentation/DocBook/parportbook.tmpl
Back to the patch index
Back to the overall index
- Lines: 37
- Date:
Wed Jul 12 21:58:41 2000
- Orig file:
v2.4.0-test3/linux/Documentation/filesystems/Locking
- Orig date:
Mon Jul 10 16:47:18 2000
diff -u --recursive --new-file v2.4.0-test3/linux/Documentation/filesystems/Locking linux/Documentation/filesystems/Locking
@@ -66,6 +66,7 @@
revalidate: no (see below)
Additionally, ->rmdir() has i_zombie on victim and so does ->rename()
in case when target exists and is a directory.
+ ->rename() on directories has (per-superblock) ->s_vfs_rename_sem.
->revalidate(), it may be called both with and without the i_sem
on dentry->d_inode. VFS never calls it with i_zombie on dentry->d_inode,
but watch for other methods directly calling this one...
@@ -226,7 +227,7 @@
mmap: no
open: maybe (see below)
flush: yes
-release: yes
+release: no
fsync: yes (see below)
fasync: yes (see below)
lock: yes
@@ -238,12 +239,13 @@
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. At the same point
-->release() will lose BKL. Currently ext2_release() is *the* source of
-contention on fs-intensive loads and dropping BKL on ->release() will get
-rid of that (we will still need some locking for cases when we close a file
-that had been opened r/w, but that can be done using the internal locking with
-smaller critical areas). sock_close() is also going to win from that change.
+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
+can and should be done using the internal locking with smaller critical areas).
+Current worst offender is ext2_get_block()...
->fasync() is a mess. This area needs a big cleanup and that will probably
affect locking.
FUNET's LINUX-ADM group, linux-adm@nic.funet.fi
TCL-scripts by Sam Shen (who was at: slshen@lbl.gov)