From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752795AbbBKMLy (ORCPT ); Wed, 11 Feb 2015 07:11:54 -0500 Received: from mail.skyhub.de ([78.46.96.112]:41977 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752252AbbBKMLx (ORCPT ); Wed, 11 Feb 2015 07:11:53 -0500 Date: Wed, 11 Feb 2015 13:11:15 +0100 From: Borislav Petkov To: Dave Hansen Cc: linux-kernel@vger.kernel.org, x86@kernel.org, dave.hansen@linux.intel.com Subject: Re: [RFC][PATCH] x86: nit: wrong page size in init_memory_mapping() printks Message-ID: <20150211121114.GB3650@pd.tnic> References: <20150210212030.665EC267@viggo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150210212030.665EC267@viggo.jf.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 10, 2015 at 01:20:30PM -0800, Dave Hansen wrote: > > From: Dave Hansen > > With 32-bit non-PAE kernels, we have 2 page sizes available > (at most): 4k and 4M. > > Enabling PAE replaces that 4M size with a 2M one (which 64-bit > systems use too). > > But, when booting a 32-bit non-PAE kernel, in one of our > early-boot printouts, we say: > > [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff] > [ 0.000000] [mem 0x00000000-0x000fffff] page 4k > [ 0.000000] init_memory_mapping: [mem 0x37000000-0x373fffff] > [ 0.000000] [mem 0x37000000-0x373fffff] page 2M > [ 0.000000] init_memory_mapping: [mem 0x00100000-0x36ffffff] > [ 0.000000] [mem 0x00100000-0x003fffff] page 4k > [ 0.000000] [mem 0x00400000-0x36ffffff] page 2M > [ 0.000000] init_memory_mapping: [mem 0x37400000-0x377fdfff] > [ 0.000000] [mem 0x37400000-0x377fdfff] page 4k > > Which is obviously wrong. There is no 2M page available. This > is probably because of a badly-named variable: in the map_range > code: PG_LEVEL_2M. > > Instead of renaming all the PG_LEVEL_2M's. This patch just > fixes the printout: > > [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff] > [ 0.000000] [mem 0x00000000-0x000fffff] page 4k > [ 0.000000] init_memory_mapping: [mem 0x37000000-0x373fffff] > [ 0.000000] [mem 0x37000000-0x373fffff] page 4M > [ 0.000000] init_memory_mapping: [mem 0x00100000-0x36ffffff] > [ 0.000000] [mem 0x00100000-0x003fffff] page 4k > [ 0.000000] [mem 0x00400000-0x36ffffff] page 4M > [ 0.000000] init_memory_mapping: [mem 0x37400000-0x377fdfff] > [ 0.000000] [mem 0x37400000-0x377fdfff] page 4k > [ 0.000000] BRK [0x03206000, 0x03206fff] PGTABLE > > > Signed-off-by: Dave Hansen Looks ok to me considering that we're missing a PG_LEVEL_4M thing completely which would need to be handled depending on X86_PAE and CR4 PSE and PAE bits. Probably not worth the trouble though. Acked-by: Borislav Petkov -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --