linux-kernel - Re: [Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111121184356.GB18843@bolo_yeung.jf.intel.com>
Date:	Mon, 21 Nov 2011 10:43:57 -0800
From:	Ben Widawsky <ben@...dawsk.net>
To:	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to
 use copy_from_user

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@...dawsk.net>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/