linux-kernel - Re: [PATCH 10/21] MIPS memblock: Discard bootmem allocator initialization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <780ca27f-d582-4911-a1a6-bd5c8792c587@imgtec.com>
Date:   Mon, 23 Jan 2017 08:55:27 +0100
From:   Marcin Nowakowski <marcin.nowakowski@...tec.com>
To:     Serge Semin <fancer.lancer@...il.com>, <ralf@...ux-mips.org>,
        <paul.burton@...tec.com>, <rabinv@...s.com>,
        <matt.redfearn@...tec.com>, <james.hogan@...tec.com>,
        <alexander.sverdlin@...ia.com>, <robh+dt@...nel.org>,
        <frowand.list@...il.com>
CC:     <Sergey.Semin@...latforms.ru>, <linux-mips@...ux-mips.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 10/21] MIPS memblock: Discard bootmem allocator
 initialization

Hi Serge,

On 19.12.2016 03:07, Serge Semin wrote:
> Bootmem allocator initialization needs to be discarded.
> PFN limit constants are still in use by some subsystems, so they
> need to be properly initialized. The initialization is moved into
> a separate method and performed with help of commonly used
> platform-specific constants. It might me too simplified, but most
> of the kernel platforms do it the same way. Moreover it's much
> easier to debug it, when it's not that complicated.
>
> Signed-off-by: Serge Semin <fancer.lancer@...il.com>
> ---
>  arch/mips/kernel/setup.c | 193 ++++-------------------------
>  1 file changed, 21 insertions(+), 172 deletions(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index e746793..6562f55 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -626,6 +626,25 @@ static void __init request_crashkernel(struct resource *res) { }
>  #endif /* !CONFIG_KEXEC */
>
>  /*
> + * Calcualte PFN limits with respect to the defined memory layout
> + */
> +static void __init find_pfn_limits(void)
> +{
> +	phys_addr_t ram_end = memblock_end_of_DRAM();
> +
> +	min_low_pfn = ARCH_PFN_OFFSET;
> +	max_low_pfn = PFN_UP(HIGHMEM_START);

This doesn't look right - as this may set max_low_pfn to more than the 
actual physical memory size. In some cases this might be a serious 
problem and it doesn't look like any other platform does that.
Even in MIPS code you can find uses of max_low_pfn that would be 
seriously affected by this change (vpe loader with 
CONFIG_MIPS_VPE_LOADER_TOM).

> +	max_pfn = PFN_UP(ram_end);
> +#ifdef CONFIG_HIGHMEM
> +	highstart_pfn = max_low_pfn;
> +	highend_pfn = max_pfn <= highstart_pfn ? highstart_pfn : max_pfn;
> +#endif
> +	pr_info("PFNs: low min %lu, low max %lu, high start %lu, high end %lu,"
> +		"max %lu\n",
> +		min_low_pfn, max_low_pfn, highstart_pfn, highend_pfn, max_pfn);
> +}
> +
> +/*
>   * Initialize the bootmem allocator. It also setup initrd related data
>   * if needed.
>   */



I fully agree with you that the current initialisation code is really 
complex and difficult to debug, but the modified one seems a bit too 
simplified.

Regards,
Marcin