On Thu, 12 Oct 2006 12:01:52 -0700 Mark Fasheh <mark.fasheh@xxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
