2013-04-03 23:17:56

by Ben Greear

[permalink] [raw]
Subject: sta_info_flush_defer: Splat in 3.9.0-rc5+

I'm getting started on testing 3.9.0-rc5+ a bit more seriously. This is on
a tree with some additional patches:

http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary


The splat below comes from this. I see lots of these on both station and AP system when
bouncing 50 or so stations.

int sta_info_flush_defer(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_local *local = sdata->local;
struct sta_info *sta, *tmp;
int ret = 0;

might_sleep();

mutex_lock(&local->sta_mtx);
list_for_each_entry_safe(sta, tmp, &local->sta_list, list) {
if (sdata == sta->sdata) {
WARN_ON(__sta_info_destroy(sta));
ret++;
}
}
mutex_unlock(&local->sta_mtx);

return ret;
}



[ 549.134242] ------------[ cut here ]------------
[ 549.134291] WARNING: at /home/greearb/git/linux-3.9.dev.y/net/mac80211/sta_info.c:986 sta_info_flush_defer+0x86/0x90 [mac80211]()
[ 549.134294] Hardware name: To Be Filled By O.E.M.
[ 549.134368] Modules linked in: iptable_raw xt_CT bridge nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_gre gre 8021q mrp garp stp llc
macvlan wanlink(O) pktgen fuse nfsv3 nfs_acl nfsv4 auth_rpcgss nfs fscache lockd sunrpc binfmt_misc uinput arc4 coretemp iTCO_wdt iTCO_vendor_support gpio_ich
snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq ath9k snd_seq_device cdc_acm mac80211 snd_pcm microcode ath9k_common ath9k_hw ath lpc_ich
snd_timer pcspkr cfg80211 i2c_i801 serio_raw snd r8169 soundcore rfkill snd_page_alloc mii i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded:
iptable_nat]
[ 549.134374] Pid: 4822, comm: hostapd Tainted: G WC O 3.9.0-rc5+ #3
[ 549.134376] Call Trace:
[ 549.134392] [<c0444f6d>] warn_slowpath_common+0x6d/0xa0
[ 549.134420] [<f8b8f236>] ? sta_info_flush_defer+0x86/0x90 [mac80211]
[ 549.134448] [<f8b8f236>] ? sta_info_flush_defer+0x86/0x90 [mac80211]
[ 549.134455] [<c0444fbd>] warn_slowpath_null+0x1d/0x20
[ 549.134482] [<f8b8f236>] sta_info_flush_defer+0x86/0x90 [mac80211]
[ 549.134514] [<f8b9eac7>] ieee80211_del_station+0x27/0x40 [mac80211]
[ 549.134545] [<f8b9eaa0>] ? ieee80211_send_layer2_update+0xc0/0xc0 [mac80211]
[ 549.134569] [<f8a89ce0>] nl80211_del_station+0x70/0x80 [cfg80211]
[ 549.134579] [<c0877df6>] genl_rcv_msg+0x236/0x290
[ 549.134594] [<c08492e6>] ? __alloc_skb+0x66/0x170
[ 549.134600] [<c0877bc0>] ? genl_rcv+0x20/0x20
[ 549.134605] [<c0876996>] netlink_rcv_skb+0x86/0xb0
[ 549.134611] [<c0877bb7>] genl_rcv+0x17/0x20
[ 549.134616] [<c08766df>] netlink_unicast+0x16f/0x1f0
[ 549.134622] [<c087735c>] netlink_sendmsg+0x1fc/0x300
[ 549.134630] [<c0842005>] sock_sendmsg+0xb5/0xf0
[ 549.134639] [<c08403a8>] ? copy_from_user+0x8/0x10
[ 549.134645] [<c084bd83>] ? verify_iovec+0x53/0xb0
[ 549.134652] [<c0842e05>] __sys_sendmsg+0x2c5/0x2e0
[ 549.134659] [<c0865b59>] ? dev_ioctl+0x99/0x690
[ 549.134666] [<c084862b>] ? skb_dequeue+0x4b/0x70
[ 549.134672] [<c083ffd3>] ? sock_destroy_inode+0x23/0x30
[ 549.134678] [<c083ffd3>] ? sock_destroy_inode+0x23/0x30
[ 549.134685] [<c052d97c>] ? destroy_inode+0x2c/0x50
[ 549.134691] [<c052da8a>] ? evict+0xea/0x180
[ 549.134697] [<c052dbef>] ? iput+0xcf/0x160
[ 549.134702] [<c052a6e9>] ? __d_free+0x29/0x40
[ 549.134709] [<c0842f86>] sys_sendmsg+0x36/0x60
[ 549.134716] [<c0843297>] sys_socketcall+0x107/0x2d0
[ 549.134723] [<c0519588>] ? ____fput+0x8/0x10
[ 549.134731] [<c094184d>] sysenter_do_call+0x12/0x28
[ 549.134735] ---[ end trace 7aa6620d94bfffc5 ]---
[ 549.138470] ------------[ cut here ]------------

--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com



2013-04-03 23:41:34

by Johannes Berg

[permalink] [raw]
Subject: Re: sta_info_flush_defer: Splat in 3.9.0-rc5+

On Wed, 2013-04-03 at 16:17 -0700, Ben Greear wrote:
> I'm getting started on testing 3.9.0-rc5+ a bit more seriously. This is on
> a tree with some additional patches:
>
> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary
>
>
> The splat below comes from this. I see lots of these on both station and AP system when
> bouncing 50 or so stations.

I might be interested if you can reproduce without your hashing patches,
but with those I suspect you just return an error there that shouldn't
be returned.

johannes


2013-04-04 00:10:13

by Ben Greear

[permalink] [raw]
Subject: Re: sta_info_flush_defer: Splat in 3.9.0-rc5+

On 04/03/2013 04:41 PM, Johannes Berg wrote:
> On Wed, 2013-04-03 at 16:17 -0700, Ben Greear wrote:
>> I'm getting started on testing 3.9.0-rc5+ a bit more seriously. This is on
>> a tree with some additional patches:
>>
>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary
>>
>>
>> The splat below comes from this. I see lots of these on both station and AP system when
>> bouncing 50 or so stations.
>
> I might be interested if you can reproduce without your hashing patches,
> but with those I suspect you just return an error there that shouldn't
> be returned.

Ahh, yes...I was returning false errors from the sta_info_hash_del.
I just need to ignore vhash remove errors because the vhash is only
populated for station vifs.

Seems to be working better now.

Thanks for the suggestion!

Thanks,
Ben

--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com