Possible memory leak in ath9k monitor mode injection

Possible memory leak in ath9k monitor mode injection

[Lorenzo Bianconi]

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);

Re: Possible memory leak in ath9k monitor mode injection

[Matteo Croce]

On Thu, Nov 12, 2009 at 12:31 PM, Lorenzo Bianconi
<lorenzo.bianconi83@gmail.com> 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

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

[Luis R. Rodriguez]

On Thu, Nov 12, 2009 at 06:18:46AM -0800, Matteo Croce wrote:
> On Thu, Nov 12, 2009 at 12:31 PM, Lorenzo Bianconi
> <lorenzo.bianconi83@gmail.com> 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

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

[Luis R. Rodriguez]

On Thu, Nov 12, 2009 at 7:44 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> 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
>> <lorenzo.bianconi83@gmail.com> 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

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

[Matteo Croce]

On Thu, Nov 12, 2009 at 4:49 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Thu, Nov 12, 2009 at 7:44 AM, Luis R. Rodriguez
> <lrodriguez@atheros.com> 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
>>> <lorenzo.bianconi83@gmail.com> 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

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Luis R. Rodriguez]

On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
<johannes@sipsolutions.net> 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

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

[Luis R. Rodriguez]

On Thu, Nov 12, 2009 at 11:35 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
> <johannes@sipsolutions.net> 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

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

[Matteo Croce]

On Thu, Nov 12, 2009 at 8:31 PM, Johannes Berg
<johannes@sipsolutions.net> 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
>

# diff -u leak.1 leak.2
--- leak.1      2000-01-01 01:19:56.817434067 +0100
+++ leak.2      2000-01-01 01:20:45.447434308 +0100
@@ -77,10 +77,10 @@
 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
@@ -90,21 +90,21 @@
 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
+157 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
+467 in /sys/kernel/slab/vm_area_struct
+507 in /sys/kernel/slab/radix_tree_node
 513 in /sys/kernel/slab/kmalloc-8192
 515 in /sys/kernel/slab/skbuff_head_cache
 546 in /sys/kernel/slab/inode_cache
 767 in /sys/kernel/slab/kmalloc-16
 795 in /sys/kernel/slab/ext4_inode_cache
 1019 in /sys/kernel/slab/kmalloc-8
-2088 in /sys/kernel/slab/buffer_head
+2135 in /sys/kernel/slab/buffer_head
 2916 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
+61054 in /sys/kernel/slab/kmalloc-64
+80680 in /sys/kernel/slab/kmemleak_object

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

[Matteo Croce]

On Thu, Nov 12, 2009 at 8:35 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
> <johannes@sipsolutions.net> 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

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

[Matteo Croce]

On Thu, Nov 12, 2009 at 8:31 PM, Johannes Berg
<johannes@sipsolutions.net> 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

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

[Luis R. Rodriguez]

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
> <lrodriguez@atheros.com> wrote:
> > On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
> > <johannes@sipsolutions.net> 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

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

[Matteo Croce]

On Thu, Nov 12, 2009 at 11:28 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> 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
>> <lrodriguez@atheros.com> wrote:
>> > On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
>> > <johannes@sipsolutions.net> 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)

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

[Lorenzo Bianconi]

> 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

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

[Matteo Croce]

On Thu, Nov 12, 2009 at 11:28 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> 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
>> <lrodriguez@atheros.com> wrote:
>> > On Thu, Nov 12, 2009 at 11:31 AM, Johannes Berg
>> > <johannes@sipsolutions.net> 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.

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 194 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Lorenzo Bianconi]

2009/11/13 Johannes Berg <johannes@sipsolutions.net>:
> 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

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

[Matteo Croce]

On Fri, Nov 13, 2009 at 12:27 PM,  <Lorenzo.Bianconi83@gmail.com> wrote:
> Il giorno , Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> ha scritto:
>> 2009/11/13 Johannes Berg johannes@sipsolutions.net>:
>> 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

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

[Matteo Croce]

On Fri, Nov 13, 2009 at 12:27 PM,  <Lorenzo.Bianconi83@gmail.com> wrote:
> Il giorno , Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> ha scritto:
>> 2009/11/13 Johannes Berg johannes@sipsolutions.net>:
>> 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);
> }

What about adding that line in ieee80211_tx_status() instead of
ath_tx_complete()?
That will hopefully fix other drivers too.
I haven't a broadcom card to test b43 with

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

On Fri, 2009-11-13 at 15:42 +0100, Matteo Croce wrote:

> > - 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);
> > }
> 
> What about adding that line in ieee80211_tx_status() instead of
> ath_tx_complete()?
> That will hopefully fix other drivers too.

Umm, no, this is an atheros-ism that ought to be removed anyway, but
it's not possible this particular problem affects other drivers.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Luis R. Rodriguez]

On Fri, Nov 13, 2009 at 4:20 AM, Matteo Croce <technoboy85@gmail.com> wrote:
> On Fri, Nov 13, 2009 at 12:27 PM,  <Lorenzo.Bianconi83@gmail.com> wrote:
>> Il giorno , Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> ha scritto:
>>> 2009/11/13 Johannes Berg johannes@sipsolutions.net>:
>>> 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

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

[Matteo Croce]

On Sat, Nov 14, 2009 at 3:13 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Nov 13, 2009 at 4:20 AM, Matteo Croce <technoboy85@gmail.com> wrote:
>> On Fri, Nov 13, 2009 at 12:27 PM,  <Lorenzo.Bianconi83@gmail.com> wrote:
>>> Il giorno , Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> ha scritto:
>>>> 2009/11/13 Johannes Berg johannes@sipsolutions.net>:
>>>> 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