linux-kernel - Re: [PATCH v4 02/13] ARM: LPAE: use phys_addr_t in alloc_init

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]

Date:	Thu, 31 Jan 2013 22:35:47 -0500 (EST)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Hui Wang <jason77.wang@...il.com>
cc:	Cyril Chemparathy <cyril@...com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	marc.zyngier@....com, sboyd@...eaurora.org,
	linus.walleij@...aro.org, Will Deacon <will.deacon@....com>,
	Vitaly Andrianov <vitalya@...com>,
	Catalin Marinas <catalin.marinas@....com>,
	paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH v4 02/13] ARM: LPAE: use phys_addr_t in
 alloc_init_pud()

On Fri, 1 Feb 2013, Hui Wang wrote:

> Cyril Chemparathy wrote:
> > From: Vitaly Andrianov <vitalya@...com>
> > 
> > This patch fixes the alloc_init_pud() function to use phys_addr_t instead of
> > unsigned long when passing in the phys argument.
> > 
> > This is an extension to commit 97092e0c56830457af0639f6bd904537a150ea4a
> > (ARM:
> > pgtable: use phys_addr_t for physical addresses), which applied similar
> > changes
> > elsewhere in the ARM memory management code.
> > 
> > Signed-off-by: Vitaly Andrianov <vitalya@...com>
> > Signed-off-by: Cyril Chemparathy <cyril@...com>
> > Acked-by: Nicolas Pitre <nico@...aro.org>
> > Acked-by: Catalin Marinas <catalin.marinas@....com>
> > ---
> >  arch/arm/mm/mmu.c |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > index 9f06102..ef43689 100644
> > --- a/arch/arm/mm/mmu.c
> > +++ b/arch/arm/mm/mmu.c
> > @@ -612,7 +612,8 @@ static void __init alloc_init_section(pud_t *pud,
> > unsigned long addr,
> >  }
> >   static void __init alloc_init_pud(pgd_t *pgd, unsigned long addr,
> > -	unsigned long end, unsigned long phys, const struct mem_type *type)
> > +				  unsigned long end, phys_addr_t phys,
> > +				  const struct mem_type *type)
> >   
> The change is correct but seems useless so far. This function only be called
> from map_lowmem and devicemaps_init, from i know neither lowmem nor device io
> registers of existing platforms exceed 32bit address.

It is not because you are not aware of any existing platforms with RAM 
or device IO above the 4GB mark that they don't exist.

For example, some LPAE systems have all their RAM located above the 4G 
physical address mark. A simple (potentially non DMA capable) alias 
exists in the low 32-bit address space to allow the system to boot and 
switch to the real physical RAM addresses once the MMU is turned on.  
Some of that RAM is still qualified as "low mem" i.e. the portion of RAM 
that the kernel keeps permanently mapped in the 32-bit virtual space 
even if all of it is above the 4G mark in physical space.


Nicolas
--
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/