All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: "Isaac J. Manjarres" <isaacmanjarres@google.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
	Mike Rapoport <rppt@kernel.org>,
	"Kirill A. Shutemov" <kirill.shtuemov@linux.intel.com>,
	Nick Kossifidis <mick@ics.forth.gr>,
	Andrew Morton <akpm@linux-foundation.org>,
	Saravana Kannan <saravanak@google.com>,
	linux-mm@kvack.org, kernel-team@android.com,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Rob Herring <robh@kernel.org>
Subject: Re: [PATCH v2 1/1] of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem
Date: Thu, 9 Feb 2023 18:55:42 +0000	[thread overview]
Message-ID: <Y+VBrpGfwFD82PVF@arm.com> (raw)
In-Reply-To: <20230208232001.2052777-2-isaacmanjarres@google.com>

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>

      parent reply	other threads:[~2023-02-09 18:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+VBrpGfwFD82PVF@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=isaacmanjarres@google.com \
    --cc=kernel-team@android.com \
    --cc=kirill.shtuemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mick@ics.forth.gr \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=rppt@kernel.org \
    --cc=saravanak@google.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.