* [PATCH v2 0/1] Fix kmemleak crashes when scanning CMA regions
@ 2023-02-08 23:19 Isaac J. Manjarres
2023-02-08 23:20 ` [PATCH v2 1/1] of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem Isaac J. Manjarres
0 siblings, 1 reply; 4+ messages in thread
From: Isaac J. Manjarres @ 2023-02-08 23:19 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Russell King (Oracle),
Mike Rapoport, Kirill A. Shutemov, Nick Kossifidis,
Catalin Marinas
Cc: Andrew Morton, Saravana Kannan, linux-mm, Isaac J. Manjarres,
kernel-team, Rafael J. Wysocki, devicetree, linux-kernel
When trying to boot a device with an ARM64 kernel with the following
config options enabled:
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y
CONFIG_DEBUG_KMEMLEAK=y
a crash is encountered when kmemleak starts to scan the list of gray
or allocated objects that it maintains. Upon closer inspection, it was
observed that these page-faults always occurred when kmemleak attempted
to scan a CMA region.
At the moment, kmemleak is made aware of CMA regions that are specified
through the devicetree to be dynamically allocated within a range of
addresses. However, kmemleak should not need to scan CMA regions or any
reserved memory region, as those regions can be used for DMA transfers
between drivers and peripherals, and thus wouldn't contain anything
useful for kmemleak.
Additionally, since CMA regions are unmapped from the kernel's address
space when they are freed to the buddy allocator at boot when
CONFIG_DEBUG_PAGEALLOC is enabled, kmemleak shouldn't attempt to access
those memory regions, as that will trigger a crash. Thus, kmemleak
should ignore all dynamically allocated reserved memory regions.
v1 ==> v2:
- Simplified the original approach of informing kmemleak about all CMA
regions in the system to just having kmemleak ignore CMA regions it is
currently aware of.
Isaac J. Manjarres (1):
of: reserved_mem: Have kmemleak ignore dynamically allocated reserved
mem
drivers/of/of_reserved_mem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.39.1.581.gbfd45094c4-goog
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH v2 1/1] of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem
2023-02-08 23:19 [PATCH v2 0/1] Fix kmemleak crashes when scanning CMA regions Isaac J. Manjarres
@ 2023-02-08 23:20 ` Isaac J. Manjarres
2023-02-09 5:59 ` Mike Rapoport
2023-02-09 18:55 ` Catalin Marinas
0 siblings, 2 replies; 4+ messages in thread
From: Isaac J. Manjarres @ 2023-02-08 23:20 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Russell King (Oracle),
Mike Rapoport, Kirill A. Shutemov, Nick Kossifidis,
Catalin Marinas, Andrew Morton
Cc: Saravana Kannan, linux-mm, Isaac J. Manjarres, kernel-team,
Rafael J. Wysocki, devicetree, linux-kernel, stable, Rob Herring
Currently, kmemleak ignores dynamically allocated reserved memory
regions that don't have a kernel mapping. However, regions that do
retain a kernel mapping (e.g. CMA regions) do get scanned by kmemleak.
This is not ideal for two reasons:
1. kmemleak works by scanning memory regions for pointers to
allocated objects to determine if those objects have been leaked
or not. However, reserved memory regions can be used between drivers
and peripherals for DMA transfers, and thus, would not contain pointers
to allocated objects, making it unnecessary for kmemleak to scan
these reserved memory regions.
2. When CONFIG_DEBUG_PAGEALLOC is enabled, along with kmemleak, the
CMA reserved memory regions are unmapped from the kernel's address
space when they are freed to buddy at boot. These CMA reserved regions
are still tracked by kmemleak, however, and when kmemleak attempts to
scan them, a crash will happen, as accessing the CMA region will result
in a page-fault, since the regions are unmapped.
Thus, use kmemleak_ignore_phys() for all dynamically allocated reserved
memory regions, instead of those that do not have a kernel mapping
associated with them.
Cc: <stable@vger.kernel.org> # 5.15+
Fixes: a7259df76702 ("memblock: make memblock_find_in_range method private")
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
---
drivers/of/of_reserved_mem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 65f3b02a0e4e..f90975e00446 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -48,9 +48,10 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
err = memblock_mark_nomap(base, size);
if (err)
memblock_phys_free(base, size);
- kmemleak_ignore_phys(base);
}
+ kmemleak_ignore_phys(base);
+
return err;
}
--
2.39.1.581.gbfd45094c4-goog
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2 1/1] of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem
2023-02-08 23:20 ` [PATCH v2 1/1] of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem Isaac J. Manjarres
@ 2023-02-09 5:59 ` Mike Rapoport
2023-02-09 18:55 ` Catalin Marinas
1 sibling, 0 replies; 4+ messages in thread
From: Mike Rapoport @ 2023-02-09 5:59 UTC (permalink / raw)
To: Isaac J. Manjarres
Cc: Rob Herring, Frank Rowand, Russell King (Oracle),
Kirill A. Shutemov, Nick Kossifidis, Catalin Marinas,
Andrew Morton, Saravana Kannan, linux-mm, kernel-team,
Rafael J. Wysocki, devicetree, linux-kernel, stable, Rob Herring
On Wed, Feb 08, 2023 at 03:20:00PM -0800, Isaac J. Manjarres wrote:
> Currently, kmemleak ignores dynamically allocated reserved memory
> regions that don't have a kernel mapping. However, regions that do
> retain a kernel mapping (e.g. CMA regions) do get scanned by kmemleak.
>
> This is not ideal for two reasons:
>
> 1. kmemleak works by scanning memory regions for pointers to
> allocated objects to determine if those objects have been leaked
> or not. However, reserved memory regions can be used between drivers
> and peripherals for DMA transfers, and thus, would not contain pointers
> to allocated objects, making it unnecessary for kmemleak to scan
> these reserved memory regions.
>
> 2. When CONFIG_DEBUG_PAGEALLOC is enabled, along with kmemleak, the
> CMA reserved memory regions are unmapped from the kernel's address
> space when they are freed to buddy at boot. These CMA reserved regions
> are still tracked by kmemleak, however, and when kmemleak attempts to
> scan them, a crash will happen, as accessing the CMA region will result
> in a page-fault, since the regions are unmapped.
>
> Thus, use kmemleak_ignore_phys() for all dynamically allocated reserved
> memory regions, instead of those that do not have a kernel mapping
> associated with them.
>
> Cc: <stable@vger.kernel.org> # 5.15+
> Fixes: a7259df76702 ("memblock: make memblock_find_in_range method private")
> Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
Acked-by: Mike Rapoport (IBM) <rppt@kernel.org>
> ---
> drivers/of/of_reserved_mem.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index 65f3b02a0e4e..f90975e00446 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -48,9 +48,10 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
> err = memblock_mark_nomap(base, size);
> if (err)
> memblock_phys_free(base, size);
> - kmemleak_ignore_phys(base);
> }
>
> + kmemleak_ignore_phys(base);
> +
> return err;
> }
>
> --
> 2.39.1.581.gbfd45094c4-goog
>
--
Sincerely yours,
Mike.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2 1/1] of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem
2023-02-08 23:20 ` [PATCH v2 1/1] of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem Isaac J. Manjarres
2023-02-09 5:59 ` Mike Rapoport
@ 2023-02-09 18:55 ` Catalin Marinas
1 sibling, 0 replies; 4+ messages in thread
From: Catalin Marinas @ 2023-02-09 18:55 UTC (permalink / raw)
To: Isaac J. Manjarres
Cc: Rob Herring, Frank Rowand, Russell King (Oracle),
Mike Rapoport, Kirill A. Shutemov, Nick Kossifidis,
Andrew Morton, Saravana Kannan, linux-mm, kernel-team,
Rafael J. Wysocki, devicetree, linux-kernel, stable, Rob Herring
On Wed, Feb 08, 2023 at 03:20:00PM -0800, Isaac J. Manjarres wrote:
> Currently, kmemleak ignores dynamically allocated reserved memory
> regions that don't have a kernel mapping. However, regions that do
> retain a kernel mapping (e.g. CMA regions) do get scanned by kmemleak.
>
> This is not ideal for two reasons:
>
> 1. kmemleak works by scanning memory regions for pointers to
> allocated objects to determine if those objects have been leaked
> or not. However, reserved memory regions can be used between drivers
> and peripherals for DMA transfers, and thus, would not contain pointers
> to allocated objects, making it unnecessary for kmemleak to scan
> these reserved memory regions.
>
> 2. When CONFIG_DEBUG_PAGEALLOC is enabled, along with kmemleak, the
> CMA reserved memory regions are unmapped from the kernel's address
> space when they are freed to buddy at boot. These CMA reserved regions
> are still tracked by kmemleak, however, and when kmemleak attempts to
> scan them, a crash will happen, as accessing the CMA region will result
> in a page-fault, since the regions are unmapped.
>
> Thus, use kmemleak_ignore_phys() for all dynamically allocated reserved
> memory regions, instead of those that do not have a kernel mapping
> associated with them.
>
> Cc: <stable@vger.kernel.org> # 5.15+
> Fixes: a7259df76702 ("memblock: make memblock_find_in_range method private")
> Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-02-09 18:55 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-08 23:19 [PATCH v2 0/1] Fix kmemleak crashes when scanning CMA regions Isaac J. Manjarres
2023-02-08 23:20 ` [PATCH v2 1/1] of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem Isaac J. Manjarres
2023-02-09 5:59 ` Mike Rapoport
2023-02-09 18:55 ` Catalin Marinas
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.