devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Isaac J. Manjarres" <isaacmanjarres@google.com>
To: 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>,
	Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Saravana Kannan <saravanak@google.com>,
	linux-mm@kvack.org,
	"Isaac J. Manjarres" <isaacmanjarres@google.com>,
	kernel-team@android.com,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/1] Fix kmemleak crashes when scanning CMA regions
Date: Wed,  8 Feb 2023 15:19:59 -0800	[thread overview]
Message-ID: <20230208232001.2052777-1-isaacmanjarres@google.com> (raw)

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


             reply	other threads:[~2023-02-08 23:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-08 23:19 Isaac J. Manjarres [this message]
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

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=20230208232001.2052777-1-isaacmanjarres@google.com \
    --to=isaacmanjarres@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.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=rppt@kernel.org \
    --cc=saravanak@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).