LinuxLists.cc - Possible memory leak in ath9k monitor mode injection

2009-11-12 11:31:31

Subject: Possible memory leak in ath9k monitor mode injection

Hi all

I am playing with ath9k/mac80211 in monitor mode and I suspect there
is a memory leak.
The leak happens when injecting in monitor mode when the destination
MAC address is unicast.
In fact there is no leak sending broadcast packet.
I wrote this minimal test case module which triggers the leak.

Cheers.

Lorenzo Bianconi

#include <linux/init.h>
#include <linux/module.h>
#include <linux/etherdevice.h>
#include <linux/netdevice.h>
#include <linux/skbuff.h>
#include <linux/timer.h>
#include <linux/version.h>

MODULE_LICENSE("Dual BSD/GPL");

const char ping_packet[] =
"\x00\x00\x1a\x00\x2f\x48\x00\x00\x06\x81\x1a\x05\x00\x00\x00\x00"
"\x10\x6c\x76\x09\xc0\x00\xdf\x00\x00\x00\x08\x00\x2c\x00\x00\x15"
"\x6d\x84\x13\x06\x00\x15\x6d\x84\x13\x05\xee\x74\x25\xdf\x3b\x78"
"\x00\x00\xaa\xaa\x03\x00\x00\x00\x08\x00\x00\x05\x5d\x44\xfb\xc3"
"\x40\x36\x5a\x21\xc9\x8e\x08\x00\x45\x00\x00\x54\x24\x22\x00\x00"
"\x40\x01\xd5\x2a\xc0\xa8\x00\x0b\xc0\xa8\x00\x01\x00\x00\x09\x95"
"\x84\x72\x01\x09\x38\x91\xfa\x4a\x51\x10\x02\x00\x08\x09\x0a\x0b"
"\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b"
"\x1c\x1d\x1e\x1f\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b"
"\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x93\x5a\x7b\x07"
;

const int ping_packet_size = 160;

struct net_device *dev;
struct timer_list timer;

int delay = HZ/1000;
static char *device = "wlan0";

module_param(device, charp, 0600);
module_param(delay, int, 0);

static struct sk_buff * create_skb(void)
{
struct sk_buff *skb = dev_alloc_skb(ping_packet_size);
if (!skb)
return NULL;

memcpy(skb_put(skb, ping_packet_size), ping_packet, ping_packet_size);
skb->dev = dev;
skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->len = ping_packet_size;
skb->pkt_type = PACKET_OUTGOING;

return skb;
}

static void inject_packet(unsigned long x)
{
struct sk_buff *skb = create_skb();
dev->netdev_ops->ndo_start_xmit(skb, dev);

mod_timer(&timer, jiffies + delay);
}

static int __init inject_init(void)
{
printk(KERN_ALERT "%s Inject, inserting module\n", __func__);
dev = dev_get_by_name(&init_net, device);

printk(KERN_ALERT "%s Inject, initializing the timer\n", __func__);
init_timer(&timer);
timer.data = (unsigned long)0;
timer.function = inject_packet;
timer.expires = jiffies + delay;
add_timer(&timer);

return 0;
}

static void __exit inject_exit(void)
{
del_timer_sync(&timer);
printk(KERN_ALERT "%s Inject, exiting module\n", __func__);
}

module_init(inject_init);
module_exit(inject_exit);

2009-11-16 15:10:18

by Matteo Croce

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Sat, Nov 14, 2009 at 3:13 AM, Luis R. Rodriguez <[email protected]> wrote:
> On Fri, Nov 13, 2009 at 4:20 AM, Matteo Croce <[email protected]> wrote:
>> On Fri, Nov 13, 2009 at 12:27 PM, ?<[email protected]> wrote:
>>> Il giorno , Lorenzo Bianconi <[email protected]> ha scritto:
>>>> 2009/11/13 Johannes Berg [email protected]>:
>>>> Yes, I tested ath5k/mac80211 and ath9k/mac80211 and both show the same
>>>> problem
>>>>
>>>> whereas madwifi/net80211, tested with the same module, has not memory
>>>> leak.
>>>>
>>>
>>> Hi all,
>>>
>>> I found a way to stop the mem leak. In the ath_tx_complete() function I have
>>> noticed that the struct tx_info_priv is not freed. I have made the following
>>> changes and now the memory remains stable. I do not know if this is the
>>> right place to put the kfree(tx_info_priv), however this seems to solve the
>>> issue.
>>>
>>> Cheers,
>>>
>>> Lorenzo
>>>
>>> @@ -1825,9 +1825,10 @@
>>> SC_OP_WAIT_FOR_TX_ACK));
>>> }
>>>
>>> - if (frame_type == ATH9K_NOT_INTERNAL)
>>> + if (frame_type == ATH9K_NOT_INTERNAL) {
>>> ieee80211_tx_status(hw, skb);
>>> - else
>>> + kfree(tx_info_priv);
>>> + } else
>>> ath9k_tx_status(hw, skb);
>>> }
>>
>> That's great. I'll try the fix with ath5k too
>
> Can you guys try Felix's RFC patches ? It removes this completely.
>
> ?Luis
>

Yes they fix the leak

2009-11-13 12:20:24

by Matteo Croce

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Fri, Nov 13, 2009 at 12:27 PM, <[email protected]> wrote:
> Il giorno , Lorenzo Bianconi <[email protected]> ha scritto:
>> 2009/11/13 Johannes Berg [email protected]>:
>> Yes, I tested ath5k/mac80211 and ath9k/mac80211 and both show the same
>> problem
>>
>> whereas madwifi/net80211, tested with the same module, has not memory
>> leak.
>>
>
> Hi all,
>
> I found a way to stop the mem leak. In the ath_tx_complete() function I have
> noticed that the struct tx_info_priv is not freed. I have made the following
> changes and now the memory remains stable. I do not know if this is the
> right place to put the kfree(tx_info_priv), however this seems to solve the
> issue.
>
> Cheers,
>
> Lorenzo
>
> @@ -1825,9 +1825,10 @@
> SC_OP_WAIT_FOR_TX_ACK));
> }
>
> - if (frame_type == ATH9K_NOT_INTERNAL)
> + if (frame_type == ATH9K_NOT_INTERNAL) {
> ieee80211_tx_status(hw, skb);
> - else
> + kfree(tx_info_priv);
> + } else
> ath9k_tx_status(hw, skb);
> }

That's great. I'll try the fix with ath5k too

2009-11-14 02:13:39

by Luis R. Rodriguez

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Fri, Nov 13, 2009 at 4:20 AM, Matteo Croce <[email protected]> wrote:
> On Fri, Nov 13, 2009 at 12:27 PM, <[email protected]> wrote:
>> Il giorno , Lorenzo Bianconi <[email protected]> ha scritto:
>>> 2009/11/13 Johannes Berg [email protected]>:
>>> Yes, I tested ath5k/mac80211 and ath9k/mac80211 and both show the same
>>> problem
>>>
>>> whereas madwifi/net80211, tested with the same module, has not memory
>>> leak.
>>>
>>
>> Hi all,
>>
>> I found a way to stop the mem leak. In the ath_tx_complete() function I have
>> noticed that the struct tx_info_priv is not freed. I have made the following
>> changes and now the memory remains stable. I do not know if this is the
>> right place to put the kfree(tx_info_priv), however this seems to solve the
>> issue.
>>
>> Cheers,
>>
>> Lorenzo
>>
>> @@ -1825,9 +1825,10 @@
>> SC_OP_WAIT_FOR_TX_ACK));
>> }
>>
>> - if (frame_type == ATH9K_NOT_INTERNAL)
>> + if (frame_type == ATH9K_NOT_INTERNAL) {
>> ieee80211_tx_status(hw, skb);
>> - else
>> + kfree(tx_info_priv);
>> + } else
>> ath9k_tx_status(hw, skb);
>> }
>
> That's great. I'll try the fix with ath5k too

Can you guys try Felix's RFC patches ? It removes this completely.

Luis

2009-11-12 15:44:37

by Luis R. Rodriguez

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, Nov 12, 2009 at 06:18:46AM -0800, Matteo Croce wrote:
> On Thu, Nov 12, 2009 at 12:31 PM, Lorenzo Bianconi
> <[email protected]> wrote:
> > Hi all
> >
> > I am playing with ath9k/mac80211 in monitor mode and I suspect there
> > is a memory leak.
> > The leak happens when injecting in monitor mode when the destination
> > MAC address is unicast.
> > In fact there is no leak sending broadcast packet.
> > I wrote this minimal test case module which triggers the leak.
>
> I can reproduce it with ath5k but not with madwifi, so the leak could
> be in mac80211

Can you please resend the thread to linux-wireless for wider review, with
the code snippet and all?

Luis

2009-11-12 19:35:43

by Luis R. Rodriguez

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
<[email protected]> wrote:
> On Thu, 2009-11-12 at 20:18 +0100, Matteo Croce wrote:
>
>> # echo scan >/sys/kernel/debug/kmemleak ; cat
>> /sys/kernel/debug/kmemleak
>> kmemleak: 197 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>> unreferenced object 0xc5cfea80 (size 192):
>> comm "softirq", pid 0, jiffies 14191
>> backtrace:
>> [<ffffffff>] 0xffffffff
>
> that's kinda useless, can you run

But if you insist on using kmemleak, try clearing the list

echo clear > kmemleak

Then scan

echo scan > kmemleak

then run your frame injection tests and then re-run scan.

echo scan > kmemleak

Then paste the output here.

Luis

2009-11-12 15:49:15

by Luis R. Rodriguez

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, Nov 12, 2009 at 7:44 AM, Luis R. Rodriguez
<[email protected]> wrote:
> On Thu, Nov 12, 2009 at 06:18:46AM -0800, Matteo Croce wrote:
>> On Thu, Nov 12, 2009 at 12:31 PM, Lorenzo Bianconi
>> <[email protected]> wrote:
>> > Hi all
>> >
>> > I am playing with ath9k/mac80211 in monitor mode and I suspect there
>> > is a memory leak.
>> > The leak happens when injecting in monitor mode when the destination
>> > MAC address is unicast.
>> > In fact there is no leak sending broadcast packet.
>> > I wrote this minimal test case module which triggers the leak.
>>
>> I can reproduce it with ath5k but not with madwifi, so the leak could
>> be in mac80211
>
> Can you please resend the thread to linux-wireless for wider review, with
> the code snippet and all?

Sorry failed to notice you already had.

Luis

2009-11-13 07:31:22

by Johannes Berg

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, 2009-11-12 at 23:18 +0100, Matteo Croce wrote:

> kmalloc-64 is definitely getting fat

Is it the same with ath5k?

I don't see any allocations like that in mac80211.

johannes

Attachments:

signature.asc (801.00 B)
This is a digitally signed message part

2009-11-12 22:09:11

by Matteo Croce

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

2009-11-12 23:04:23

by Matteo Croce

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, Nov 12, 2009 at 11:28 PM, Luis R. Rodriguez
<[email protected]> wrote:
> On Thu, Nov 12, 2009 at 02:16:09PM -0800, Matteo Croce wrote:
>> On Thu, Nov 12, 2009 at 8:35 PM, Luis R. Rodriguez
>> <[email protected]> wrote:
>> > On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
>> > <[email protected]> wrote:
>> >> On Thu, 2009-11-12 at 20:18 +0100, Matteo Croce wrote:
>> >>
>> >>> # echo scan >/sys/kernel/debug/kmemleak ; cat
>> >>> /sys/kernel/debug/kmemleak
>> >>> kmemleak: 197 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>> >>> unreferenced object 0xc5cfea80 (size 192):
>> >>> ? comm "softirq", pid 0, jiffies 14191
>> >>> ? backtrace:
>> >>> ? ? [<ffffffff>] 0xffffffff
>> >>
>> >> that's kinda useless, can you run
>> >
>> > But if you insist on using kmemleak, try clearing the list
>> >
>> > echo clear > kmemleak
>> >
>> > Then scan
>> >
>> > echo scan > kmemleak
>> >
>> > then run your frame injection tests and then re-run scan.
>> >
>> > echo scan > kmemleak
>> >
>> > Then paste the output here.
>> >
>> > ?Luis
>> >
>>
>> root@alix:/sys/kernel/debug# rmmod inject
>> inject_exit Inject, exiting module
>> root@alix:/sys/kernel/debug# echo clear > kmemleak
>
> I forgot you're on 2.6.31, clear stuff was added to kmemleak for 2.6.32.
>
>> root@alix:/sys/kernel/debug# echo scan >kmemleak
>> kmemleak: 61037 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>> root@alix:/sys/kernel/debug# modprobe inject
>> inject_init Inject, inserting module
>> inject_init Inject, initializing the timer
>> root@alix:/sys/kernel/debug# echo scan >kmemleak
>> root@alix:/sys/kernel/debug# cat kmemleak
>> unreferenced object 0xccd48e70 (size 64):
>
> What's 0xccd48e70 and friends? Can you enable debugging on your kernel?
>
> ?Luis
>

I've built a monolithic kernel, no luck:

(gdb) l *0xcee26a80
No source file for address 0xcee26a80.
(gdb) l *0xcee26a10
No source file for address 0xcee26a10.
(gdb) l *0xcee262a0
No source file for address 0xcee262a0.

2009-11-12 22:37:52

by Matteo Croce

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, Nov 12, 2009 at 11:28 PM, Luis R. Rodriguez
<[email protected]> wrote:
> On Thu, Nov 12, 2009 at 02:16:09PM -0800, Matteo Croce wrote:
>> On Thu, Nov 12, 2009 at 8:35 PM, Luis R. Rodriguez
>> <[email protected]> wrote:
>> > On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
>> > <[email protected]> wrote:
>> >> On Thu, 2009-11-12 at 20:18 +0100, Matteo Croce wrote:
>> >>
>> >>> # echo scan >/sys/kernel/debug/kmemleak ; cat
>> >>> /sys/kernel/debug/kmemleak
>> >>> kmemleak: 197 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>> >>> unreferenced object 0xc5cfea80 (size 192):
>> >>> ? comm "softirq", pid 0, jiffies 14191
>> >>> ? backtrace:
>> >>> ? ? [<ffffffff>] 0xffffffff
>> >>
>> >> that's kinda useless, can you run
>> >
>> > But if you insist on using kmemleak, try clearing the list
>> >
>> > echo clear > kmemleak
>> >
>> > Then scan
>> >
>> > echo scan > kmemleak
>> >
>> > then run your frame injection tests and then re-run scan.
>> >
>> > echo scan > kmemleak
>> >
>> > Then paste the output here.
>> >
>> > ?Luis
>> >
>>
>> root@alix:/sys/kernel/debug# rmmod inject
>> inject_exit Inject, exiting module
>> root@alix:/sys/kernel/debug# echo clear > kmemleak
>
> I forgot you're on 2.6.31, clear stuff was added to kmemleak for 2.6.32.
>
>> root@alix:/sys/kernel/debug# echo scan >kmemleak
>> kmemleak: 61037 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>> root@alix:/sys/kernel/debug# modprobe inject
>> inject_init Inject, inserting module
>> inject_init Inject, initializing the timer
>> root@alix:/sys/kernel/debug# echo scan >kmemleak
>> root@alix:/sys/kernel/debug# cat kmemleak
>> unreferenced object 0xccd48e70 (size 64):
>
> What's 0xccd48e70 and friends? Can you enable debugging on your kernel?
>
> ?Luis
>

Debugging is enabled but i guess it's a kernel module

root@alix:/usr/src/wireless-testing# gdb vmlinux
GNU gdb (GDB) 7.0-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/src/wireless-testing/vmlinux...done.
(gdb) l *0xccd48e70
No source file for address 0xccd48e70.
(gdb)

2009-11-12 22:16:30

by Matteo Croce

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, Nov 12, 2009 at 8:35 PM, Luis R. Rodriguez
<[email protected]> wrote:
> On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
> <[email protected]> wrote:
>> On Thu, 2009-11-12 at 20:18 +0100, Matteo Croce wrote:
>>
>>> # echo scan >/sys/kernel/debug/kmemleak ; cat
>>> /sys/kernel/debug/kmemleak
>>> kmemleak: 197 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>>> unreferenced object 0xc5cfea80 (size 192):
>>> ? comm "softirq", pid 0, jiffies 14191
>>> ? backtrace:
>>> ? ? [<ffffffff>] 0xffffffff
>>
>> that's kinda useless, can you run
>
> But if you insist on using kmemleak, try clearing the list
>
> echo clear > kmemleak
>
> Then scan
>
> echo scan > kmemleak
>
> then run your frame injection tests and then re-run scan.
>
> echo scan > kmemleak
>
> Then paste the output here.
>
> ?Luis
>

root@alix:/sys/kernel/debug# rmmod inject
inject_exit Inject, exiting module
root@alix:/sys/kernel/debug# echo clear > kmemleak
root@alix:/sys/kernel/debug# echo scan >kmemleak
kmemleak: 61037 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
root@alix:/sys/kernel/debug# modprobe inject
inject_init Inject, inserting module
inject_init Inject, initializing the timer
root@alix:/sys/kernel/debug# echo scan >kmemleak
root@alix:/sys/kernel/debug# cat kmemleak
unreferenced object 0xccd48e70 (size 64):
comm "softirq", pid 0, jiffies 3615
hex dump (first 32 bytes):
20 89 ed ce b9 83 d2 00 00 00 01 1b 00 80 00 04 ...............
00 00 00 80 80 80 80 80 80 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xcd6f7930 (size 64):
comm "softirq", pid 0, jiffies 11486
hex dump (first 32 bytes):
20 89 ed ce 6a a3 83 05 00 00 01 1b 00 80 00 04 ...j...........
00 00 00 80 80 80 80 80 80 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xcbe57c40 (size 64):
comm "softirq", pid 0, jiffies 28666
hex dump (first 32 bytes):
20 89 ed ce cc 52 c1 0f 00 00 01 1b 00 80 00 04 ....R..........
00 00 00 80 80 80 80 80 80 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xcbe71850 (size 64):
comm "softirq", pid 0, jiffies 28981
hex dump (first 32 bytes):
20 89 ed ce c9 64 f1 0f 00 00 01 1b 00 80 00 04 ....d..........
00 00 00 80 80 80 80 80 80 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xcbe71f50 (size 64):
comm "softirq", pid 0, jiffies 30041
hex dump (first 32 bytes):
20 89 ed ce 4a 26 93 10 00 00 01 1b 00 80 00 04 ...J&..........
00 00 00 80 80 80 80 80 80 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xcb4b0230 (size 64):
comm "softirq", pid 0, jiffies 35770
hex dump (first 32 bytes):
20 89 ed ce 79 66 fd 13 00 00 01 1b 00 80 00 04 ...yf..........
00 00 00 80 80 80 80 80 80 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xcb4b02a0 (size 64):
comm "softirq", pid 0, jiffies 35771
hex dump (first 32 bytes):
20 89 ed ce b1 8d fd 13 00 00 01 1b 00 80 00 04 ...............
00 00 00 80 80 80 80 80 80 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff>] 0xffffffff

2009-11-12 19:18:31

by Matteo Croce

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, Nov 12, 2009 at 4:49 PM, Luis R. Rodriguez
<[email protected]> wrote:
> On Thu, Nov 12, 2009 at 7:44 AM, Luis R. Rodriguez
> <[email protected]> wrote:
>> On Thu, Nov 12, 2009 at 06:18:46AM -0800, Matteo Croce wrote:
>>> On Thu, Nov 12, 2009 at 12:31 PM, Lorenzo Bianconi
>>> <[email protected]> wrote:
>>> > Hi all
>>> >
>>> > I am playing with ath9k/mac80211 in monitor mode and I suspect there
>>> > is a memory leak.
>>> > The leak happens when injecting in monitor mode when the destination
>>> > MAC address is unicast.
>>> > In fact there is no leak sending broadcast packet.
>>> > I wrote this minimal test case module which triggers the leak.
>>>
>>> I can reproduce it with ath5k but not with madwifi, so the leak could
>>> be in mac80211
>>
>> Can you please resend the thread to linux-wireless for wider review, with
>> the code snippet and all?

I have compiled a 2.6.31 x86 kernel with kmemleak, and when injecting
the memory goes rapidly down:

# while sleep 10; do free |grep Mem; done
Mem: 127112 41780 85332 0 224
Mem: 127112 42580 84532 0 224
Mem: 127112 43360 83752 0 224
Mem: 127112 44160 82952 0 224
Mem: 127112 44960 82152 0 224
Mem: 127112 48140 78972 0 224

just to be sure that any program is stoling RAM:

# ps
PID USER VSZ STAT COMMAND
1 root 932 S init
2 root 0 SW< [kthreadd]
3 root 0 SW< [ksoftirqd/0]
4 root 0 SW< [watchdog/0]
5 root 0 SW< [events/0]
6 root 0 SW< [khelper]
9 root 0 SW< [async/mgr]
61 root 0 SW< [kblockd/0]
66 root 0 SW< [ata/0]
67 root 0 SW< [ata_aux]
107 root 0 SW [khungtaskd]
108 root 0 SW [pdflush]
109 root 0 SW [pdflush]
110 root 0 SW< [kswapd0]
111 root 0 SW< [aio/0]
112 root 0 SW< [crypto/0]
194 root 0 SW< [scsi_eh_0]
197 root 0 SW< [scsi_eh_1]
213 root 0 SWN [kmemleak]
369 root 936 R /bin/ash --login
505 root 0 SW< [phy0]
4369 root 932 S init
4371 root 924 R ps

This time I'm using ath5k with an AR5212 card instead of ath9k, so the
leak definitely is in mac80211
This is what kmemleak reports:

# echo scan >/sys/kernel/debug/kmemleak ; cat
/sys/kernel/debug/kmemleak
kmemleak: 197 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
unreferenced object 0xc5cfea80 (size 192):
comm "softirq", pid 0, jiffies 14191
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d1a400 (size 1024):
comm "softirq", pid 0, jiffies 14191
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc7ac9e40 (size 192):
comm "softirq", pid 0, jiffies 14192
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6a05000 (size 1024):
comm "softirq", pid 0, jiffies 14192
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc7ac9d80 (size 192):
comm "softirq", pid 0, jiffies 14193
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6a04800 (size 1024):
comm "softirq", pid 0, jiffies 14193
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc7ac9c00 (size 192):
comm "softirq", pid 0, jiffies 14194
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc707b800 (size 1024):
comm "softirq", pid 0, jiffies 14194
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc7ac9f00 (size 192):
comm "softirq", pid 0, jiffies 14195
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6a05400 (size 1024):
comm "softirq", pid 0, jiffies 14195
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc69df480 (size 192):
comm "softirq", pid 0, jiffies 14196
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d1c000 (size 1024):
comm "softirq", pid 0, jiffies 14196
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc69df540 (size 192):
comm "softirq", pid 0, jiffies 14197
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d1c800 (size 1024):
comm "softirq", pid 0, jiffies 14197
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc69df3c0 (size 192):
comm "softirq", pid 0, jiffies 14198
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d1cc00 (size 1024):
comm "softirq", pid 0, jiffies 14198
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc69df300 (size 192):
comm "softirq", pid 0, jiffies 14199
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d1d000 (size 1024):
comm "softirq", pid 0, jiffies 14199
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc69df600 (size 192):
comm "softirq", pid 0, jiffies 14200
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d1d400 (size 1024):
comm "softirq", pid 0, jiffies 14200
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc69df180 (size 192):
comm "softirq", pid 0, jiffies 14201
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d1d800 (size 1024):
comm "softirq", pid 0, jiffies 14201
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc69df6c0 (size 192):
comm "softirq", pid 0, jiffies 14202
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d1dc00 (size 1024):
comm "softirq", pid 0, jiffies 14202
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc69df780 (size 192):
comm "softirq", pid 0, jiffies 14203
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6a04400 (size 1024):
comm "softirq", pid 0, jiffies 14203
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc69df0c0 (size 192):
comm "softirq", pid 0, jiffies 14204
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6a05800 (size 1024):
comm "softirq", pid 0, jiffies 14204
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc69df000 (size 192):
comm "softirq", pid 0, jiffies 14205
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6cb7800 (size 1024):
comm "softirq", pid 0, jiffies 14205
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc69df840 (size 192):
comm "softirq", pid 0, jiffies 14206
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d1c400 (size 1024):
comm "softirq", pid 0, jiffies 14206
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d000c0 (size 192):
comm "softirq", pid 0, jiffies 14207
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6cb9800 (size 1024):
comm "softirq", pid 0, jiffies 14256
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d14780 (size 192):
comm "softirq", pid 0, jiffies 14257
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d24000 (size 1024):
comm "softirq", pid 0, jiffies 14257
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d14840 (size 192):
comm "softirq", pid 0, jiffies 14258
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d24800 (size 1024):
comm "softirq", pid 0, jiffies 14258
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d14900 (size 192):
comm "softirq", pid 0, jiffies 14259
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d24c00 (size 1024):
comm "softirq", pid 0, jiffies 14259
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d149c0 (size 192):
comm "softirq", pid 0, jiffies 14260
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d25000 (size 1024):
comm "softirq", pid 0, jiffies 14260
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d14a80 (size 192):
comm "softirq", pid 0, jiffies 14261
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d25400 (size 1024):
comm "softirq", pid 0, jiffies 14261
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d14b40 (size 192):
comm "softirq", pid 0, jiffies 14262
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d25800 (size 1024):
comm "softirq", pid 0, jiffies 14262
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d14c00 (size 192):
comm "softirq", pid 0, jiffies 14263
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d25c00 (size 1024):
comm "softirq", pid 0, jiffies 14263
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d14cc0 (size 192):
comm "softirq", pid 0, jiffies 14264
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6a0fc00 (size 1024):
comm "softirq", pid 0, jiffies 14264
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d14d80 (size 192):
comm "softirq", pid 0, jiffies 14265
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6a0f400 (size 1024):
comm "softirq", pid 0, jiffies 14265
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d14e40 (size 192):
comm "softirq", pid 0, jiffies 14266
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc7273800 (size 1024):
comm "softirq", pid 0, jiffies 14266
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d14f00 (size 192):
comm "softirq", pid 0, jiffies 14267
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc7273c00 (size 1024):
comm "softirq", pid 0, jiffies 14267
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6ca56c0 (size 192):
comm "softirq", pid 0, jiffies 14268
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d24400 (size 1024):
comm "softirq", pid 0, jiffies 14268
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6ca5540 (size 192):
comm "softirq", pid 0, jiffies 14269
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6cb8400 (size 1024):
comm "softirq", pid 0, jiffies 14269
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6ca50c0 (size 192):
comm "softirq", pid 0, jiffies 14271
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc7272c00 (size 1024):
comm "softirq", pid 0, jiffies 14271
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6ca5480 (size 192):
comm "softirq", pid 0, jiffies 14272
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d26000 (size 1024):
comm "softirq", pid 0, jiffies 14272
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6ca5180 (size 192):
comm "softirq", pid 0, jiffies 14273
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5d26800 (size 1024):
comm "softirq", pid 0, jiffies 14273
backtrace:
[<ffffffff>] 0xffffffff

and again:

# echo scan >/sys/kernel/debug/kmemleak ; cat /sys/kernel/debug/km
emleak
kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
unreferenced object 0xc586b540 (size 192):
comm "softirq", pid 0, jiffies 18612
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc70c0800 (size 1024):
comm "softirq", pid 0, jiffies 18612
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc586b600 (size 192):
comm "softirq", pid 0, jiffies 18613
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6d81800 (size 1024):
comm "softirq", pid 0, jiffies 18613
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc586b6c0 (size 192):
comm "softirq", pid 0, jiffies 18614
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6b96800 (size 1024):
comm "softirq", pid 0, jiffies 18614
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc586b840 (size 192):
comm "softirq", pid 0, jiffies 18615
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6b96000 (size 1024):
comm "softirq", pid 0, jiffies 18615
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc586b900 (size 192):
comm "softirq", pid 0, jiffies 18616
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6b96c00 (size 1024):
comm "softirq", pid 0, jiffies 18616
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc586b9c0 (size 192):
comm "softirq", pid 0, jiffies 18617
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc5886400 (size 1024):
comm "softirq", pid 0, jiffies 18617
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc586ba80 (size 192):
comm "softirq", pid 0, jiffies 18618
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6b97400 (size 1024):
comm "softirq", pid 0, jiffies 18618
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc586bb40 (size 192):
comm "softirq", pid 0, jiffies 18619
backtrace:
[<ffffffff>] 0xffffffff
unreferenced object 0xc6baa400 (size 1024):
comm "softirq", pid 0, jiffies 18619
backtrace:
[<ffffffff>] 0xffffffff

2009-11-12 22:58:49

by Lorenzo Bianconi

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

> Debugging is enabled but i guess it's a kernel module
>
> root@alix:/usr/src/wireless-testing# gdb vmlinux
> GNU gdb (GDB) 7.0-debian
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. ?Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i486-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/src/wireless-testing/vmlinux...done.
> (gdb) l *0xccd48e70
> No source file for address 0xccd48e70.
> (gdb)
>

Running the minimal test case module on a 2.6.31.5 standard kernel I
obtained these results:

Cheers.

Lorenzo

23:18:18 up 5 min, 4 users, load average: 0.11, 0.37, 0.20
total used free shared buffers cached
Mem: 3785552 699684 3085868 0 35404 307544
-/+ buffers/cache: 356736 3428816
Swap: 947824 0 947824

23:19:03 up 5 min, 4 users, load average: 0.10, 0.33, 0.19
total used free shared buffers cached
Mem: 3785552 702244 3083308 0 35436 307548
-/+ buffers/cache: 359260 3426292
Swap: 947824 0 947824

23:19:46 up 6 min, 4 users, load average: 0.09, 0.30, 0.18
total used free shared buffers cached
Mem: 3785552 705708 3079844 0 35476 307548
-/+ buffers/cache: 362684 3422868
Swap: 947824 0 947824

23:22:17 up 9 min, 4 users, load average: 0.00, 0.17, 0.15
total used free shared buffers cached
Mem: 3785552 722036 3063516 0 35884 307560
-/+ buffers/cache: 378592 3406960
Swap: 947824 0 947824

23:34:34 up 21 min, 4 users, load average: 0.14, 0.09, 0.11
total used free shared buffers cached
Mem: 3785552 809180 2976372 0 39320 325364
-/+ buffers/cache: 444496 3341056
Swap: 947824 0 947824

diff -u a b

@@ -43,15 +43,15 @@
132 in /sys/kernel/slab/mm_struct
132 in /sys/kernel/slab/:t-0000896
146 in /sys/kernel/slab/:at-0000056
+146 in /sys/kernel/slab/:at-0000112
146 in /sys/kernel/slab/ext4_free_block_extents
+146 in /sys/kernel/slab/jbd2_journal_head
146 in /sys/kernel/slab/skbuff_fclone_cache
146 in /sys/kernel/slab/:t-0000448
150 in /sys/kernel/slab/sighand_cache
156 in /sys/kernel/slab/:at-0000104
-156 in /sys/kernel/slab/:at-0000112
156 in /sys/kernel/slab/ext4_prealloc_space
156 in /sys/kernel/slab/fsnotify_event
-156 in /sys/kernel/slab/jbd2_journal_head
156 in /sys/kernel/slab/:t-0000104
170 in /sys/kernel/slab/Acpi-Parse
170 in /sys/kernel/slab/bip-16
@@ -94,7 +94,7 @@
420 in /sys/kernel/slab/idr_layer_cache
420 in /sys/kernel/slab/:t-0000544
549 in /sys/kernel/slab/kmalloc-8192
-551 in /sys/kernel/slab/:t-0008192
+549 in /sys/kernel/slab/:t-0008192
623 in /sys/kernel/slab/biovec-256
623 in /sys/kernel/slab/kmalloc-4096
623 in /sys/kernel/slab/names_cache
@@ -104,20 +104,20 @@
772 in /sys/kernel/slab/sgpool-16
772 in /sys/kernel/slab/:t-0000512
824 in /sys/kernel/slab/proc_inode_cache
-899 in /sys/kernel/slab/bip-1
-899 in /sys/kernel/slab/cred_jar
-899 in /sys/kernel/slab/eventpoll_epi
-899 in /sys/kernel/slab/kmalloc-128
-899 in /sys/kernel/slab/pid
-899 in /sys/kernel/slab/request_sock_TCP
-899 in /sys/kernel/slab/scsi_sense_cache
-899 in /sys/kernel/slab/:t-0000128
-899 in /sys/kernel/slab/uid_cache
+898 in /sys/kernel/slab/bip-1
+898 in /sys/kernel/slab/cred_jar
+898 in /sys/kernel/slab/eventpoll_epi
+898 in /sys/kernel/slab/kmalloc-128
+898 in /sys/kernel/slab/pid
+898 in /sys/kernel/slab/request_sock_TCP
+898 in /sys/kernel/slab/scsi_sense_cache
+898 in /sys/kernel/slab/:t-0000128
+898 in /sys/kernel/slab/uid_cache
1405 in /sys/kernel/slab/shmem_inode_cache
-1992 in /sys/kernel/slab/kmalloc-1024
-1994 in /sys/kernel/slab/biovec-64
-1994 in /sys/kernel/slab/:t-0001024
-1995 in /sys/kernel/slab/sgpool-32
+1991 in /sys/kernel/slab/sgpool-32
+1993 in /sys/kernel/slab/biovec-64
+1993 in /sys/kernel/slab/kmalloc-1024
+1993 in /sys/kernel/slab/:t-0001024
2097 in /sys/kernel/slab/Acpi-Operand
2097 in /sys/kernel/slab/Acpi-ParseExt
2097 in /sys/kernel/slab/eventpoll_pwq
@@ -126,15 +126,15 @@
2294 in /sys/kernel/slab/biovec-1
2294 in /sys/kernel/slab/kmalloc-16
2294 in /sys/kernel/slab/:t-0000016
-2565 in /sys/kernel/slab/biovec-4
-2565 in /sys/kernel/slab/fib6_nodes
-2565 in /sys/kernel/slab/fs_cache
-2565 in /sys/kernel/slab/inet_peer_cache
-2565 in /sys/kernel/slab/kmalloc-64
-2565 in /sys/kernel/slab/secpath_cache
-2565 in /sys/kernel/slab/:t-0000064
-2565 in /sys/kernel/slab/xfrm6_tunnel_spi
-2729 in /sys/kernel/slab/anon_vma
+2517 in /sys/kernel/slab/biovec-4
+2517 in /sys/kernel/slab/fib6_nodes
+2517 in /sys/kernel/slab/fs_cache
+2517 in /sys/kernel/slab/inet_peer_cache
+2517 in /sys/kernel/slab/kmalloc-64
+2517 in /sys/kernel/slab/secpath_cache
+2517 in /sys/kernel/slab/:t-0000064
+2517 in /sys/kernel/slab/xfrm6_tunnel_spi
+2776 in /sys/kernel/slab/anon_vma
2936 in /sys/kernel/slab/Acpi-Namespace
2936 in /sys/kernel/slab/dnotify_struct
2936 in /sys/kernel/slab/inotify_event_private_data
@@ -143,40 +143,40 @@
2936 in /sys/kernel/slab/nv_pte_t
2936 in /sys/kernel/slab/:t-0000032
2936 in /sys/kernel/slab/tcp_bind_bucket
-2970 in /sys/kernel/slab/scsi_cmd_cache
-2971 in /sys/kernel/slab/kiocb
-2971 in /sys/kernel/slab/skbuff_head_cache
-2972 in /sys/kernel/slab/arp_cache
-2972 in /sys/kernel/slab/kmalloc-256
-2972 in /sys/kernel/slab/mnt_cache
-2972 in /sys/kernel/slab/sgpool-8
-2973 in /sys/kernel/slab/biovec-16
-2973 in /sys/kernel/slab/ndisc_cache
2973 in /sys/kernel/slab/:t-0000256
-3086 in /sys/kernel/slab/inode_cache
+2974 in /sys/kernel/slab/kiocb
+2975 in /sys/kernel/slab/biovec-16
+2975 in /sys/kernel/slab/kmalloc-256
+2975 in /sys/kernel/slab/ndisc_cache
+2976 in /sys/kernel/slab/arp_cache
+2976 in /sys/kernel/slab/skbuff_head_cache
+2977 in /sys/kernel/slab/mnt_cache
+2977 in /sys/kernel/slab/scsi_cmd_cache
+2977 in /sys/kernel/slab/sgpool-8
+3084 in /sys/kernel/slab/inode_cache
3578 in /sys/kernel/slab/kmalloc-8
3578 in /sys/kernel/slab/:t-0000008
-4808 in /sys/kernel/slab/filp
-4812 in /sys/kernel/slab/bio-0
-4812 in /sys/kernel/slab/bip-4
-4814 in /sys/kernel/slab/request_sock_TCPv6
-4816 in /sys/kernel/slab/kmalloc-192
-4820 in /sys/kernel/slab/:t-0000192
-5963 in /sys/kernel/slab/radix_tree_node
+4786 in /sys/kernel/slab/request_sock_TCPv6
+4793 in /sys/kernel/slab/bip-4
+4793 in /sys/kernel/slab/kmalloc-192
+4793 in /sys/kernel/slab/:t-0000192
+4795 in /sys/kernel/slab/filp
+4796 in /sys/kernel/slab/bio-0
+6040 in /sys/kernel/slab/radix_tree_node
10173 in /sys/kernel/slab/Acpi-State
10173 in /sys/kernel/slab/blkdev_ioc
10173 in /sys/kernel/slab/scsi_tgt_cmd
10173 in /sys/kernel/slab/sysfs_dir_cache
10173 in /sys/kernel/slab/:t-0000080
-10796 in /sys/kernel/slab/buffer_head
-11532 in /sys/kernel/slab/vm_area_struct
-11557 in /sys/kernel/slab/cfq_io_context
-11557 in /sys/kernel/slab/cfq_queue
-11557 in /sys/kernel/slab/:t-0000168
-11719 in /sys/kernel/slab/ext4_inode_cache
-27271 in /sys/kernel/slab/:at-0000192
-27271 in /sys/kernel/slab/dentry
-128562 in /sys/kernel/slab/flow_cache
-128562 in /sys/kernel/slab/kmalloc-96
-128604 in /sys/kernel/slab/:t-0000096
-241093 in /sys/kernel/slab/kmemleak_object
+10947 in /sys/kernel/slab/buffer_head
+11315 in /sys/kernel/slab/cfq_io_context
+11315 in /sys/kernel/slab/cfq_queue
+11315 in /sys/kernel/slab/:t-0000168
+11315 in /sys/kernel/slab/vm_area_struct
+11800 in /sys/kernel/slab/ext4_inode_cache
+27442 in /sys/kernel/slab/:at-0000192
+27442 in /sys/kernel/slab/dentry
+155568 in /sys/kernel/slab/flow_cache
+155568 in /sys/kernel/slab/kmalloc-96
+155610 in /sys/kernel/slab/:t-0000096
+268261 in /sys/kernel/slab/kmemleak_object

2009-11-12 14:19:02

by Matteo Croce

[permalink] [raw]

Subject: Re: Possible memory leak in ath9k monitor mode injection

On Thu, Nov 12, 2009 at 12:31 PM, Lorenzo Bianconi
<[email protected]> wrote:
> Hi all
>
> I am playing with ath9k/mac80211 in monitor mode and I suspect there
> is a memory leak.
> The leak happens when injecting in monitor mode when the destination
> MAC address is unicast.
> In fact there is no leak sending broadcast packet.
> I wrote this minimal test case module which triggers the leak.

I can reproduce it with ath5k but not with madwifi, so the leak could
be in mac80211

2009-11-13 07:06:36

by Johannes Berg

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Fri, 2009-11-13 at 00:04 +0100, Matteo Croce wrote:

> >> root@alix:/sys/kernel/debug# cat kmemleak
> >> unreferenced object 0xccd48e70 (size 64):
> >
> > What's 0xccd48e70 and friends? Can you enable debugging on your kernel?
> >
> > Luis
> >
>
> I've built a monolithic kernel, no luck:
>
> (gdb) l *0xcee26a80
> No source file for address 0xcee26a80.

Not surprising at all since that's a kmalloc'ed object, not a .text
address ...

johannes

Attachments:

signature.asc (801.00 B)
This is a digitally signed message part

2009-11-12 22:18:53

by Matteo Croce

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, Nov 12, 2009 at 8:31 PM, Johannes Berg
<[email protected]> wrote:
> On Thu, 2009-11-12 at 20:18 +0100, Matteo Croce wrote:
>
>> # echo scan >/sys/kernel/debug/kmemleak ; cat
>> /sys/kernel/debug/kmemleak
>> kmemleak: 197 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>> unreferenced object 0xc5cfea80 (size 192):
>> ? comm "softirq", pid 0, jiffies 14191
>> ? backtrace:
>> ? ? [<ffffffff>] 0xffffffff
>
> that's kinda useless, can you run
>
> for slab in /sys/kernel/slab/* ; do echo $(cat $slab/objects) in $slab ; done|sort -n
>
> and tell us which one increases most?
>
> johannes
>

kmalloc-64 is definitely getting fat

root@alix:~/leak# diff -u leak.1 leak.3
--- leak.1 2000-01-01 01:19:56.817434067 +0100
+++ leak.3 2000-01-01 01:29:48.917438188 +0100
@@ -55,56 +55,56 @@
21 in /sys/kernel/slab/sigqueue
22 in /sys/kernel/slab/files_cache
24 in /sys/kernel/slab/sock_inode_cache
+25 in /sys/kernel/slab/bio-0
25 in /sys/kernel/slab/ext4_alloc_context
25 in /sys/kernel/slab/scsi_sense_cache
26 in /sys/kernel/slab/cfq_queue
-27 in /sys/kernel/slab/bio-0
28 in /sys/kernel/slab/file_lock_cache
30 in /sys/kernel/slab/cfq_io_context
30 in /sys/kernel/slab/kmalloc-2048
33 in /sys/kernel/slab/task_xstate
36 in /sys/kernel/slab/ext4_prealloc_space
-36 in /sys/kernel/slab/sighand_cache
37 in /sys/kernel/slab/signal_cache
39 in /sys/kernel/slab/inotify_inode_mark_entry
39 in /sys/kernel/slab/jbd2_journal_head
42 in /sys/kernel/slab/fib6_nodes
42 in /sys/kernel/slab/fs_cache
42 in /sys/kernel/slab/inet_peer_cache
+42 in /sys/kernel/slab/sighand_cache
42 in /sys/kernel/slab/task_struct
42 in /sys/kernel/slab/uid_cache
46 in /sys/kernel/slab/blkdev_ioc
51 in /sys/kernel/slab/ext4_free_block_extents
51 in /sys/kernel/slab/ip_fib_hash
51 in /sys/kernel/slab/sd_ext_cdb
-64 in /sys/kernel/slab/cred_jar
64 in /sys/kernel/slab/jbd2_journal_handle
64 in /sys/kernel/slab/jbd2_revoke_record
64 in /sys/kernel/slab/pid
+65 in /sys/kernel/slab/cred_jar
68 in /sys/kernel/slab/kmalloc-128
73 in /sys/kernel/slab/jbd2_revoke_table
-82 in /sys/kernel/slab/kmalloc-1024
+81 in /sys/kernel/slab/kmalloc-1024
87 in /sys/kernel/slab/kmalloc-512
102 in /sys/kernel/slab/kmalloc-192
128 in /sys/kernel/slab/kmemleak_scan_area
142 in /sys/kernel/slab/kmalloc-256
147 in /sys/kernel/slab/idr_layer_cache
152 in /sys/kernel/slab/proc_inode_cache
-154 in /sys/kernel/slab/filp
+161 in /sys/kernel/slab/filp
203 in /sys/kernel/slab/anon_vma
265 in /sys/kernel/slab/shmem_inode_cache
334 in /sys/kernel/slab/kmalloc-96
400 in /sys/kernel/slab/kmalloc-32
-460 in /sys/kernel/slab/vm_area_struct
-503 in /sys/kernel/slab/radix_tree_node
+453 in /sys/kernel/slab/vm_area_struct
513 in /sys/kernel/slab/kmalloc-8192
-515 in /sys/kernel/slab/skbuff_head_cache
+513 in /sys/kernel/slab/skbuff_head_cache
+517 in /sys/kernel/slab/radix_tree_node
546 in /sys/kernel/slab/inode_cache
767 in /sys/kernel/slab/kmalloc-16
-795 in /sys/kernel/slab/ext4_inode_cache
+825 in /sys/kernel/slab/ext4_inode_cache
1019 in /sys/kernel/slab/kmalloc-8
-2088 in /sys/kernel/slab/buffer_head
-2916 in /sys/kernel/slab/dentry
+2225 in /sys/kernel/slab/buffer_head
+2967 in /sys/kernel/slab/dentry
7088 in /sys/kernel/slab/sysfs_dir_cache
-56194 in /sys/kernel/slab/kmalloc-64
-75769 in /sys/kernel/slab/kmemleak_object
+113649 in /sys/kernel/slab/kmalloc-64
+133459 in /sys/kernel/slab/kmemleak_object

2009-11-12 19:31:43

by Johannes Berg

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, 2009-11-12 at 20:18 +0100, Matteo Croce wrote:

> # echo scan >/sys/kernel/debug/kmemleak ; cat
> /sys/kernel/debug/kmemleak
> kmemleak: 197 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
> unreferenced object 0xc5cfea80 (size 192):
> comm "softirq", pid 0, jiffies 14191
> backtrace:
> [<ffffffff>] 0xffffffff

that's kinda useless, can you run

for slab in /sys/kernel/slab/* ; do echo $(cat $slab/objects) in $slab ; done|sort -n

and tell us which one increases most?

johannes

Attachments:

signature.asc (801.00 B)
This is a digitally signed message part

2009-11-13 08:55:34

by Lorenzo Bianconi

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

2009/11/13 Johannes Berg <[email protected]>:
> On Thu, 2009-11-12 at 23:18 +0100, Matteo Croce wrote:
>
>> kmalloc-64 is definitely getting fat
>
> Is it the same with ath5k?
>
> I don't see any allocations like that in mac80211.
>
> johannes
>

Yes, I tested ath5k/mac80211 and ath9k/mac80211 and both show the same problem
whereas madwifi/net80211, tested with the same module, has not memory leak.

Lorenzo

2009-11-12 19:36:15

by Luis R. Rodriguez

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, Nov 12, 2009 at 11:35 AM, Luis R. Rodriguez
<[email protected]> wrote:
> On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
> <[email protected]> wrote:
>> On Thu, 2009-11-12 at 20:18 +0100, Matteo Croce wrote:
>>
>>> # echo scan >/sys/kernel/debug/kmemleak ; cat
>>> /sys/kernel/debug/kmemleak
>>> kmemleak: 197 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>>> unreferenced object 0xc5cfea80 (size 192):
>>> comm "softirq", pid 0, jiffies 14191
>>> backtrace:
>>> [<ffffffff>] 0xffffffff
>>
>> that's kinda useless, can you run
>
> But if you insist on using kmemleak, try clearing the list
>
> echo clear > kmemleak
>
> Then scan
>
> echo scan > kmemleak
>
> then run your frame injection tests and then re-run scan.
>
> echo scan > kmemleak
>
> Then paste the output here.

You need a kernel with debugging too to get a good valuable trace.

Luis

2009-11-12 22:28:28

by Luis R. Rodriguez

[permalink] [raw]

Subject: Re: [ath9k-devel] Possible memory leak in ath9k monitor mode injection

On Thu, Nov 12, 2009 at 02:16:09PM -0800, Matteo Croce wrote:
> On Thu, Nov 12, 2009 at 8:35 PM, Luis R. Rodriguez
> <[email protected]> wrote:
> > On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
> > <[email protected]> wrote:
> >> On Thu, 2009-11-12 at 20:18 +0100, Matteo Croce wrote:
> >>
> >>> # echo scan >/sys/kernel/debug/kmemleak ; cat
> >>> /sys/kernel/debug/kmemleak
> >>> kmemleak: 197 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
> >>> unreferenced object 0xc5cfea80 (size 192):
> >>> comm "softirq", pid 0, jiffies 14191
> >>> backtrace:
> >>> [<ffffffff>] 0xffffffff
> >>
> >> that's kinda useless, can you run
> >
> > But if you insist on using kmemleak, try clearing the list
> >
> > echo clear > kmemleak
> >
> > Then scan
> >
> > echo scan > kmemleak
> >
> > then run your frame injection tests and then re-run scan.
> >
> > echo scan > kmemleak
> >
> > Then paste the output here.
> >
> > Luis
> >
>
> root@alix:/sys/kernel/debug# rmmod inject
> inject_exit Inject, exiting module
> root@alix:/sys/kernel/debug# echo clear > kmemleak

I forgot you're on 2.6.31, clear stuff was added to kmemleak for 2.6.32.

> root@alix:/sys/kernel/debug# echo scan >kmemleak
> kmemleak: 61037 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
> root@alix:/sys/kernel/debug# modprobe inject
> inject_init Inject, inserting module
> inject_init Inject, initializing the timer
> root@alix:/sys/kernel/debug# echo scan >kmemleak
> root@alix:/sys/kernel/debug# cat kmemleak
> unreferenced object 0xccd48e70 (size 64):

What's 0xccd48e70 and friends? Can you enable debugging on your kernel?

Luis