Message ID | 20230124230254.295589-1-isaacmanjarres@google.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [v1] Revert "mm: kmemleak: alloc gray object for reserved region with direct map" | expand |
On Tue, Jan 24, 2023 at 03:02:54PM -0800, Isaac J. Manjarres wrote: > This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769. > > Kmemleak operates by periodically scanning memory regions for pointers > to allocated memory blocks to determine if they are leaked or not. > However, reserved memory regions can be used for DMA transactions > between a device and a CPU, and thus, wouldn't contain pointers to > allocated memory blocks, making them inappropriate for kmemleak to > scan. Thus, revert this commit. > > Cc: stable@vger.kernel.org # 5.17+ > Cc: Calvin Zhang <calvinzhang.cool@gmail.com> > Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
On Tue, Jan 24, 2023 at 03:02:54PM -0800, Isaac J. Manjarres wrote: > This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769. > > Kmemleak operates by periodically scanning memory regions for pointers > to allocated memory blocks to determine if they are leaked or not. > However, reserved memory regions can be used for DMA transactions > between a device and a CPU, and thus, wouldn't contain pointers to > allocated memory blocks, making them inappropriate for kmemleak to > scan. Thus, revert this commit. Both commits talk about the same type of memory as CMA is used for DMA. Neither commit tells me what are the implications of kmemleak scanning or not scanning the region? Are there false positives? > Cc: stable@vger.kernel.org # 5.17+ > Cc: Calvin Zhang <calvinzhang.cool@gmail.com> > Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com> > --- > drivers/of/fdt.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-)
On Wed, Jan 25, 2023 at 03:02:15PM -0600, Rob Herring wrote: > On Tue, Jan 24, 2023 at 03:02:54PM -0800, Isaac J. Manjarres wrote: > > This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769. > > > > Kmemleak operates by periodically scanning memory regions for pointers > > to allocated memory blocks to determine if they are leaked or not. > > However, reserved memory regions can be used for DMA transactions > > between a device and a CPU, and thus, wouldn't contain pointers to > > allocated memory blocks, making them inappropriate for kmemleak to > > scan. Thus, revert this commit. > > Both commits talk about the same type of memory as CMA is used for DMA. > Neither commit tells me what are the implications of kmemleak scanning > or not scanning the region? Are there false positives? If kmemleak scans the region when CONFIG_DEBUG_PAGEALLOC is enabled, and the CMA region is not in use, then kmemleak will cause a page-fault, because the region is unmapped from the kernel's address space. kmemleak scans the region because it thinks it is in use/allocated, when it's not. While this sounds like a problem of kmemleak not being informed about the region not being actually allocated, it's also a matter of CMA regions not being suitable for kmemleak to scan in the first place, because they don't have pointers to other memory blocks; they might have data from DMA transactions with another device, so it doesn't make sense for kmemleak to scan these areas. --Isaac
On Tue, 24 Jan 2023 15:02:54 -0800, Isaac J. Manjarres wrote: > This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769. > > Kmemleak operates by periodically scanning memory regions for pointers > to allocated memory blocks to determine if they are leaked or not. > However, reserved memory regions can be used for DMA transactions > between a device and a CPU, and thus, wouldn't contain pointers to > allocated memory blocks, making them inappropriate for kmemleak to > scan. Thus, revert this commit. > > Cc: stable@vger.kernel.org # 5.17+ > Cc: Calvin Zhang <calvinzhang.cool@gmail.com> > Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com> > --- > drivers/of/fdt.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > Applied, thanks!
On Fri, Jan 27, 2023 at 3:38 PM Rob Herring <robh@kernel.org> wrote: > > > On Tue, 24 Jan 2023 15:02:54 -0800, Isaac J. Manjarres wrote: > > This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769. > > > > Kmemleak operates by periodically scanning memory regions for pointers > > to allocated memory blocks to determine if they are leaked or not. > > However, reserved memory regions can be used for DMA transactions > > between a device and a CPU, and thus, wouldn't contain pointers to > > allocated memory blocks, making them inappropriate for kmemleak to > > scan. Thus, revert this commit. > > > > Cc: stable@vger.kernel.org # 5.17+ > > Cc: Calvin Zhang <calvinzhang.cool@gmail.com> > > Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com> > > --- > > drivers/of/fdt.c | 6 +----- > > 1 file changed, 1 insertion(+), 5 deletions(-) > > > > Applied, thanks! Or not. Andrew already applied it. Rob
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index f08b25195ae7..d1a68b6d03b3 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -26,7 +26,6 @@ #include <linux/serial_core.h> #include <linux/sysfs.h> #include <linux/random.h> -#include <linux/kmemleak.h> #include <asm/setup.h> /* for COMMAND_LINE_SIZE */ #include <asm/page.h> @@ -525,12 +524,9 @@ static int __init __reserved_mem_reserve_reg(unsigned long node, size = dt_mem_next_cell(dt_root_size_cells, &prop); if (size && - early_init_dt_reserve_memory(base, size, nomap) == 0) { + early_init_dt_reserve_memory(base, size, nomap) == 0) pr_debug("Reserved memory: reserved region for node '%s': base %pa, size %lu MiB\n", uname, &base, (unsigned long)(size / SZ_1M)); - if (!nomap) - kmemleak_alloc_phys(base, size, 0); - } else pr_err("Reserved memory: failed to reserve memory for node '%s': base %pa, size %lu MiB\n", uname, &base, (unsigned long)(size / SZ_1M));
This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769. Kmemleak operates by periodically scanning memory regions for pointers to allocated memory blocks to determine if they are leaked or not. However, reserved memory regions can be used for DMA transactions between a device and a CPU, and thus, wouldn't contain pointers to allocated memory blocks, making them inappropriate for kmemleak to scan. Thus, revert this commit. Cc: stable@vger.kernel.org # 5.17+ Cc: Calvin Zhang <calvinzhang.cool@gmail.com> Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com> --- drivers/of/fdt.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)