| Message ID | 1361805410-8664-1-git-send-email-will.deacon@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Will, On Monday 25 February 2013 08:46 PM, Will Deacon wrote: > When creating our initial mappings, we call alloc_init_pud, which > simply defers to alloc_init_section for mappings at the pmd level. > > However, the physical address passed to alloc_init_pud is potentially > truncated to unsigned long, which could cause problems on systems making > use of LPAE. > > This patch fixes the function prototype to use phys_addr_t. > > Cc: <stable@vger.kernel.org> > Signed-off-by: Will Deacon <will.deacon@arm.com> > --- There is already a similar patch [1] on list which was suppose to get merged in 3.9 from Cyril's series [2] Regards, Santosh [1] https://lkml.org/lkml/2013/1/31/491 [2] http://www.spinics.net/lists/arm-kernel/msg221994.html
On Tue, Feb 26, 2013 at 08:42:46AM +0000, Santosh Shilimkar wrote: > Will, Hi Santosh, > On Monday 25 February 2013 08:46 PM, Will Deacon wrote: > > When creating our initial mappings, we call alloc_init_pud, which > > simply defers to alloc_init_section for mappings at the pmd level. > > > > However, the physical address passed to alloc_init_pud is potentially > > truncated to unsigned long, which could cause problems on systems making > > use of LPAE. > > > > This patch fixes the function prototype to use phys_addr_t. > > > > Cc: <stable@vger.kernel.org> > > Signed-off-by: Will Deacon <will.deacon@arm.com> > > --- > There is already a similar patch [1] on list which was suppose > to get merged in 3.9 from Cyril's series [2] Nice, that series contains a number of similar fixes too. However, I can't see anywhere destined for upstream. Cyril -- what's the status on this branch? Cheers, Will
On Tuesday 26 February 2013 05:47 PM, Will Deacon wrote: > On Tue, Feb 26, 2013 at 08:42:46AM +0000, Santosh Shilimkar wrote: >> Will, > > Hi Santosh, > >> On Monday 25 February 2013 08:46 PM, Will Deacon wrote: >>> When creating our initial mappings, we call alloc_init_pud, which >>> simply defers to alloc_init_section for mappings at the pmd level. >>> >>> However, the physical address passed to alloc_init_pud is potentially >>> truncated to unsigned long, which could cause problems on systems making >>> use of LPAE. >>> >>> This patch fixes the function prototype to use phys_addr_t. >>> >>> Cc: <stable@vger.kernel.org> >>> Signed-off-by: Will Deacon <will.deacon@arm.com> >>> --- >> There is already a similar patch [1] on list which was suppose >> to get merged in 3.9 from Cyril's series [2] > > Nice, that series contains a number of similar fixes too. However, I can't > see anywhere destined for upstream. > I remember seeing a pull request [2] from Cyril sent to Russell. Regards Santosh [2] http://www.spinics.net/lists/arm-kernel/msg221994.html
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index e95a996..754c37f 100644 --- a/arch/arm/mm/mmu.c +++ b/arch/arm/mm/mmu.c @@ -634,7 +634,7 @@ 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) { pud_t *pud = pud_offset(pgd, addr); unsigned long next;
When creating our initial mappings, we call alloc_init_pud, which simply defers to alloc_init_section for mappings at the pmd level. However, the physical address passed to alloc_init_pud is potentially truncated to unsigned long, which could cause problems on systems making use of LPAE. This patch fixes the function prototype to use phys_addr_t. Cc: <stable@vger.kernel.org> Signed-off-by: Will Deacon <will.deacon@arm.com> --- arch/arm/mm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)