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://linux-arm.org/linux-2.6 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. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html