| Message ID | 1480445729-27130-9-git-send-email-labbott@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 11/29/2016 09:55 PM, Laura Abbott wrote: > __pa_symbol is the correct API to find the physical address of symbols. > Switch to it to allow for debugging APIs to work correctly. But __pa() is correct for symbols. I see how __pa_symbol() might be a little faster than __pa(), but there is nothing wrong in using __pa() on symbols. > Other > functions such as p*d_populate may call __pa internally. Ensure that the > address passed is in the linear region by calling lm_alias. Why it should be linear mapping address? __pa() translates kernel image address just fine. This lm_alias() only obfuscates source code. Generated code is probably worse too.
On 12/01/2016 03:36 AM, Andrey Ryabinin wrote: > On 11/29/2016 09:55 PM, Laura Abbott wrote: >> __pa_symbol is the correct API to find the physical address of symbols. >> Switch to it to allow for debugging APIs to work correctly. > > But __pa() is correct for symbols. I see how __pa_symbol() might be a little > faster than __pa(), but there is nothing wrong in using __pa() on symbols. > >> Other >> functions such as p*d_populate may call __pa internally. Ensure that the >> address passed is in the linear region by calling lm_alias. > > Why it should be linear mapping address? __pa() translates kernel image address just fine. > This lm_alias() only obfuscates source code. Generated code is probably worse too. > > This is part of adding CONFIG_DEBUG_VIRTUAL for arm64. We want to differentiate between __pa and __pa_symbol to enforce stronger virtual checks and have __pa only be for linear map addresses. Thanks, Laura
On Thu, Dec 01, 2016 at 02:36:05PM +0300, Andrey Ryabinin wrote: > On 11/29/2016 09:55 PM, Laura Abbott wrote: > > __pa_symbol is the correct API to find the physical address of symbols. > > Switch to it to allow for debugging APIs to work correctly. > > But __pa() is correct for symbols. I see how __pa_symbol() might be a little > faster than __pa(), but there is nothing wrong in using __pa() on symbols. While it's true today that __pa() works on symbols, this is for pragmatic reasons (allowing existing code to work until it is all cleaned up), and __pa_symbol() is the correct API to use. Relying on this means that __pa() can't be optimised for the (vastly common) case of translating linear map addresses. Consistent use of __pa_symbol() will allow for subsequent optimisation of __pa() in the common case, in adition to being necessary for arm64's DEBUG_VIRTUAL. > > Other functions such as p*d_populate may call __pa internally. > > Ensure that the address passed is in the linear region by calling > > lm_alias. > > Why it should be linear mapping address? __pa() translates kernel > image address just fine. As above, while that's true today, but is something that we wish to change. > Generated code is probably worse too. Even if that is the case, given this is code run once at boot on a debug build, I think it's outweighed by the gain from DEBUG_VIRTUAL, and as a step towards optimising __pa(). Thanks, Mark.
On Tue, Nov 29, 2016 at 10:55:27AM -0800, Laura Abbott wrote: > __pa_symbol is the correct API to find the physical address of symbols. > Switch to it to allow for debugging APIs to work correctly. Other > functions such as p*d_populate may call __pa internally. Ensure that the > address passed is in the linear region by calling lm_alias. I've given this a go on Juno with CONFIG_KASAN_INLINE enabled, and everything seems happy. We'll need an include of <linux/mm.h> as that appears to be missing. I guess we're getting lucky with transitive includes. Otherwise this looks good to me. With that fixed up: Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Thanks, Mark. > Signed-off-by: Laura Abbott <labbott@redhat.com> > --- > Pointed out during review/testing of v3. > --- > mm/kasan/kasan_init.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/mm/kasan/kasan_init.c b/mm/kasan/kasan_init.c > index 3f9a41c..ff04721 100644 > --- a/mm/kasan/kasan_init.c > +++ b/mm/kasan/kasan_init.c > @@ -49,7 +49,7 @@ static void __init zero_pte_populate(pmd_t *pmd, unsigned long addr, > pte_t *pte = pte_offset_kernel(pmd, addr); > pte_t zero_pte; > > - zero_pte = pfn_pte(PFN_DOWN(__pa(kasan_zero_page)), PAGE_KERNEL); > + zero_pte = pfn_pte(PFN_DOWN(__pa_symbol(kasan_zero_page)), PAGE_KERNEL); > zero_pte = pte_wrprotect(zero_pte); > > while (addr + PAGE_SIZE <= end) { > @@ -69,7 +69,7 @@ static void __init zero_pmd_populate(pud_t *pud, unsigned long addr, > next = pmd_addr_end(addr, end); > > if (IS_ALIGNED(addr, PMD_SIZE) && end - addr >= PMD_SIZE) { > - pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte); > + pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte)); > continue; > } > > @@ -94,7 +94,7 @@ static void __init zero_pud_populate(pgd_t *pgd, unsigned long addr, > > pud_populate(&init_mm, pud, kasan_zero_pmd); > pmd = pmd_offset(pud, addr); > - pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte); > + pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte)); > continue; > } > > @@ -135,11 +135,11 @@ void __init kasan_populate_zero_shadow(const void *shadow_start, > * puds,pmds, so pgd_populate(), pud_populate() > * is noops. > */ > - pgd_populate(&init_mm, pgd, kasan_zero_pud); > + pgd_populate(&init_mm, pgd, lm_alias(kasan_zero_pud)); > pud = pud_offset(pgd, addr); > - pud_populate(&init_mm, pud, kasan_zero_pmd); > + pud_populate(&init_mm, pud, lm_alias(kasan_zero_pmd)); > pmd = pmd_offset(pud, addr); > - pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte); > + pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte)); > continue; > } > > -- > 2.7.4 >
On Tue, Nov 29, 2016 at 10:55:27AM -0800, Laura Abbott wrote: > @@ -94,7 +94,7 @@ static void __init zero_pud_populate(pgd_t *pgd, unsigned long addr, > > pud_populate(&init_mm, pud, kasan_zero_pmd); We also need to lm_alias()-ify kasan_zero_pmd here, or we'll get a stream of warnings at boot (example below). I should have spotted that. :/ With that fixed up, I'm able to boot Juno with both KASAN_INLINE and DEBUG_VIRTUAL, without issued. With that, my previous Reviewed-by and Tested-by stand. Thanks, Mark. ---->8---- [ 0.000000] virt_to_phys used for non-linear address :ffff20000a367000 [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:13 __virt_to_phys+0x48/0x68 [ 0.000000] Modules linked in: [ 0.000000] [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc6-00012-gdcc0162-dirty #13 [ 0.000000] Hardware name: ARM Juno development board (r1) (DT) [ 0.000000] task: ffff200009ec2200 task.stack: ffff200009eb0000 [ 0.000000] PC is at __virt_to_phys+0x48/0x68 [ 0.000000] LR is at __virt_to_phys+0x48/0x68 [ 0.000000] pc : [<ffff2000080af310>] lr : [<ffff2000080af310>] pstate: 600000c5 [ 0.000000] sp : ffff200009eb3c80 [ 0.000000] x29: ffff200009eb3c80 x28: ffff20000abdd000 [ 0.000000] x27: ffff200009ce1000 x26: ffff047fffffffff [ 0.000000] x25: ffff200009ce1000 x24: ffff20000a366100 [ 0.000000] x23: ffff048000000000 x22: ffff20000a366000 [ 0.000000] x21: ffff040080000000 x20: ffff040040000000 [ 0.000000] x19: ffff20000a367000 x18: 000000000000005c [ 0.000000] x17: 00000009ffec20e0 x16: 00000000fefff4b0 [ 0.000000] x15: ffffffffffffffff x14: 302b646d705f6f72 [ 0.000000] x13: 657a5f6e6173616b x12: 2820303030373633 [ 0.000000] x11: ffff20000a376ca0 x10: 0000000000000010 [ 0.000000] x9 : 646461207261656e x8 : 696c2d6e6f6e2072 [ 0.000000] x7 : 6f66206465737520 x6 : ffff20000a3741e5 [ 0.000000] x5 : 1fffe4000146ee0e x4 : 1fffe400013de704 [ 0.000000] x3 : 1fffe400013d6003 x2 : 1fffe400013d6003 [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000056 [ 0.000000] [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Call trace: [ 0.000000] Exception stack(0xffff200009eb3a50 to 0xffff200009eb3b80) [ 0.000000] 3a40: ffff20000a367000 0001000000000000 [ 0.000000] 3a60: ffff200009eb3c80 ffff2000080af310 00000000600000c5 000000000000003d [ 0.000000] 3a80: ffff200009ce1000 ffff2000081c4720 0000000041b58ab3 ffff200009c6cd98 [ 0.000000] 3aa0: ffff2000080818a0 ffff20000a366000 ffff048000000000 ffff20000a366100 [ 0.000000] 3ac0: ffff200009ce1000 ffff047fffffffff ffff200009ce1000 ffff20000abdd000 [ 0.000000] 3ae0: ffff0400013e3ccf ffff20000a3766c0 0000000000000000 0000000000000000 [ 0.000000] 3b00: ffff200009eb3c80 ffff200009eb3c80 ffff200009eb3c40 00000000ffffffc8 [ 0.000000] 3b20: ffff200009eb3b50 ffff2000082cbd3c ffff200009eb3c80 ffff200009eb3c80 [ 0.000000] 3b40: ffff200009eb3c40 00000000ffffffc8 0000000000000056 0000000000000000 [ 0.000000] 3b60: 1fffe400013d6003 1fffe400013d6003 1fffe400013de704 1fffe4000146ee0e [ 0.000000] [<ffff2000080af310>] __virt_to_phys+0x48/0x68 [ 0.000000] [<ffff200009d734e8>] zero_pud_populate+0x88/0x138 [ 0.000000] [<ffff200009d736f8>] kasan_populate_zero_shadow+0x160/0x18c [ 0.000000] [<ffff200009d5a048>] kasan_init+0x1f8/0x408 [ 0.000000] [<ffff200009d54000>] setup_arch+0x314/0x948 [ 0.000000] [<ffff200009d50c64>] start_kernel+0xb4/0x54c [ 0.000000] [<ffff200009d501e0>] __primary_switched+0x64/0x74 [mark@leverpostej:~/src/linux]% uselinaro 15.08 aarch64-linux-gnu-readelf -s vmlinux | grep ffff20000a367000 108184: ffff20000a367000 4096 OBJECT GLOBAL DEFAULT 25 kasan_zero_pmd [mark@leverpostej:~/src/linux]% uselinaro 15.08 aarch64-linux-gnu-addr2line -ife vmlinux ffff200009d734e8 set_pud /home/mark/src/linux/./arch/arm64/include/asm/pgtable.h:435 __pud_populate /home/mark/src/linux/./arch/arm64/include/asm/pgalloc.h:47 pud_populate /home/mark/src/linux/./arch/arm64/include/asm/pgalloc.h:52 zero_pud_populate /home/mark/src/linux/mm/kasan/kasan_init.c:95
diff --git a/mm/kasan/kasan_init.c b/mm/kasan/kasan_init.c index 3f9a41c..ff04721 100644 --- a/mm/kasan/kasan_init.c +++ b/mm/kasan/kasan_init.c @@ -49,7 +49,7 @@ static void __init zero_pte_populate(pmd_t *pmd, unsigned long addr, pte_t *pte = pte_offset_kernel(pmd, addr); pte_t zero_pte; - zero_pte = pfn_pte(PFN_DOWN(__pa(kasan_zero_page)), PAGE_KERNEL); + zero_pte = pfn_pte(PFN_DOWN(__pa_symbol(kasan_zero_page)), PAGE_KERNEL); zero_pte = pte_wrprotect(zero_pte); while (addr + PAGE_SIZE <= end) { @@ -69,7 +69,7 @@ static void __init zero_pmd_populate(pud_t *pud, unsigned long addr, next = pmd_addr_end(addr, end); if (IS_ALIGNED(addr, PMD_SIZE) && end - addr >= PMD_SIZE) { - pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte); + pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte)); continue; } @@ -94,7 +94,7 @@ static void __init zero_pud_populate(pgd_t *pgd, unsigned long addr, pud_populate(&init_mm, pud, kasan_zero_pmd); pmd = pmd_offset(pud, addr); - pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte); + pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte)); continue; } @@ -135,11 +135,11 @@ void __init kasan_populate_zero_shadow(const void *shadow_start, * puds,pmds, so pgd_populate(), pud_populate() * is noops. */ - pgd_populate(&init_mm, pgd, kasan_zero_pud); + pgd_populate(&init_mm, pgd, lm_alias(kasan_zero_pud)); pud = pud_offset(pgd, addr); - pud_populate(&init_mm, pud, kasan_zero_pmd); + pud_populate(&init_mm, pud, lm_alias(kasan_zero_pmd)); pmd = pmd_offset(pud, addr); - pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte); + pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte)); continue; }
__pa_symbol is the correct API to find the physical address of symbols. Switch to it to allow for debugging APIs to work correctly. Other functions such as p*d_populate may call __pa internally. Ensure that the address passed is in the linear region by calling lm_alias. Signed-off-by: Laura Abbott <labbott@redhat.com> --- Pointed out during review/testing of v3. --- mm/kasan/kasan_init.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)