On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
> <rmk+kernel@xxxxxxxxxxxxxxxx> wrote:
> > Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx>
> > ---
> > arch/arm/kernel/setup.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 77b54c461c52..d9317eec1eba 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
> > * zImage relocating below the reserved region.
> > */
> > #define CRASH_ALIGN (128 << 20)
> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> >
> > static inline unsigned long long get_total_mem(void)
> > {
> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
> > return;
> >
> > if (crash_base <= 0) {
> > - unsigned long long crash_max = CRASH_ADDR_MAX;
> > - if (crash_max > (u32)~0)
> > - crash_max = (u32)~0;
> > + unsigned long long crash_max = idmap_to_phys((u32)~0);
> > crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
> > crash_size, CRASH_ALIGN);
> > if (!crash_base) {
>
> Reviewed-by: Pratyush Anand <panand@xxxxxxxxxx>
>
> Unrelated to these modification:
> In function arch/arm/mm/init.c: arm_memblock_steal() may be following
> would be more appropriate?
> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));
No, arm_memblock_steal() is totally unsuitable. arm_memblock_steal()
*removes* the memory range from memblock, including removing the
mapping of that memory. It will make the memory range inaccessible to
the kernel.
Since kexec wants to write directly to this memory, using
arm_memblock_steal() will have the cause the kernel to OOPS when
it hits the resulting hole.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
