On Fri, May 21, 2010 at 09:50:54AM -0400, Josef Bacik wrote: > On Fri, May 21, 2010 at 09:05:24AM +1000, Dave Chinner wrote: > > Allocating multipage writes as unwritten extents turns off delayed > > allocation and hence we'd lose all the benefits that this gives... > > > > I just realized we have another problem, the mmap_sem/page_lock deadlock. > Currently BTRFS is susceptible to this, since we don't prefault any of the pages > in yet. If we're going to do multi-page writes we're going to need to have a > way to fault in all of the iovec's at once, so when we do the > pagefault_disable() copy pagefault_enable() we don't just end up copying the > first iovec. Nick have you done something like this already? If not I assume > I can just loop through all the iovec's and call fault_in_pages_readable on all > of them and be good to go right? Thanks, Yes, well it's a different issue. With multi-page writes, even a single iovec may not be faulted in properly. And with multiple iovecs, we are already suboptimal with faulting. faulting in multiple iovecs may already be a good idea. I didn't add that code, I had hoped for a test case first, but perhaps we can just go and add it. With multipage writes, we would want to fault in multiple source pages at once if the design was to lock multiple pages at once and do the copy. I still think we might be able to just lock and copy one page at a time, but I could be wrong. Oh wow, btrfs is deadlocky there. Firstly, fault_in_pages_readable does not guarantee success (race can always unmap the page in the meantime). Secondly, calling it inside the page lock section just means it will cause the deadlock rather than the copy_from_user. Quick workaround to reduce probability is to do fault_in_pages_readable calls before locking the pages. But you really need to handle the short-copy case. From the error handling there, it seems like you can just free_reserved_data_space and retry the copy? -- 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
