| 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
| ||
|
Message-ID: <20121029170436.GA6604@jshin-Toonie>
Date: Mon, 29 Oct 2012 12:04:36 -0500
From: Jacob Shin <jacob.shin@....com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC: Ben Hutchings <ben@...adent.org.uk>,
Mark Lord <kernel@...savvy.com>,
Yinghai Lu <yinghai@...nel.org>, Willy Tarreau <w@....eu>,
<stable@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: Regression from 3.4.9 to 3.4.16 "stable" kernel
On Mon, Oct 29, 2012 at 09:58:23AM -0700, Greg Kroah-Hartman wrote:
> On Mon, Oct 29, 2012 at 09:47:22AM -0500, Jacob Shin wrote:
> > On Mon, Oct 29, 2012 at 02:40:58PM +0000, Ben Hutchings wrote:
> > > On Mon, 2012-10-29 at 10:22 -0400, Mark Lord wrote:
> > > > On 12-10-29 02:46 AM, Willy Tarreau wrote:
> > > > > On Mon, Oct 29, 2012 at 12:03:55AM -0400, Mark Lord wrote:
> > > > >> My server here runs the 3.4.xx series of "stable" kernels.
> > > > >> Until today, it was running 3.4.9.
> > > > >> Today I tried to upgrade it to 3.4.16.
> > > > >> It hangs in setup.c.
> > > > >>
> > > > >> I've isolated the fault down to this specific change
> > > > >> that was made between 3.4.9 and 3.4.16.
> > > > >> Reverting this change allows the system to boot/run normally again.
> > > > >>
> > > > >>
> > > > >> --- linux-3.4.9/arch/x86/kernel/setup.c 2012-08-15 11:17:17.000000000 -0400
> > > > >> +++ linux-3.4.16/arch/x86/kernel/setup.c 2012-10-28 13:36:33.000000000 -0400
> > > > >> @@ -927,8 +927,21 @@
> > > > >>
> > > > >> #ifdef CONFIG_X86_64
> > > > >> if (max_pfn > max_low_pfn) {
> > > > >> - max_pfn_mapped = init_memory_mapping(1UL<<32,
> > > > >> - max_pfn<<PAGE_SHIFT);
> > > > >> + int i;
> > > > >> + for (i = 0; i < e820.nr_map; i++) {
> > > > >> + struct e820entry *ei = &e820.map[i];
> > > > >> +
> > > > >> + if (ei->addr + ei->size <= 1UL << 32)
> > > > >> + continue;
> > > > >> +
> > > > >> + if (ei->type == E820_RESERVED)
> > > > >> + continue;
> > > > >> +
> > > > >> + max_pfn_mapped = init_memory_mapping(
> > > > >> + ei->addr < 1UL << 32 ? 1UL << 32 : ei->addr,
> > > > >> + ei->addr + ei->size);
> > > > >> + }
> > > > >> +
> > > > >> /* can we preseve max_low_pfn ?*/
> > > > >> max_low_pfn = max_pfn;
> > > > >> }
> > > > >
> > > > > For the record, it is this commit introduced in 3.4.16 :
> > > > >
> > > > > commit efd5fa0c1a1d1b46846ea6e8d1a783d0d8a6a721
> > > > > Author: Jacob Shin <jacob.shin@....com>
> > > > > Date: Thu Oct 20 16:15:26 2011 -0500
> > > > >
> > > > > x86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct mapping.
> > > > >
> > > > > commit 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a upstream.
> > > > >
> > > > > On systems with very large memory (1 TB in our case), BIOS may report a
> > > > > reserved region or a hole in the E820 map, even above the 4 GB range. Exclude
> > > > > these from the direct mapping.
> > > > >
> > > > > [ hpa: this should be done not just for > 4 GB but for everything above the legacy
> > > > > region (1 MB), at the very least. That, however, turns out to require significant
> > > > > restructuring. That work is well underway, but is not suitable for rc/stable. ]
> > > > >
> > > > > Signed-off-by: Jacob Shin <jacob.shin@....com>
> > > > > Link: http://lkml.kernel.org/r/1319145326-13902-1-git-send-email-jacob.shin@amd.com
> > > > > Signed-off-by: H. Peter Anvin <hpa@...ux.intel.com>
> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > > >
> > > > > Willy
> > > >
> > > >
> > > > Thanks, Willy.
> > > >
> > > > I've also now downloaded linux-3.7.0-rc3, and it boots/runs without need for patching.
> > > > So there's a fix somewhere in between that perhaps could also get backported to -stable.
> > >
> > > Might well be:
> > >
> > > commit 1f2ff682ac951ed82cc043cf140d2851084512df
> > > Author: Yinghai Lu <yinghai@...nel.org>
> > > Date: Mon Oct 22 16:35:18 2012 -0700
> > >
> > > x86, mm: Use memblock memory loop instead of e820_RAM
> > >
> > > However I'm not sure that this loop is correct either. Yinghai, does
> > > your version definitely iterate in increasing pfn order? If not then
> > > the max_pfn_mapped assignment must be conditional.
> >
> > Hi, I believe these two commits in mainline should fix Alexander's failing
> > machien:
> >
> > 844ab6f993b1d32eb40512503d35ff6ad0c57030
> > f82f64dd9f485e13f29f369772d4a0e868e5633a
> >
> > This thread has some more details:
> >
> > https://lkml.org/lkml/2012/10/21/157
> >
> > Sorry, and thanks!
>
> Thanks, I've queued these up now.
Thanks,
And also unrelated to Alexander's panic, but related to the commit in question
1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a
These two commits from Yinghai should also be backported into stable, or I
think it is already in progress (I saw an email out to Yinghai saying that the
patch did not apply cleanly, and needs to be manually backported):
6ede1fd3cb404c0016de6ac529df46d561bd558b
1f2ff682ac951ed82cc043cf140d2851084512df
Right Yinghai?
Thanks!
-Jacob
>
> greg k-h
>
--
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