From: Mike Rapoport <rppt@kernel.org>
To: "zhaoyang.huang" <zhaoyang.huang@unisoc.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Vlastimil Babka <vbabka@suse.cz>,
Nathan Chancellor <nathan@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Zhaoyang Huang <huangzhaoyang@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
ke.wang@unisoc.com,
Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>
Subject: Re: [PATCHv4 1/2] mm: move KMEMLEAK's Kconfig items from lib to mm
Date: Thu, 19 Jan 2023 12:04:01 +0200 [thread overview]
Message-ID: <Y8kVkZTZ/8lwaUlf@kernel.org> (raw)
In-Reply-To: <1674091345-14799-1-git-send-email-zhaoyang.huang@unisoc.com>
On Thu, Jan 19, 2023 at 09:22:24AM +0800, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>
> Have the kmemleak's source code and Kconfig items be in the same directory.
>
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
Acked-by: Mike Rapoport (IBM) <rppt@kernel.org>
> ---
> lib/Kconfig.debug | 70 -------------------------------------------------------
> mm/Kconfig.debug | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 70 insertions(+), 70 deletions(-)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 401ad4b..62884ac 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -716,76 +716,6 @@ config SHRINKER_DEBUG
> visibility into the kernel memory shrinkers subsystem.
> Disable it to avoid an extra memory footprint.
>
> -config HAVE_DEBUG_KMEMLEAK
> - bool
> -
> -config DEBUG_KMEMLEAK
> - bool "Kernel memory leak detector"
> - depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
> - select DEBUG_FS
> - select STACKTRACE if STACKTRACE_SUPPORT
> - select KALLSYMS
> - select CRC32
> - select STACKDEPOT
> - help
> - Say Y here if you want to enable the memory leak
> - detector. The memory allocation/freeing is traced in a way
> - similar to the Boehm's conservative garbage collector, the
> - difference being that the orphan objects are not freed but
> - only shown in /sys/kernel/debug/kmemleak. Enabling this
> - feature will introduce an overhead to memory
> - allocations. See Documentation/dev-tools/kmemleak.rst for more
> - details.
> -
> - Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
> - of finding leaks due to the slab objects poisoning.
> -
> - In order to access the kmemleak file, debugfs needs to be
> - mounted (usually at /sys/kernel/debug).
> -
> -config DEBUG_KMEMLEAK_MEM_POOL_SIZE
> - int "Kmemleak memory pool size"
> - depends on DEBUG_KMEMLEAK
> - range 200 1000000
> - default 16000
> - help
> - Kmemleak must track all the memory allocations to avoid
> - reporting false positives. Since memory may be allocated or
> - freed before kmemleak is fully initialised, use a static pool
> - of metadata objects to track such callbacks. After kmemleak is
> - fully initialised, this memory pool acts as an emergency one
> - if slab allocations fail.
> -
> -config DEBUG_KMEMLEAK_TEST
> - tristate "Simple test for the kernel memory leak detector"
> - depends on DEBUG_KMEMLEAK && m
> - help
> - This option enables a module that explicitly leaks memory.
> -
> - If unsure, say N.
> -
> -config DEBUG_KMEMLEAK_DEFAULT_OFF
> - bool "Default kmemleak to off"
> - depends on DEBUG_KMEMLEAK
> - help
> - Say Y here to disable kmemleak by default. It can then be enabled
> - on the command line via kmemleak=on.
> -
> -config DEBUG_KMEMLEAK_AUTO_SCAN
> - bool "Enable kmemleak auto scan thread on boot up"
> - default y
> - depends on DEBUG_KMEMLEAK
> - help
> - Depending on the cpu, kmemleak scan may be cpu intensive and can
> - stall user tasks at times. This option enables/disables automatic
> - kmemleak scan at boot up.
> -
> - Say N here to disable kmemleak auto scan thread to stop automatic
> - scanning. Disabling this option disables automatic reporting of
> - memory leaks.
> -
> - If unsure, say Y.
> -
> config DEBUG_STACK_USAGE
> bool "Stack utilization instrumentation"
> depends on DEBUG_KERNEL && !IA64
> diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
> index ce8dded..d1893ac 100644
> --- a/mm/Kconfig.debug
> +++ b/mm/Kconfig.debug
> @@ -207,3 +207,73 @@ config PTDUMP_DEBUGFS
> kernel.
>
> If in doubt, say N.
> +
> +config HAVE_DEBUG_KMEMLEAK
> + bool
> +
> +config DEBUG_KMEMLEAK
> + bool "Kernel memory leak detector"
> + depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
> + select DEBUG_FS
> + select STACKTRACE if STACKTRACE_SUPPORT
> + select KALLSYMS
> + select CRC32
> + select STACKDEPOT
> + help
> + Say Y here if you want to enable the memory leak
> + detector. The memory allocation/freeing is traced in a way
> + similar to the Boehm's conservative garbage collector, the
> + difference being that the orphan objects are not freed but
> + only shown in /sys/kernel/debug/kmemleak. Enabling this
> + feature will introduce an overhead to memory
> + allocations. See Documentation/dev-tools/kmemleak.rst for more
> + details.
> +
> + Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
> + of finding leaks due to the slab objects poisoning.
> +
> + In order to access the kmemleak file, debugfs needs to be
> + mounted (usually at /sys/kernel/debug).
> +
> +config DEBUG_KMEMLEAK_MEM_POOL_SIZE
> + int "Kmemleak memory pool size"
> + depends on DEBUG_KMEMLEAK
> + range 200 1000000
> + default 16000
> + help
> + Kmemleak must track all the memory allocations to avoid
> + reporting false positives. Since memory may be allocated or
> + freed before kmemleak is fully initialised, use a static pool
> + of metadata objects to track such callbacks. After kmemleak is
> + fully initialised, this memory pool acts as an emergency one
> + if slab allocations fail.
> +
> +config DEBUG_KMEMLEAK_TEST
> + tristate "Simple test for the kernel memory leak detector"
> + depends on DEBUG_KMEMLEAK && m
> + help
> + This option enables a module that explicitly leaks memory.
> +
> + If unsure, say N.
> +
> +config DEBUG_KMEMLEAK_DEFAULT_OFF
> + bool "Default kmemleak to off"
> + depends on DEBUG_KMEMLEAK
> + help
> + Say Y here to disable kmemleak by default. It can then be enabled
> + on the command line via kmemleak=on.
> +
> +config DEBUG_KMEMLEAK_AUTO_SCAN
> + bool "Enable kmemleak auto scan thread on boot up"
> + default y
> + depends on DEBUG_KMEMLEAK
> + help
> + Depending on the cpu, kmemleak scan may be cpu intensive and can
> + stall user tasks at times. This option enables/disables automatic
> + kmemleak scan at boot up.
> +
> + Say N here to disable kmemleak auto scan thread to stop automatic
> + scanning. Disabling this option disables automatic reporting of
> + memory leaks.
> +
> + If unsure, say Y.
> --
> 1.9.1
>
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2023-01-19 10:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-19 1:22 zhaoyang.huang
2023-01-19 1:22 ` [PATCHv4 2/2] mm: use stack_depot_early_init for kmemleak zhaoyang.huang
2023-01-19 10:03 ` Mike Rapoport
2023-01-19 10:13 ` Catalin Marinas
2023-01-19 10:32 ` Vlastimil Babka
2023-01-19 22:42 ` Andrew Morton
2023-01-20 12:52 ` Vlastimil Babka
2023-01-19 10:04 ` Mike Rapoport [this message]
2023-01-19 10:16 ` [PATCHv4 1/2] mm: move KMEMLEAK's Kconfig items from lib to mm Vlastimil Babka
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=Y8kVkZTZ/8lwaUlf@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=huangzhaoyang@gmail.com \
--cc=ke.wang@unisoc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mirsad.todorovac@alu.unizg.hr \
--cc=nathan@kernel.org \
--cc=peterz@infradead.org \
--cc=vbabka@suse.cz \
--cc=zhaoyang.huang@unisoc.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