linux-kernel - Re: [PATCH 34/49] gma500: the GEM and GTT code is device independant

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: <CAMeQTsYYfBs+Z=2NZqN-9X=XpCT5cboA3DL0=FM0zr6a=ztAUA@mail.gmail.com>
Date:	Wed, 12 Oct 2011 14:03:10 +0200
From:	Patrik Jakobsson <patrik.r.jakobsson@...il.com>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rob Clark <rob.clark@...aro.org>, greg@...ah.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 34/49] gma500: the GEM and GTT code is device independant

On Mon, Oct 10, 2011 at 8:37 PM, Hugh Dickins wrote:
> I was surprised to see drivers/staging/gma500 appearing still to use
> read_cache_page_gfp().  I assumed that since nobody was complaining,
> it must be on a currently unusable path.  But you have code coming up,
> that now enables that path?

Yes, I have a couple of patches for getting SDVO to properly set up DDC.
It seems we hit that path when framebuffer size exceeds a certain limit.

> Am I right to think that your immediate problem is just the oops in
> __read_cache_page(), that you're not yet about to hit the 4GB issue?

Correct, I have only seen 1GB and 2GB platforms so far. But the driver
does support platforms that I haven't got my hands on yet.

> I haven't rushed to address the 4GB issue, but what I have in mind is
> killing two-and-a-half birds with one stone, by putting a little cookie
> into the swapper_space radix_tree when we free a swapcache page, that
> specifies node/zone and hashes object/offset.
>
> NUMA mempolicies are too complex to be encapsulated in a sizeof(long)
> cookie, but it should improve the common case after swapin; while
> solving your 4GB GEM case, and vastly speeding up swapoff.
>
> Here's the kind of patch I imagined would be going in for gma500, that
> specifies __GFP_DMA32 on the mapping, so even swapoff can know that
> this object needs its pages below 4GB (even before my recent changes,
> swapoff would have broken you by inserting higher pages in the cache)
> - once I implement that.  But I've not tested this patch at all...

There are some other issues with SDVO when running at higher resolutions
that triggers the path. Will test your patch as soon as I get those things
sorted out, though it looks ok to me.

Thanks
Patrik
--
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/