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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ