On Mon, Jul 23, 2012 at 02:20:57PM +0200, Lukáš Czerner wrote:
[cut...]

quoted

quoted

Moreover I think that we should avoid taking i_mutex if we can and I
believe that we can in this case, because we only need to prevent
allocation. So I just want to let you know that this part is
probably going to change anyway.

It seems that we need to take i_mutex locking to prevent from buffered
writes after page cache has been truncated by truncate_pagecache_range.
If a buffered write without delalloc occurs after truncating page cache
and before taking i_data_sem, that means that the allocated block for
this buffered write will be removed in ext4_ext_remove_space when the
offset is within the range of the hole.  Am I missing something?

You're absolutely right, currently this is possible. But I think that we
can take i_data_sem before truncating the pagecache hence preventing anyone
from mapping new blocks. However this is not yet implemented in my
patch set.

...
hmm, looking at the ext4_write_begin() it seems like it might not be
such good idea after all. It seems to take page lock before
i_data_sem so we might get deadlock, moreover if the punch hole
happened in the middle of the ext4_write_begin() we might have only
part of the data written, moreover this does not have to be hole
aligned, which is bad. I need to revise that.

Yes, this is why I think that i_mutex locking should be taken.  At least
we are safty when we take the i_mutex. :-)

Regards,
Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html