On Mon, Nov 21, 2011 at 09:55:07AM -0800, Ben Widawsky wrote: > On Mon, Nov 21, 2011 at 05:02:44PM +0100, Daniel Vetter wrote: > > On Sun, Nov 20, 2011 at 09:56:32PM -0800, Ben Widawsky wrote: > > [snip the patch] > > > Bikeshed, but I would much prefer a #define for the swizzle > > > bit/cacheline size. > > > > I've looked at this stuff way too long, so I'm biased, but 64 = cacheline > > = dram fetch size = 1 << 64 feels about as natural for me as 4096 = > > PAGE_SIZE ... > > > > [snip the patch] > > > > > I must be missing something obvious here... > > > Can you explain how this can possibly be considered safe without holding > > > struct_mutex? > > > > That's the reason why the commit msg goes through every case and explains > > why I think it's safe. The large thing here is that we need to drop the > > mutex when calling copy_*_user (at least in the non-atomic slow-paths) > > because otherwise we might deadlock with our own pagefault handler. > > -Daniel > > The part about dropping struct_mutex is clear to me. > > The bit that I'm missing, I just don't see how you guarantee the page > you're reading from (assuming it's a GTT mmapped page) doesn't get moved > from out under you. For instance if the page isn't there when you do the > initial __copy_from_user, it will get faulted in... cool - but what if > somewhere in that loop the object gets swapped out and something else is > put in it's place? How is that prevented? > > Sorry if it's a stupid question, I just don't get it. > Ben Okay, I got what I was missing from IRC. Anytime the object is unmapped we shoot down the userspace mapping. I couldn't find it in the code, but it turned out to be right in front of me. Reviewed-by: Ben Widawsky <ben at bwidawsk.net>
