Message ID | 20211021070929.23272-1-rppt@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | memblock: exclude MEMBLOCK_NOMAP regions from kmemleak | expand |
On 10/21/21 3:09 AM, Mike Rapoport wrote: > From: Mike Rapoport <rppt@linux.ibm.com> > > Hi, > > This is take 2 to fix interaction between MEMBLOCK_NOMAP and kmemleak. > > The previous version caused boot failures Qian Cai reported here: > > https://lore.kernel.org/all/c30ff0a2-d196-c50d-22f0-bd50696b1205@quicinc.com > > The failures happened because calling kmemleak_free_part_phys() (or any > kmemleak phys APIs for that matter) too early means it cannot use __va() on > arm64. > > This late in the cycle I can only think of reverting kmemleak wavier from > memblock_mark_nomap() and putting it in the only two callers that set > MEMBLOCK_NOMAP to an allocated chunk rather than marking NOMAP "unusable" > memory reported by firmware. > > The first patch here is the revert of v1 and the second patch is actual v2 > implementation. > > Vladimir and Qian, I'd appreciate if you could verify that v2 works for > you. FYI, this passed the regression tests here. > > v2: > * move kmemleak waiver from memblock_mark_nomap() to callers that need it > * use kmemleak_ignore_phys() rather than kmemleak_free_part_phys() as > Catalin suggested. > > v1: https://lore.kernel.org/all/20211013054756.12177-1-rppt@kernel.org > > Mike Rapoport (2): > Revert "memblock: exclude NOMAP regions from kmemleak" > memblock: exclude MEMBLOCK_NOMAP regions from kmemleak > > drivers/acpi/tables.c | 3 +++ > drivers/of/of_reserved_mem.c | 2 ++ > mm/memblock.c | 10 ++++------ > 3 files changed, 9 insertions(+), 6 deletions(-) > > > base-commit: 519d81956ee277b4419c723adfb154603c2565ba >
From: Mike Rapoport <rppt@linux.ibm.com> Hi, This is take 2 to fix interaction between MEMBLOCK_NOMAP and kmemleak. The previous version caused boot failures Qian Cai reported here: https://lore.kernel.org/all/c30ff0a2-d196-c50d-22f0-bd50696b1205@quicinc.com The failures happened because calling kmemleak_free_part_phys() (or any kmemleak phys APIs for that matter) too early means it cannot use __va() on arm64. This late in the cycle I can only think of reverting kmemleak wavier from memblock_mark_nomap() and putting it in the only two callers that set MEMBLOCK_NOMAP to an allocated chunk rather than marking NOMAP "unusable" memory reported by firmware. The first patch here is the revert of v1 and the second patch is actual v2 implementation. Vladimir and Qian, I'd appreciate if you could verify that v2 works for you. v2: * move kmemleak waiver from memblock_mark_nomap() to callers that need it * use kmemleak_ignore_phys() rather than kmemleak_free_part_phys() as Catalin suggested. v1: https://lore.kernel.org/all/20211013054756.12177-1-rppt@kernel.org Mike Rapoport (2): Revert "memblock: exclude NOMAP regions from kmemleak" memblock: exclude MEMBLOCK_NOMAP regions from kmemleak drivers/acpi/tables.c | 3 +++ drivers/of/of_reserved_mem.c | 2 ++ mm/memblock.c | 10 ++++------ 3 files changed, 9 insertions(+), 6 deletions(-) base-commit: 519d81956ee277b4419c723adfb154603c2565ba