On Tue, Oct 11, 2011 at 11:01:57AM +0400, Dmitry Monakhov wrote: > > ext4_ext_walk_space() will get the i_data_sem, construct the path > > array, then release the semaphore. But then it does a bazillion > > accesses on the extent/header/index pointers in the path array, with > > no protection against truncate, growth, or any other changes. As far > > as I can tell, this is the only use of a path array retrieved from > > ext4_ext_find_extent() that isn't completely covered by i_data_sem. > > In that case i_data sem protects us from nothing. Path collected can > simply disappear under us. And in fact i don't understand the > reason why we drop i_data_sem too soon. Are any reason to do that? The one concern I have is that I don't want FIEMAP to slow down "real" ext4 processing. So what I've hoping we'll be able to do is use a seq_lock sort of design, where if the pointer changes out from under us, FIEMAP is forced to redo its sampling. But if there is some crazy userspace program which is calling FIEMAP all the time, I'd much rather that it not block ext4_map_blocks() if possible (which is what I using a seqlock to protect the FIEMAP routines would help). - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
