Thread (12 messages) 12 messages, 6 authors, 2022-08-01

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help