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: <20111121175503.GA18843@bolo_yeung.jf.intel.com>
Date:	Mon, 21 Nov 2011 09:55:07 -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 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
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ