From 866707fc2721df8fee637fcf0239628b9231f9ea Mon Sep 17 00:00:00 2001 From: Jan Blunck Date: Wed, 26 May 2010 14:44:54 -0700 Subject: Documentation/filesystems/Locking: update documentation on llseek() wrt BKL The inode's i_size is not protected by the big kernel lock. Therefore it does not make sense to recommend taking the BKL in filesystems llseek operations. Instead it should use the inode's mutex or use just use i_size_read() instead. Add a note that this is not protecting file->f_pos. Signed-off-by: Jan Blunck Acked-by: Alan Cox Cc: Arnd Bergmann Cc: Christoph Hellwig Cc: Frederic Weisbecker Cc: John Kacur Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/Locking | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation/filesystems/Locking') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index af1608070cd5..61c98f03baa1 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -429,8 +429,9 @@ check_flags: no implementations. If your fs is not using generic_file_llseek, you need to acquire and release the appropriate locks in your ->llseek(). For many filesystems, it is probably safe to acquire the inode -mutex. Note some filesystems (i.e. remote ones) provide no -protection for i_size so you will need to use the BKL. +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 loads and dropping BKL on ->release() helps to get rid of that (we still -- cgit v1.2.3