[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131129083551.GB4186@dhcp-16-126.nay.redhat.com>
Date: Fri, 29 Nov 2013 16:35:52 +0800
From: Dave Young <dyoung@...hat.com>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
x86@...nel.org, mjg59@...f.ucam.org, hpa@...or.com,
James.Bottomley@...senPartnership.com, vgoyal@...hat.com,
ebiederm@...ssion.com, horms@...ge.net.au,
kexec@...ts.infradead.org, greg@...ah.com, matt@...sole-pimps.org,
toshi.kani@...com
Subject: Re: [PATCH v4 11/12] x86: reserve setup_data ranges late after
parsing memmap cmdline
On 11/27/13 at 04:07pm, Borislav Petkov wrote:
> On Tue, Nov 26, 2013 at 01:57:56PM +0800, Dave Young wrote:
> > Kdump kernel using memmap=exactmap, move e820_reserve_setup_data after
> > parsing early params so they can be set reserved finally. Or kdump kernel
> > will warn about ioremap a normal ram range.
>
> I had to stare for a while at this commit message, rereading it a couple
> of times and looking at the code in order to understand why you're
> moving the call further down.
>
> Please rewrite it into something more readable.
>
> The usual structure which you could use is:
>
> 1. Currently we have A
> 2. We need B
> 3. In order to achieve it, we do C
>
> or something to that effect.
Is below changes ok to you?
Currently e820_reserve_setup_data is called before parsing early params,
it works in normal case. But for memmap=exactmap, the final memory ranges
are created after parsing memmap= cmdline params, so the previous
e820_reserve_setup_data has no effect. For example for setup_data ranges
will still be marked as normal system ram, thus when later sysfs driver
ioremap them kernel will warn about mapping normal ram.
This patch fix it by moving the e820_reserve_setup_data callback after
parsing early params so they can be set as reserved ranges and later
ioremap will be fine with it.
Thanks
Dave
--
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