Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753951AbcKRQrI (ORCPT ); Fri, 18 Nov 2016 11:47:08 -0500 Received: from mga01.intel.com ([192.55.52.88]:19086 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753693AbcKRQrF (ORCPT ); Fri, 18 Nov 2016 11:47:05 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,510,1473145200"; d="scan'208";a="1087177794" Subject: Re: [PATCH] x86: Add warning when memmap=nn!ss and CONFIG_RANDOMIZE_BASE enabled To: Thomas Gleixner References: <147941499514.131046.6450643991764692220.stgit@djiang5-desk3.ch.intel.com> Cc: Ingo Molnar , "H. Peter Anvin" , dan.j.williams@intel.com, x86@kernel.org, david@fromorbit.com, LKML , linux-nvdimm@ml01.01.org From: Dave Jiang Message-ID: Date: Fri, 18 Nov 2016 09:47:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1385 Lines: 42 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/18/2016 04:33 AM, Thomas Gleixner wrote: > On Thu, 17 Nov 2016, Dave Jiang wrote: >> CONFIG_RANDOMIZE_BASE can place the kernel anywhere. This causes >> a problem for when memmap=nn!ss is used. This information is not >> known until after the kernel starts executing and the decision >> for where the randomized base goes happens before the kernel is >> uncompressed. memmap=nn!ss is not reliable in the presence of >> CONFIG_RANDOMIZE_BASE. > > So this is a description of a problem. Now what's missing is a > useful explanation why you think that adding a warning will make > things better. > > IMNSHO adding that warning is just a pointless exercise. > > Why aren't you addressing the real issue and make the boot code > parse that option and prevent that region from being used for > kernel placement? > > The same issue exists for other memmap options as well, not just > for that PMEM thingy. > > Thanks, > > tglx > I wasn't planning to fix it because the pmem memmap option is really only used for testing. Is it possible to parse the kernel commandline parameters before the kernel is uncompressed? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlgvMIUACgkQZBXE8WajuT5aoAEAmXEJ0git9CwD4RhXV3+A/bmF CN1iLKoXHOvcpQ0FcDsA/j8UKmobWBHyswb6RCSu2uSqTt6XreMG7uNamT1eMt0J =hk/4 -----END PGP SIGNATURE-----