Re: i_mutex locking in generic_file_splice_write()

[Andrew Morton <akpm@osdl.org>]

On Thu, 12 Oct 2006 12:01:52 -0700
Mark Fasheh <mark.fasheh@oracle.com> 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.