Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1514300 > unrolled thread

[PATCH] userns: suppress kmemleak message

Back to article view | Back to linux.kernel

Contents

  [PATCH] userns: suppress kmemleak message Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-11-03 06:50 +0100
    Re: [PATCH] userns: suppress kmemleak message Jakub Kicinski <jakub.kicinski@netronome.com> - 2016-11-03 15:10 +0100
    Re: [PATCH] userns: suppress kmemleak message ebiederm@xmission.com (Eric W. Biederman) - 2016-11-03 16:00 +0100
      Re: [PATCH] userns: suppress kmemleak message Jakub Kicinski <kubakici@wp.pl> - 2016-11-03 16:10 +0100

#1514300 — [PATCH] userns: suppress kmemleak message

We do not ever intend to unregister "user" sysctl table, unfortunately
it leads kmemleak to believe that we are leaking memory:

unreferenced object 0xffff8807383bfd48 (size 96):
  comm "swapper/0", pid 1, jiffies 4294894636 (age 278.320s)
  hex dump (first 32 bytes):
    a0 b4 b0 ba ff ff ff ff 00 00 00 00 01 00 00 00  ................
    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffffb7de59e8>] kmemleak_alloc+0x28/0x50
    [<ffffffffb676e2f6>] __kmalloc+0x206/0x5a0
    [<ffffffffb69be2d3>] __register_sysctl_table+0xb3/0x1130
    [<ffffffffb69bf36b>] register_sysctl+0x1b/0x20
    [<ffffffffba840de1>] user_namespace_sysctl_init+0x17/0x4c
    [<ffffffffb60022b7>] do_one_initcall+0xb7/0x2a0
    [<ffffffffba7eb102>] kernel_init_freeable+0x597/0x636
    [<ffffffffb7de0433>] kernel_init+0x13/0x140
    [<ffffffffb7dfb36a>] ret_from_fork+0x2a/0x40t show
    [<ffffffffffffffff>] 0xffffffffffffffff

Let's annotate the pointer as kmemleak_not_leak() to suppress the
kmemleak false positive.

Reported-by: Jakub Kicinski <kubakici@wp.pl>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---

This was only compiled; Jakub, could you give it a spin?

 kernel/ucount.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/ucount.c b/kernel/ucount.c
index 9d20d5d..07d69b2 100644
--- a/kernel/ucount.c
+++ b/kernel/ucount.c
@@ -5,6 +5,7 @@
  *  License.
  */
 
+#include <linux/kmemleak.h>
 #include <linux/stat.h>
 #include <linux/sysctl.h>
 #include <linux/slab.h>
@@ -226,6 +227,7 @@ static __init int user_namespace_sysctl_init(void)
 	 */
 	user_header = register_sysctl("user", empty);
 	BUG_ON(!user_header);
+	kmemleak_not_leak(user_header);
 	BUG_ON(!setup_userns_sysctls(&init_user_ns));
 #endif
 	return 0;
-- 
2.8.0.rc3.226.g39d4020


-- 
Dmitry

[toc] | [next] | [standalone]

#1514540

On Wed, 2 Nov 2016 22:39:48 -0700, Dmitry Torokhov wrote:
> We do not ever intend to unregister "user" sysctl table, unfortunately
> it leads kmemleak to believe that we are leaking memory:
> 
> unreferenced object 0xffff8807383bfd48 (size 96):
>   comm "swapper/0", pid 1, jiffies 4294894636 (age 278.320s)
>   hex dump (first 32 bytes):
>     a0 b4 b0 ba ff ff ff ff 00 00 00 00 01 00 00 00  ................
>     01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<ffffffffb7de59e8>] kmemleak_alloc+0x28/0x50
>     [<ffffffffb676e2f6>] __kmalloc+0x206/0x5a0
>     [<ffffffffb69be2d3>] __register_sysctl_table+0xb3/0x1130
>     [<ffffffffb69bf36b>] register_sysctl+0x1b/0x20
>     [<ffffffffba840de1>] user_namespace_sysctl_init+0x17/0x4c
>     [<ffffffffb60022b7>] do_one_initcall+0xb7/0x2a0
>     [<ffffffffba7eb102>] kernel_init_freeable+0x597/0x636
>     [<ffffffffb7de0433>] kernel_init+0x13/0x140
>     [<ffffffffb7dfb36a>] ret_from_fork+0x2a/0x40t show
>     [<ffffffffffffffff>] 0xffffffffffffffff
> 
> Let's annotate the pointer as kmemleak_not_leak() to suppress the
> kmemleak false positive.
> 
> Reported-by: Jakub Kicinski <kubakici@wp.pl>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> 
> This was only compiled; Jakub, could you give it a spin?

Tested-by: Jakub Kicinski <jakub.kicinski@netronome.com>

Thanks!

[toc] | [prev] | [next] | [standalone]

#1514579

Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:

> We do not ever intend to unregister "user" sysctl table, unfortunately
> it leads kmemleak to believe that we are leaking memory:

Sounds like an issue with kmemleak because we do retain references.

So no we don't intend to unregister the table.

As for the patch.

Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>

I can't see the using kmemleak_not_leak is possibly good form.  I
would much rather have suggestions about constructs that won't confuse
kmemleak and won't need ugly annotations that serve no purpose but to
appease a tool.  Perhaps the user_header variable needs to be moved out
of user_namespace_sysctl_init.

Eric

> unreferenced object 0xffff8807383bfd48 (size 96):
>   comm "swapper/0", pid 1, jiffies 4294894636 (age 278.320s)
>   hex dump (first 32 bytes):
>     a0 b4 b0 ba ff ff ff ff 00 00 00 00 01 00 00 00  ................
>     01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<ffffffffb7de59e8>] kmemleak_alloc+0x28/0x50
>     [<ffffffffb676e2f6>] __kmalloc+0x206/0x5a0
>     [<ffffffffb69be2d3>] __register_sysctl_table+0xb3/0x1130
>     [<ffffffffb69bf36b>] register_sysctl+0x1b/0x20
>     [<ffffffffba840de1>] user_namespace_sysctl_init+0x17/0x4c
>     [<ffffffffb60022b7>] do_one_initcall+0xb7/0x2a0
>     [<ffffffffba7eb102>] kernel_init_freeable+0x597/0x636
>     [<ffffffffb7de0433>] kernel_init+0x13/0x140
>     [<ffffffffb7dfb36a>] ret_from_fork+0x2a/0x40t show
>     [<ffffffffffffffff>] 0xffffffffffffffff
>
> Let's annotate the pointer as kmemleak_not_leak() to suppress the
> kmemleak false positive.
>
> Reported-by: Jakub Kicinski <kubakici@wp.pl>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>
> This was only compiled; Jakub, could you give it a spin?
>
>  kernel/ucount.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/ucount.c b/kernel/ucount.c
> index 9d20d5d..07d69b2 100644
> --- a/kernel/ucount.c
> +++ b/kernel/ucount.c
> @@ -5,6 +5,7 @@
>   *  License.
>   */
>  
> +#include <linux/kmemleak.h>
>  #include <linux/stat.h>
>  #include <linux/sysctl.h>
>  #include <linux/slab.h>
> @@ -226,6 +227,7 @@ static __init int user_namespace_sysctl_init(void)
>  	 */
>  	user_header = register_sysctl("user", empty);
>  	BUG_ON(!user_header);
> +	kmemleak_not_leak(user_header);
>  	BUG_ON(!setup_userns_sysctls(&init_user_ns));
>  #endif
>  	return 0;
> -- 
> 2.8.0.rc3.226.g39d4020

[toc] | [prev] | [next] | [standalone]

#1514597

On Thu, 03 Nov 2016 09:54:25 -0500, Eric W. Biederman wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
> 
> > We do not ever intend to unregister "user" sysctl table, unfortunately
> > it leads kmemleak to believe that we are leaking memory:  
> 
> Sounds like an issue with kmemleak because we do retain references.
> 
> So no we don't intend to unregister the table.
> 
> As for the patch.
> 
> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
> 
> I can't see the using kmemleak_not_leak is possibly good form.  I
> would much rather have suggestions about constructs that won't confuse
> kmemleak and won't need ugly annotations that serve no purpose but to
> appease a tool.  Perhaps the user_header variable needs to be moved out
> of user_namespace_sysctl_init.

FWIW the problem now is that the compiler is clever enough to never
write the pointer to memory so kmemleak can't find it.  user_header is
just held in a register for as long as it's needed even though the
variable is static.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web