Re: [PATCH] cfg80211: clear cfg80211_inform_bss() from kmemleak reports

From: Luis R. Rodriguez
Date: Fri Sep 04 2009 - 20:04:23 EST

On Fri, Sep 4, 2009 at 3:48 PM, Luis R. Rodriguez<lrodriguez@xxxxxxxxxxx> wrote:
> On Fri, Sep 4, 2009 at 3:24 PM, Catalin Marinas<catalin.marinas@xxxxxxx> wrote:
>> On Fri, 2009-09-04 at 14:58 -0700, Luis R. Rodriguez wrote:
>>> On Fri, Sep 4, 2009 at 2:21 PM, Luis R. Rodriguez<lrodriguez@xxxxxxxxxxx> wrote:
>>> > BTW I should not I got this kmemleak report after using the clear
>>> > command by painting objects black. I'll test it now with your
>>> > suggested changes.
>>> So I pulled your git:// master into my tree and
>>> didn't even need a 'clear' command now, the output of
>>> /sys/kernel/debug/kmemleak is empty :), so I suspect you have quite a
>>> few changes which should help avoid getting false positives.
>>> Will these changes make it for 2.6.32?
>> The kmemleak branch is planned for the upcoming merging window.
> Ah great.
>> I don't
>> think you need to merge the master branch as it has a lot of
>> arm-specific code.
> That was a goof, thanks, I'll rebase onto your kmemleak branch.

I rebased and I still get these, even if I scan every now and then,
they stay up there.

On wireless_send_event() I can follow the allocated skb put onto the
skb queue wext_nlevents, and then schedule work is supposed to process
it on wireless_nlevent_process(). From there I am able to follow the
skb onto netlink_unicast() (for unicast data) but I do not see where
this ends up being freed. The compskb is set onto the
skb_shinfo(skb)->frag_list and not sure if netlink_unicast() ever
frees that.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at