Excerpts from Sage Weil's message of 2011-09-16 12:39:06 -0400: > On Fri, 16 Sep 2011, Li Zefan wrote: > > It's a bug in commit f81c9cdc567cd3160ff9e64868d9a1a7ee226480 > > (Btrfs: truncate pages from clone ioctl target range) > > > > We should pass the dest range to the truncate function, but not the > > src range. > > Sigh... yes. > > > Also move the function before locking extent state. > > Hmm, any reason? i_mutex protects us from a racing write(2), but what > about a racing mmap()? e.g. > > cloner: truncates dest pages > writer: mmap -> page_mkwrite locks extent, creates new dirty page, unlocks > cloner: locks extent, clones, unlocks extent Thanks guys. The locking order is page lock -> extent lock. So if we call truncate_inode_pages with the extent lock held, we're off into ABBA. If we want to avoid the mmap race, we'll have to look for the dirty pages with the extent lock held, drop the lock and goto back to the truncate_inode_pages call. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
