linux-kernel - Re: [PATCH 14/15] gma500: nuke the PSB debug stuff

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: <20110613193532.GB2761@phenom.ffwll.local>
Date:	Mon, 13 Jun 2011 21:35:32 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Daniel Vetter <daniel@...ll.ch>,
	Patrik Jakobsson <patrik.r.jakobsson@...il.com>,
	Dave Airlie <airlied@...hat.com>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, greg@...ah.com
Subject: Re: [PATCH 14/15] gma500: nuke the PSB debug stuff

On Mon, Jun 13, 2011 at 04:44:03PM +0100, Alan Cox wrote:
> > Given that I've mucked around in drm_mm quite a bit I'd be very interested
> > in your opinion about what's weird in it (and presumably what could be
> > improved). Can you elaborate?
> 
> Mostly the API, which is also somewhat poorly documented. I've not dug
> into the internals beyond trying to figure out how to use it. Looking at
> the users the API is non-obvious, the interface involves a mix of calls
> and digging deep into struct internals.

Well, I've rewritten the api but that transition is not yet complete, i.e.
the new interface is there, but no driver is converted yet. The old api
has a two-step allocation (search_free + get_block) and frees allocated
ranges with put_block. The new api has just insert_node and remove_node,
struct drm_mm_node must be allocated by the caller (to get rid of the racy
preallocation scheme and allow embedding of drm_mm_node).

There's also the lru scanning helpers (only used by intel). Under specific
conditions (should be all documented in comments) this can be used as an
eviction roaster.

Generally only node->start should be used by drivers, otherwise
drm_mm_node should be opaque. At least that's the idea.

btw, old conversion patches for i915 to the new interface are at:

http://cgit.freedesktop.org/~danvet/drm/log/?h=embed-gtt-space

When creating the new interfaces I've tried to document them. Ideas to
improve that highly welcome.

> I'd have expected an API that had allocate/free type methods and exposed
> the needed information directly or very easily not one that has drivers
> doing. drm_sman seems to be attempt in that direction but its also rather
> odd with interfaces like

Should be fixed, see above ;-)

[snip]

> Possibly drm_sman and friends should just wrap whatever simple native
> allocator exists on the OS ?

Well, drm_mm has some graphics specific magic (range restricted scans and
the eviction helpers). But simpler stuff like sman is imo just "drm likes
to reinvent the wheel". Unfortunately I don't have the hw, so I haven't
dared to touch it (the snippet you've posted is a prime example why).

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel@...ll.ch
Mobile: +41 (0)79 365 57 48
--
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/