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  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:	Sat, 17 Jul 2010 21:58:54 +0300
From:	"M. Vefa Bicakci" <>
To:	Linus Torvalds <>
CC:	Dave Airlie <>,
	Chris Wilson <>,,
	Roman Jarosz <>,,,,
	"A. Boulan" <>,
	Hugh Dickins <>,
	Pekka Enberg <>,
	A Rojas <>,
	KOSAKI Motohiro <>,,,
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim

On 02/07/10 04:28 AM, Linus Torvalds wrote:
> On Thu, Jul 1, 2010 at 5:49 PM, Dave Airlie <> wrote:
>> RECLAIMABLE added also seems fine, of course you can't have
>> RECLAIMABLE and MOVABLE (I find this out when it oopses on boot).
> Yes. They are both flags for the anti-fragmentation code, and I think
> I'll leave the decision as to whether the i915 driver should use
> __GFP_RECLAIMABLE to the people who work with and care about the
> fragmentation issues. I doubt it matters much in practice, at least
> not for the loads that the fragmentation people tend to care most
> about.
>> So I suspect MOVABLE is the problem. but I don't know enough about gfp
>> flags to know what RECLAIMABLE buys us, and where it  might bite us so
>> I can test some more.
> I think I'll just apply your previous tested patch - GFP_HIGHUSER
> should take care of all the flags that matter fundamentally, and then
> the reclaimable flag is really just a small detail for others to worry
> about.

Dear Linus,

I have bad news regarding your fix for self-reclaim and i915.

Apparently, I haven't tried enough hibernate/thaw cycles while
initially testing your fix.

After applying your fix to and using it for two weeks,
I noticed that every now and then I get a black screen or random
kernel errors after thawing. I thought maybe this might be the
same problem caused by d8e0902806c0bd2ccc4f6a267ff52565a3ec933b .
(It turns out that my guess was right.)

So I compiled two vanilla kernels. One with
d8e0902806c0bd2ccc4f6a267ff52565a3ec933b reverted to get back
to pre state, and another one with your fix applied.

Then I set up an automated process where the computer would
hibernate, and reboot at the end of the hibernation sequence
(by setting /sys/power/disk to reboot) and then thaw back.
I made this process loop at least 20 times.

The kernel with d8e0902806c0bd2ccc4f6a267ff52565a3ec933b reverted
was able to hibernate/thaw at least 40 times in one go, while
the one with your fix applied was able to hibernate/thaw at most
17 times (in two separate trials) after which it crashed during
the next thaw.

Is there anything I can do find out the correct flags to use
in addition to GFP_HIGHUSER ? Can I do something like a bisection
for the flags one by one starting from the pre state?
If you could outline a procedure to do this, I would be glad to
follow it.

Sorry to bug you again about this problem because of incomplete
testing on my part.


M. Vefa Bicakci
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists