Re: [PATCH v2 1/1] mm: kfence: apply kmemleak_ignore_phys on early allocated pool
From: Marco Elver <elver@google.com>
Date: 2022-08-01 14:06:33
Also in:
linux-mediatek, linux-mm, lkml
[+x86 maintainers ...] On Wed, 20 Jul 2022 at 01:22, Dave Hansen [off-list ref] wrote:
On 7/19/22 16:13, Andrew Morton wrote:quoted
On Mon, 18 Jul 2022 16:26:25 +0200 Marco Elver [off-list ref] wrote:quoted
On Sat, 16 Jul 2022 at 20:43, Geert Uytterhoeven [off-list ref] wrote: [...]quoted
quoted
- This patch has been accused of crashing the kernel: https://lkml.kernel.org/r/YsFeUHkrFTQ7T51Q@xsang-OptiPlex-9020 Do we think that report is bogus?I think all of this is highly architecture-specific...The report can be reproduced on i386 with CONFIG_X86_PAE=y. But e.g. mm/memblock.c:memblock_free() is also guilty of using __pa() on previously memblock_alloc()'d addresses. Looking at the phys addr before memblock_alloc() does virt_to_phys(), the result of __pa() looks correct even on PAE, at least for the purpose of passing it on to kmemleak(). So I don't know what that BUG_ON(slow_virt_to_phys() != phys_addr) is supposed to tell us here.It's only been nine years, so I'm sure Dave can remember why he added it ;) BUG_ON(slow_virt_to_phys((void *)x) != phys_addr); in arch/x86/mm/physaddr.c:__phys_addr().I think I intended it to double check that the linear map is *actually* a linear map for 'x'. Sure, we can use the "x - PAGE_OFFSET" shortcut, but did it turn out to be actually accurate for the address it was handed? I'd be curious what the page tables actually say for the address that's causing problems.
test robot just reminded us again: https://lore.kernel.org/all/YufXncrWhJZH0ifB@xsang-OptiPlex-9020/T/#u (local) Few things I noticed: * mm/memblock.c's memblock_free() also uses __pa() to convert back to physical address. Presumably that's also wrong. What should be used instead? * kmemleak happily converts phys_addr_t to unsigned long everywhere, but with i386 PAE, this will narrow a 64-bit address to a 32-bit address. Is that correct? Does kmemleak need a "depends on 64BIT || !PHYS_ADDR_T_64BIT"? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel