linux-kernel - Re: DRM lock ordering fix series

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]

Date:	Fri, 27 Mar 2009 09:19:27 -0700
From:	Eric Anholt <eric@...olt.net>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, dri-devel@...ts.sourceforge.net
Subject: Re: DRM lock ordering fix series

On Fri, 2009-03-27 at 10:34 +0100, Andi Kleen wrote:
> Eric Anholt <eric@...olt.net> writes:
> 
> > Here's hopefully the final attempt at the lock ordering fix for GEM.  The
> > problem was introduced in .29 with the GTT mapping support.  We hashed out
> > a few potential fixes on the mailing list and at OSTS.  Peter's plan was
> > to use get_user_pages, but it has significant CPU overhead (10% cost to text
> > rendering, though part of that is due to some dumb userland code.  But it's
> > dumb userland code we're all running).
> 
> 
> You are aware that there is a fast path now (get_user_pages_fast) which
> is significantly faster? (but has some limitations)

In the code I have, get_user_pages_fast is just a wrapper that calls the
get_user_pages in the way that I'm calling it from the DRM.

I'm assuming that that's changing.  Can you explain what the "some
limitations" is?  (Though, of course, in a comment in mm/util.c would be
better than email).

-- 
Eric Anholt
eric@...olt.net                         eric.anholt@...el.com



Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)