Re: [PATCH] userns: suppress kmemleak message

2016-12-16 Thread Fubo Chen
On Fri, Dec 16, 2016 at 10:39 AM, Johannes Berg wrote: > >> > 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 >> >

Re: [PATCH] userns: suppress kmemleak message

2016-12-16 Thread Fubo Chen
On Fri, Dec 16, 2016 at 10:39 AM, Johannes Berg wrote: > >> > 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

Re: [PATCH] userns: suppress kmemleak message

2016-12-16 Thread Johannes Berg
> > 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

Re: [PATCH] userns: suppress kmemleak message

2016-12-16 Thread Johannes Berg
> > 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

Re: [PATCH] userns: suppress kmemleak message

2016-12-15 Thread Fubo Chen
On Thu, Nov 3, 2016 at 3:54 PM, Eric W. Biederman wrote: > Dmitry Torokhov 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

Re: [PATCH] userns: suppress kmemleak message

2016-12-15 Thread Fubo Chen
On Thu, Nov 3, 2016 at 3:54 PM, Eric W. Biederman wrote: > Dmitry Torokhov 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. > >

Re: [PATCH] userns: suppress kmemleak message

2016-11-03 Thread Jakub Kicinski
On Thu, 03 Nov 2016 09:54:25 -0500, Eric W. Biederman wrote: > Dmitry Torokhov 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

Re: [PATCH] userns: suppress kmemleak message

2016-11-03 Thread Jakub Kicinski
On Thu, 03 Nov 2016 09:54:25 -0500, Eric W. Biederman wrote: > Dmitry Torokhov 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

Re: [PATCH] userns: suppress kmemleak message

2016-11-03 Thread Eric W. Biederman
Dmitry Torokhov 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

Re: [PATCH] userns: suppress kmemleak message

2016-11-03 Thread Eric W. Biederman
Dmitry Torokhov 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.

Re: [PATCH] userns: suppress kmemleak message

2016-11-03 Thread Jakub Kicinski
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 0x8807383bfd48 (size 96): > comm "swapper/0", pid 1, jiffies 4294894636 (age

Re: [PATCH] userns: suppress kmemleak message

2016-11-03 Thread Jakub Kicinski
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 0x8807383bfd48 (size 96): > comm "swapper/0", pid 1, jiffies 4294894636 (age