linux-kernel - Re: [PATCH] cfg80211: clear cfg80211_inform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 4 Sep 2009 17:03:45 -0700
From:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	"John W. Linville" <linville@...driver.com>,
	Johannes Berg <johannes@...solutions.net>,
	Luis Rodriguez <Luis.Rodriguez@...eros.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
Subject: Re: [PATCH] cfg80211: clear cfg80211_inform_bss() from kmemleak 
	reports

On Fri, Sep 4, 2009 at 3:48 PM, Luis R. Rodriguez<lrodriguez@...eros.com> wrote:
> On Fri, Sep 4, 2009 at 3:24 PM, Catalin Marinas<catalin.marinas@....com> 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@...eros.com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/