From b05a66fc5fb694fac8e8b80f5f415c53237c891f Mon Sep 17 00:00:00 2001 From: Daniel Baluta Date: Mon, 4 Apr 2011 14:58:03 -0700 Subject: [PATCH] --- yaml --- r: 243662 b: refs/heads/master c: 21b86bd5a838ee882d36d354185e29650b0757dd h: refs/heads/master v: v3 --- [refs] | 2 +- trunk/Documentation/kmemleak.txt | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/[refs] b/[refs] index e06b0acb1a4a..682c4e174c37 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: a5660b41af6a28f8004e70eb261e1202ad55c5e3 +refs/heads/master: 21b86bd5a838ee882d36d354185e29650b0757dd diff --git a/trunk/Documentation/kmemleak.txt b/trunk/Documentation/kmemleak.txt index 34f6638aa5ac..090e6ee04536 100644 --- a/trunk/Documentation/kmemleak.txt +++ b/trunk/Documentation/kmemleak.txt @@ -11,6 +11,7 @@ with the difference that the orphan objects are not freed but only reported via /sys/kernel/debug/kmemleak. A similar method is used by the Valgrind tool (memcheck --leak-check) to detect the memory leaks in user-space applications. +Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile. Usage ----- @@ -178,5 +179,4 @@ block doesn't need to be freed (some cases in the init_call functions), the pointer is calculated by other methods than the usual container_of macro or the pointer is stored in a location not scanned by kmemleak. -Page allocations and ioremap are not tracked. Only the ARM and x86 -architectures are currently supported. +Page allocations and ioremap are not tracked.