linux-kernel - Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim

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: <AANLkTilOWu6ZwWjwPfHvNXDhyjb6n4N5KV1rUx6byJmq@mail.gmail.com>
Date:	Fri, 2 Jul 2010 10:06:23 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"M. Vefa Bicakci" <bicave@...eronline.com>,
	Chris Wilson <chris@...is-wilson.co.uk>, earny@...4u.de,
	Roman Jarosz <kedgedev@...il.com>,
	intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	jcnengel@...glemail.com,
	"A. Boulan" <arnaud.boulan@...ertysurf.fr>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Pekka Enberg <penberg@...helsinki.fi>,
	A Rojas <nqn1976list@...il.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	rientjes@...gle.com, michael@...nelt.co.at, stable@...nel.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim

On Fri, Jul 2, 2010 at 9:59 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, Jul 1, 2010 at 3:34 PM, M. Vefa Bicakci <bicave@...eronline.com> wrote:
>>
>> Based on my testing, I am happy to report that the change you suggest
>> fixes the "memory corruption (segfaults) after thaw" issue for me.
>> I can't thank you enough times for this.
>
> Hey, goodie. And you're the one to be thanked - bisecting it down to
> that commit that wasn't _meant_ to have any real semantic changes
> (except for the bug-fix of racy mapping gfp-flags update) is what
> really cracked the lid on the problem.
>
>> Now, the obligatory question: Could we have this fix applied to 2.6.32,
>> 2.6.33 and 2.6.34 ?
>
> No problem, except we should first determine exactly what flags are
> the appropriate ones. My original patch was obviously not even
> compile-tested, and I actually meant for people to use GFP_HIGHUSER
> rather than __GFP_HIGHMEM. That contains all the "regular" allocation
> flags (but not the __GFP_MOVABLE, which is still just a suspicion of
> being the core reason for the problem).
>
> And the original DRM code had:
>
>   GFP_HIGHUSER |
>   __GFP_COLD |
>   __GFP_FS |
>   __GFP_RECLAIMABLE |
>   __GFP_NORETRY |
>   __GFP_NOWARN |
>   __GFP_NOMEMALLOC
>
> which is not entirely sensible (__GFP_FS is already part of
> GFP_HIGHUSER, for example), and two of the flags (NORETRY and NOWARN)
> are the ones the driver wants to do conditionally.
>
> But that still leaves the question about __GFP_COLD (probably sane),
> __GFP_RECLAIMABLE (I wonder about that one) and __GFP_NOMEMALLOC
> (usually used together with NORETRY, and I'm not at all sure it makes
> sense as a base flag).
>
> So I suspect the final patch should not look like the one you tested,
> but instead likely have
>
>   GFP_HIGHUSER | __GFP_COLD
>
> and possibly the __GFP_RECLAIMABLE flag too instead of just the bare
> __GFP_HIGHMEM..
>
> (Well, we already had that __GFP_COLD there from before, so it's
> really about replacing __GFP_HIGHMEM with something like "GFP_HIGHUSER
> | __GFP_RECLAIMABLE").
>
> But its' great to hear that this does seem to be the underlying cause.
> If you could test with that GFP_HIGHUSER | __GFP_RECLAIMABLE, that
> would be a good thing. After all - maybe the problem was triggered by
> some other flag than __GFP_MOVABLE, and as such, having some
> additional testing with a bigger set of allocation flags would be a
> really good thing.

I just sent a patch I tested here with GFP_HIGHUSER | __GFP_COLD
instead, and it resumes okay for me,

I'll play with GFP_RECLAIMABLE now,

If anyone wants to know why nobody uses hibernate, this laptop with a
4200rpm driver boots faster than the hibernate cycle.

Dave.
--
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/