From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Blunck Subject: [PATCH 2/2] BKL: Update documentation on llseek( =?ISO-8859-1?Q?=08?=) Date: Wed, 18 Nov 2009 17:07:37 +0100 Message-ID: <1258560457-15129-2-git-send-email-jblunck@suse.de> References: <1258560457-15129-1-git-send-email-jblunck@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Linux-Kernel Mailinglist , Andrew Morton , jkacur@redhat.com, Thomas Gleixner , Jan Blunck , Arnd Bergmann , Christoph Hellwig , =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Weisbecker?= , Randy Dunlap To: linux-fsdevel@vger.kernel.org Return-path: Received: from cantor2.suse.de ([195.135.220.15]:37033 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757618AbZKRQHh (ORCPT ); Wed, 18 Nov 2009 11:07:37 -0500 In-Reply-To: <1258560457-15129-1-git-send-email-jblunck@suse.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: The inode's i_size is not protected by the big kernel lock. Therefore i= t 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_p= os. Signed-off-by: Jan Blunck Cc: Arnd Bergmann Cc: Christoph Hellwig Cc: Fr=C3=A9d=C3=A9ric Weisbecker Cc: John Kacur --- Documentation/filesystems/Locking | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/filesystems/Locking b/Documentation/filesyst= ems/Locking index 18b9d0c..25159d4 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 -semaphore. 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 modific= ations +since this is something the userspace has to take care about. =20 Note: ext2_release() was *the* source of contention on fs-intensive loads and dropping BKL on ->release() helps to get rid of that (we sti= ll --=20 1.6.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html