[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1495726937-23557-1-git-send-email-catalin.marinas@arm.com>
Date: Thu, 25 May 2017 16:42:14 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: linux-mm@...ck.org
Cc: linux-kernel@...r.kernel.org, Michal Hocko <mhocko@...nel.org>,
Andy Lutomirski <luto@...capital.net>,
"Luis R. Rodriguez" <mcgrof@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH v2 0/3] mm: kmemleak: Improve vmalloc() false positives for thread stack allocation
Hi,
This is a follow up from [1] (mm: kmemleak: Treat vm_struct as
alternative reference to vmalloc'ed objects).
The first two patches are just clean-up and refactoring. The third
introduces the kmemleak_vmalloc() API which allows a vmalloc() caller to
keep either the returned pointer or a pointer to vm_struct as a
reference (see the patch description for the implementation details).
The false positives were noticed with alloc_thread_stack_node(),
free_thread_stack() and CONFIG_VMAP_STACK where a per-CPU array is used
to cache the freed thread stacks as vm_struct pointers.
Changes since v1:
- Split the patch into three for easier review
- Only call update_refs() if !color_gray() on the found object, it
avoids an unnecessary function call
[1] http://lkml.kernel.org/r/1495474514-24425-1-git-send-email-catalin.marinas@arm.com
Catalin Marinas (3):
mm: kmemleak: Slightly reduce the size of some structures on 64-bit
architectures
mm: kmemleak: Factor object reference updating out of scan_block()
mm: kmemleak: Treat vm_struct as alternative reference to vmalloc'ed
objects
Documentation/dev-tools/kmemleak.rst | 1 +
include/linux/kmemleak.h | 7 ++
mm/kmemleak.c | 136 +++++++++++++++++++++++++++++------
mm/vmalloc.c | 7 +-
4 files changed, 123 insertions(+), 28 deletions(-)
Powered by blists - more mailing lists