lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8kVkZTZ/8lwaUlf@kernel.org>
Date:   Thu, 19 Jan 2023 12:04:01 +0200
From:   Mike Rapoport <rppt@...nel.org>
To:     "zhaoyang.huang" <zhaoyang.huang@...soc.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Nathan Chancellor <nathan@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Zhaoyang Huang <huangzhaoyang@...il.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, ke.wang@...soc.com,
        Mirsad Todorovac <mirsad.todorovac@....unizg.hr>
Subject: Re: [PATCHv4 1/2] mm: move KMEMLEAK's Kconfig items from lib to mm

On Thu, Jan 19, 2023 at 09:22:24AM +0800, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@...soc.com>
> 
> Have the kmemleak's source code and Kconfig items be in the same directory.
> 
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@...soc.com>

Acked-by: Mike Rapoport (IBM) <rppt@...nel.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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ