[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1252040671.9336.10.camel@johannes.local>
Date: Fri, 04 Sep 2009 07:04:31 +0200
From: Johannes Berg <johannes@...solutions.net>
To: "Luis R. Rodriguez" <lrodriguez@...eros.com>
Cc: Luis Rodriguez <Luis.Rodriguez@...eros.com>,
Catalin Marinas <catalin.marinas@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linville@...driver.com" <linville@...driver.com>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
Subject: Re: [PATCH] cfg80211: clear cfg80211_inform_bss() from kmemleak
reports
On Thu, 2009-09-03 at 13:43 -0700, Luis R. Rodriguez wrote:
> On Thu, Sep 03, 2009 at 11:17:17AM -0700, Johannes Berg wrote:
> > On Thu, 2009-09-03 at 11:13 -0700, Luis R. Rodriguez wrote:
> >
> > > What I meant is it gobbles it up and spits another thing out. When it
> > > gobbles it up the routine then uses kref_put().
> > >
> > > > Why can it not track this?
> > >
> > > It probably can, just not sure if it follows kref_put(), I was under
> > > the impression here it doesn't and because of it we were getting false
> > > positives. Catalin, can you confirm?
> >
> > Ah I'd think that if it can't track it then that's because we use a
> > pointer to the middle of the struct to keep track of it much of the
> > time.
>
> So you agree with the patch but not the commit log entry?
I'm not sure -- I think kmemleak should be able to figure it out, and if
you were using IBSS then we actually have a leak that we need to plug,
but otherwise I'd prefer to get some more input from Catalin first.
Catalin, is it conceivable that kmemleak reports false positives if we
use a struct like
struct pubbss {
...
};
struct bss {
...
struct pubbss pub;
};
and then keep track of &bss->pub; pointers instead of bss directly?
johannes
Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)
Powered by blists - more mailing lists