[Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user

[Ben Widawsky]

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>