linux-kernel - Re: S4 resume broken since 2.6.39 (3.1, too)

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: <4E813986.9040400@oracle.com>
Date:	Mon, 26 Sep 2011 19:48:38 -0700
From:	Yinghai Lu <yinghai.lu@...cle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>, Takashi Iwai <tiwai@...e.de>,
	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	oneukum@...e.de, x86@...nel.org,
	Linux PM mailing list <linux-pm@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: S4 resume broken since 2.6.39 (3.1, too)

On 09/26/2011 03:47 PM, Linus Torvalds wrote:

> On Mon, Sep 26, 2011 at 3:24 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
>>
>> So, in my opinion we should simply apply the Takashi's patch at this
>> point and revisit the kdump issue later, when we actually know how to do
>> the right thing.
> 
> Applying that trivial patch certainly looks fine, especially since it
> also avoids some arbitrary differences between x86-64 and x86-32.
> 
> That said, the whole code looks *very* confusing, and I have to say
> that the commit logs there are also totally unreadable and not very
> explanatory at all.


sorry for that.

> 
> It does seem like the code is simply buggy: it "allocates" the page
> tables from the end of memory, but it seems to want to do that before
> they have been mapped. Which makes perfect sense, since the whole
> point of allocating them is to be *able* to map all the memory.

> 

> So using that
> 
>     good_end = max_pfn_mapped << PAGE_SHIFT;
> 
> would seem to be a good idea regardless. I'm not sure how the old code
> is even supposed to work. That said - why is this a problem only for
> S4 resume?


and for S4 resume, according to Takashi, that commit is ok with 2.6.37. but start to have some problem (1/20 chance) from 2.6.39...

will check if any other early page-table related commit could cause the problem.

the main point for that commit: it will "allocate" range for page-table purpose and will use early_memremap before really accessing them.
so could have the end above already mapped max address.

so We can avoid to put page_table in the middle of low ram ( just below 512m ), and could have bigger continuous range for kdump kernel.

Thanks

Yinghai

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