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: <201109270024.55418.rjw@sisk.pl>
Date:	Tue, 27 Sep 2011 00:24:55 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Yinghai Lu <yinghai.lu@...cle.com>
Cc:	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>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: S4 resume broken since 2.6.39 (3.1, too)

On Thursday, September 22, 2011, Yinghai Lu wrote:
> On Wed, Sep 21, 2011 at 11:48 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> > It looks like init_memory_mapping() is sometimes called with "end"
> > beyond the last mapped PFN and it explodes when we try to write stuff to
> > that address during image restoration.
> >
> > IOW, the Yinghai's assumption that init_memory_mapping() would always be
> > called with a "good end" on x86_64 was overomptimistic.
> 
> for 64bit x86, kernel_physical_mapping_init() will use
> map_low_page()/call early_memmap() to access ram for page_table that is above
> rather last mapped PFN.
> 
> the point is:
> on system with 64g, usable ram will be [0,2048m), [4g, 64g)
> init_memory_mapping will be called two times for them.
> before putting page_table high,
> page table will be two parts: one is just below 512M, and one below 2048m.
> after putting page_table high,
> page table will be two parts: one is just below 2048M, and one below 64G.
> 
> one of the purposes is finding biggest continuous big range under
> 1024m for kdump.

This is all fine so long as we can ensure that the "end" value we're
passing to init_memory_mapping() will always be a valid address, which
evidently is not the case sometimes.

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.

Thanks,
Rafael
--
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/