linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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.


  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