From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: i_mutex locking in generic_file_splice_write() Date: Thu, 12 Oct 2006 12:54:09 -0700 Message-ID: <20061012125409.40bd1fb1.akpm@osdl.org> References: <20061012190152.GU6485@ca-server1.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, Jens Axboe , Michael Halcrow Return-path: Received: from smtp.osdl.org ([65.172.181.4]:5012 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S1750710AbWJLTyf (ORCPT ); Thu, 12 Oct 2006 15:54:35 -0400 To: Mark Fasheh In-Reply-To: <20061012190152.GU6485@ca-server1.us.oracle.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 12 Oct 2006 12:01:52 -0700 Mark Fasheh wrote: > Hi, > generic_file_splice_write() will call into a file systems > ->prepare_write() and ->commit_write() via the the pipe_to_file() actor. > pipe_to_file() is careful to take the pipe inode i_mutex, but nowhere in the > call path do I see i_mutex on the inode being written to taken. I'm not sure that ecryptfs has full i_mutex coverage either. > Shouldn't we be taking this before calling into ->prepare_write() and > ->commit_write(). What's preventing generic_file_splice_write() from racing > a truncate? Or maybe even another write? The lock_page() will block truncate and will block write()s to this particular page. > A quick look through other callers reveals that generic_file_aio_write() and > do_lo_send_aops() both are careful to take i_mutex. I'm trying to remember what i_mutex actually protects in this context. i_size, certainly - if we go changing the file size without locks then other places might get surprised. For example, a concurrent write() at a larger file offset might try to increase i_size but if it loses the race against the unlocked i_size-changing thread, the inode ends up with the smaller i_size. So yup, we need i_mutex if only for that reason.