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
>> >
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
> > 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
> > 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
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
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.
>
>
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
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
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
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.
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
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
12 matches
Mail list logo