From: ebiederm@xmission.com (Eric W. Biederman)
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: "Jakub Kicinski" <kubakici@wp.pl>,
linux-kernel@vger.kernel.org, "Kees Cook" <keescook@chromium.org>,
"Johannes Berg" <johannes@sipsolutions.net>,
"Maciej Żenczykowski" <zenczykowski@gmail.com>
Subject: Re: [PATCH] userns: suppress kmemleak message
Date: Thu, 03 Nov 2016 09:54:25 -0500 [thread overview]
Message-ID: <87a8dgvcke.fsf@xmission.com> (raw)
In-Reply-To: <20161103053948.GA40936@dtor-ws> (Dmitry Torokhov's message of "Wed, 2 Nov 2016 22:39:48 -0700")
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
next prev parent reply other threads:[~2016-11-03 14:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-03 5:39 [PATCH] userns: suppress kmemleak message Dmitry Torokhov
2016-11-03 14:04 ` Jakub Kicinski
2016-11-03 14:54 ` Eric W. Biederman [this message]
2016-11-03 15:06 ` Jakub Kicinski
2016-12-15 12:16 ` Fubo Chen
2016-12-16 9:39 ` Johannes Berg
2016-12-16 13:52 ` Fubo Chen
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=87a8dgvcke.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=dmitry.torokhov@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=keescook@chromium.org \
--cc=kubakici@wp.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=zenczykowski@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.