On Sun, 18 Sep 2011, Chris Mason wrote: > 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. Oh right. This patch makes sense now. > 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. Yeah, given that (at Li points out) we're not locking dst extents at all, I don't think it's worth worrying about now. Sorry for the noise! sage -- 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
