linux-kernel - Re: [RFC] [PATCH] DRM TTM Memory Manager patch

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:	Thu, 03 May 2007 21:07:01 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Thomas Hellström <thomas@...gstengraphics.com>
Cc:	keithp@...thp.com, Eric Anholt <eric@...olt.net>,
	dri-devel@...ts.sourceforge.net, Dave Airlie <airlied@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [RFC] [PATCH] DRM TTM Memory Manager patch

On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:

> It might be possible to find schemes that work around this. One way 
> could possibly be to have a buffer mapping -and validate order for 
> shared buffers.

If mapping never blocks on anything other than the fence, then there
isn't any dead lock possibility. What this says is that ordering of
rendering between clients is *not DRMs problem*. I think that's a good
solution though; I want to let multiple apps work on DRM-able memory
with their own CPU without contention.

I don't recall if Eric layed out the proposed rules, but:

 1) Map never blocks on map. Clients interested in dealing with this 
    are on their own.

 2) Submit blocks on map. You must unmap all buffers before submitting
    them. Doing the relocations in the kernel makes this all possible.

 3) Map blocks on the fence from submit. We can play with pending the
    flush until the app asks for the buffer back, or we can play with
    figuring out when flushes are useful automatically. Doesn't matter
    if the policy is in the kernel.

I'm interested in making deadlock avoidence trivial and eliminating any
map-map contention.

-- 
keith.packard@...el.com

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