Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1682 (closed defect: fixed)

Opened 12 years ago

Last modified 11 years ago

VAP Memory leak on ifconfig up/down

Reported by: fermin.hdez@gmail.com Assigned to: mtaylor
Priority: major Milestone: version 0.9.5
Component: madwifi: driver Version: v0.9.3.3
Keywords: Cc:
Patch is attached: 0 Pending:

Description

Hi,

I have madwifi(9.3.3) in device with openWrt (2.6.24), and when i ifconfig up and down several time's the device crash.

ifconfig take all memory, i test it with shell script and with C program, and i think it occurs for the madwifi driver.

Any one can tell me something to fix it ?

A lot of thx.

PD: sorry for my poor english.

Change History

12/03/07 20:55:31 changed by mentor

Can you reproduce with trunk?

(in reply to: ↑ description ) 12/09/07 01:40:45 changed by gortiz@neomedia.es

I have openwrt trunk r9666, and trunk of madwifi is: madwifi-dfs-r2996 and the same problem, with this simple script:

while [ 1 == 1 ] ; do

ifconfig ath0 down; ifconfig ath0 up;

done

in few minuts the system produces an oom (out of memory), viewing the memory with top -d 1, I see that memory is reducing 4k for each iteration in the script.

wifi0 is configured in sta mode

ifconfig wifi0 down; ifconfig wifi0 up, no problem exists.

12/09/07 03:04:44 changed by mentor

  • summary changed from When i ifconfig down and ifconfig up many times, crash to VAP Memory leak on ifconfig up/down.

12/10/07 11:59:36 changed by gortiz@neomedia.es

The problem is allocated in net/ieee80211_proto.c, when ifconfig down is executed, is generated a new state in the state machine throw the ieee80211_stop function:

ieee80211_stop(struct net_device *dev) {

struct ieee80211vap *vap = dev->priv; struct ieee80211com *ic = vap->iv_ic; struct net_device *parent = ic->ic_dev;

IEEE80211_DPRINTF(vap,

IEEE80211_MSG_STATE | IEEE80211_MSG_DEBUG, "%s\n", "stop running");

ieee80211_new_state(vap, IEEE80211_S_INIT, -1); <------

. . .

the new state is executed in ieee80211_newstate

ieee80211_newstate(struct ieee80211vap *vap, enum ieee80211_state nstate, int {

struct ieee80211com *ic = vap->iv_ic; struct ieee80211_node *ni; enum ieee80211_state ostate;

ostate = vap->iv_state; IEEE80211_DPRINTF(vap, IEEE80211_MSG_STATE, "%s: %s -> %s\n", func,

ieee80211_state_name[ostate], ieee80211_state_name[nstate]);

vap->iv_state = nstate; /* state transition */ del_timer(&vap->iv_mgtsend); if (vap->iv_opmode != IEEE80211_M_HOSTAP && ostate != IEEE80211_S_SCAN)

ieee80211_cancel_scan(vap); /* background scan */

ni = vap->iv_bss; /* NB: no reference held */ switch (nstate) { case IEEE80211_S_INIT:

switch (ostate) { case IEEE80211_S_INIT:

break;

case IEEE80211_S_RUN:

switch (vap->iv_opmode) { case IEEE80211_M_STA:

IEEE80211_SEND_MGMT(ni,

IEEE80211_FC0_SUBTYPE_DISASSOC, IEEE80211_REASON_ASSOC_LEAVE);

ieee80211_sta_leave(ni); break;

case IEEE80211_M_HOSTAP:

ieee80211_iterate_nodes(&ic->ic_sta,

sta_disassoc, vap);

break;

default:

break;

} goto reset; <------- here is the problem

. . . .

reset:

ieee80211_reset_bss(vap); break;

the function ieee80211_reset_bss(vap)

void ieee80211_reset_bss(struct ieee80211vap *vap) {

struct ieee80211com *ic = vap->iv_ic; struct ieee80211_node *ni = NULL; struct ieee80211_node *obss = vap->iv_bss;

/* Recreate the node table */ ieee80211_node_table_reset(&ic->ic_sta, vap); /* XXX multi-bss wrong */ ieee80211_reset_erp(ic, ic->ic_curmode);

ni = ieee80211_alloc_node_table(vap, vap->iv_myaddr); <------- executes an kmalloc in ath/if_ath.c without freeing memory.

#ifdef IEEE80211_DEBUG_REFCNT ath_node_alloc_debug(struct ieee80211vap *vap, const char* func, int line) #else ath_node_alloc(struct ieee80211vap *vap) #endif {

struct ath_softc *sc = vap->iv_ic->ic_dev->priv; const size_t space = sizeof(struct ath_node) + sc->sc_rc->arc_space; struct ath_node *an = kmalloc(space, GFP_ATOMIC); <----- here!!

thus freeing this memory allocation before executing kmalloc would be the solution.

A partial solution is //goto reset; (reset is not executed), but I don't know the effects if reset_bss is not executed, but commenting this, ifconfig down;ifconfig up, not produces any memory leak in the system.

12/10/07 21:08:46 changed by mentor

The memory of which you speak should be freed when its reference count goes to zero; the fact that it isn't indicates that a reference is being lost somewhere...

01/09/08 09:17:00 changed by jussi.haakana@gmail.com

Hi,

Is anyone currently working with this problem? I have a somewhat similar case, when I continuously change the WLAN mode by destroying and re-creating the VAP:

while true do

wlanconfig destroy wlanconfig ath0 create wlandev wifi0 wlanmode sta wlanconfig destroy wlanconfig ath0 create wlandev wifi0 wlanmode monitor

done

When running this script, the system (linux 2.6.20 PPC) runs out of memory in couple of minutes.

01/25/08 23:54:36 changed by matt.feifarek@gmail.com

I have a similar problem. I get a leak running 3223, though I'm not doing anything up/down related. I'm just running it.

I'm running in Master mode, sortof emulating an AP via firewalling and nat. I don't think I'm doing anything special with the network interface itself. I am running on x86_64.

I also don't have much traffic on my wifi lately, so it takes a 4-5 days to eat up a gig of ram.

If I can help diagnose, I'd be glad to. Thanks!

01/29/08 08:16:42 changed by mtaylor

  • status changed from new to assigned.
  • owner set to mtaylor.

I have committed three patches for memory leaks r3299, r3300, and r3301. I believe the ifconfig athX down/up test is fixed. There was an extra reference being added to the vap->iv_bss node, causing it's loss on the next up when it was replaced. This would affect each VAP that was brought down and up again, every time. I also fixed some code paths that could leak node refs. The current code is looking cleaner and cleaner with respect to node references. I'm going to be putting the trunk revision up for overnight if down/up tests and then bandwidth tests over multiple wireless bridges tomorrow.

Please verify that these patches fix the issue so we can close the ticket. Thanks.

(follow-up: ↓ 10 ) 01/29/08 17:28:53 changed by matt.feifarek@gmail.comc

I svn up'd and built/installed this morning. It was at r3304

When I restarted the system, it OOPs'd my kernel. It never got past modprobe.

Afraid I don't have any useful codes for you; I don't know how to get the dump when I can't boot it reliably.

(in reply to: ↑ 9 ) 01/29/08 18:22:29 changed by mrenzmann

Replying to matt.feifarek@gmail.comc:

Afraid I don't have any useful codes for you; I don't know how to get the dump when I can't boot it reliably.

DevDocs/KernelOops gives some hints for such situations (such as getting oops dumps via serial port).

01/29/08 18:49:24 changed by mentor

Sorry, try r3305

02/07/08 05:29:30 changed by mtaylor

  • status changed from assigned to closed.
  • resolution set to fixed.

Fixed in trunk.

02/07/08 06:12:23 changed by mrenzmann

  • milestone set to version 0.9.5.