Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752050AbbB1TUQ (ORCPT ); Sat, 28 Feb 2015 14:20:16 -0500 Received: from mail-wi0-f169.google.com ([209.85.212.169]:45878 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750808AbbB1TUN (ORCPT ); Sat, 28 Feb 2015 14:20:13 -0500 Date: Sat, 28 Feb 2015 19:20:09 +0000 From: Matt Fleming To: Borislav Petkov Cc: "H. Peter Anvin" , Kees Cook , Jiri Kosina , Ingo Molnar , Huang Ying , LKML , LKP ML , x86-ml , Dave Young , Andy Lutomirski Subject: Re: [LKP] [x86/mm/ASLR] f47233c2d34: WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:63 __ioremap_check_ram+0x445/0x4a0() Message-ID: <20150228192009.GA2727@codeblueprint.co.uk> References: <1424929021.10337.24.camel@intel.com> <20150226103040.GA3573@pd.tnic> <20150226111250.GA32024@gmail.com> <20150226121617.GB3573@pd.tnic> <20150228105049.GA11038@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150228105049.GA11038@pd.tnic> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1320 Lines: 28 On Sat, 28 Feb, at 11:50:49AM, Borislav Petkov wrote: > > Yeah, too many hmms means this still needed staring at to find out what > exactly the problem is. And the problem is that allocating that struct > setup_data statically in arch/x86/boot/compressed/aslr.c works only by > chance, when the kernel decompressing doesn't overwrite that memory. Doing a static allocation is fine, and the memory is even reserved from being overwritten via memblock_x86_reserve_range_setup_data(), but it looks like that reservation gets dropped before get_setup_data_total_num() runs, which is what is causing ioremap() to complain - it really is usable RAM we're trying to ioremap(). Dropping the reservation looks to happen in memblock_x86_fill(), because you'll note that we explicitly reserve the boot services regions immediately after memblock_x86_fill() in setup_arch(). What isn't clear right now is why the ioremap() warning isn't triggering for a bunch of other callsites that get this wrong, i.e. pcibios_add_device(). -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/