linux-kernel - Re: CONFIG_NUMA breaks hibernation on x86-32 with PAE

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, 11 Nov 2008 16:03:42 +0100
From:	Pavel Machek <pavel@...e.cz>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	kernel list <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: CONFIG_NUMA breaks hibernation on x86-32 with PAE


> > > It is.  However, the problem is 100% reproducible on any 32-bit single-node
> > > system with CONFIG_NUMA set, from what I can tell.
> > > 
> > > It doesn't happen if the kernel is booted with highmem=0, so it looks like
> > > the code that saves highmem causes the problem to happen.  However, this
> > > same code works well for all of the !CONFIG_NUMA cases and practically only
> > > the only non-open-coded it uses is kmap_atomic().
> > > 
> > > > One possibility would be to bisect if it ever worked?
> > > 
> > > Not sure it did, probably not. :-(
> > 
> > Well, interesting point would be just before this commit:
> > 
> > 
> > commit 8357376d3df21b7d6f857931a57ac50da9c66e26 
> > tree daf2c369e9b79d24c1666323b3ae75189e482a4a 
> > parent bf73bae6ba0dc4bd4f1e570feb34a06b72725af6 
> > author Rafael J. Wysocki <rjw@...k.pl> Wed, 06 Dec 2006 20:34:18 -0800 
> > committer Linus Torvalds <torvalds@...dy.osdl.org> Thu, 07 Dec 2006
> > 08:39:27 -0800 
> > 
> >     [PATCH] swsusp: Improve handling of highmem
> >     
> >     Currently swsusp saves the contents of highmem pages by copying
> > them to the
> >     normal zone which is quite inefficient (eg.  it requires two
> > normal pages
> >     to be used for saving one highmem page).  This may be improved by
> > using
> >     highmem for saving the contents of saveable highmem pages.
> > 
> > ...highmem handling was way simpler in those good old days ;-)
> 
> Please stop kidding, this is a serious issue.
> 
> The hibernation code _works_ with all kinds of highmem when CONFIG_NUMA is
> unset.

And it does not work with single highmem page when NUMA is set... I
went through the highmem saving code, and it depends on highmem not
changing from  under it (right?) and is generally quite tricky ('if
they are both in highmem do this, else if one of them is do that, else
do something else') and it changes page protections on the fly, etc.

I'm not saying the bug is in that code, but before that commit we had
very stupid --- but very robust -- code. I'll try if that one works
with config_numa, perhaps we can get some debug info that way.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/