* [PATCH] ath9k: remove unused function ath9k_hw_keyisvalid
From: John W. Linville @ 2010-06-29 19:38 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, ath9k-devel, John W. Linville
In-Reply-To: <1266572413.3991.55.camel@jlt3.sipsolutions.net>
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 11 -----------
drivers/net/wireless/ath/ath9k/hw.h | 1 -
2 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 1ed1440..9d22444 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1737,17 +1737,6 @@ bool ath9k_hw_set_keycache_entry(struct ath_hw *ah, u16 entry,
}
EXPORT_SYMBOL(ath9k_hw_set_keycache_entry);
-bool ath9k_hw_keyisvalid(struct ath_hw *ah, u16 entry)
-{
- if (entry < ah->caps.keycache_size) {
- u32 val = REG_READ(ah, AR_KEYTABLE_MAC1(entry));
- if (val & AR_KEYTABLE_VALID)
- return true;
- }
- return false;
-}
-EXPORT_SYMBOL(ath9k_hw_keyisvalid);
-
/******************************/
/* Power Management (Chipset) */
/******************************/
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index e9578a4..f0e0cc9 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -863,7 +863,6 @@ bool ath9k_hw_keysetmac(struct ath_hw *ah, u16 entry, const u8 *mac);
bool ath9k_hw_set_keycache_entry(struct ath_hw *ah, u16 entry,
const struct ath9k_keyval *k,
const u8 *mac);
-bool ath9k_hw_keyisvalid(struct ath_hw *ah, u16 entry);
/* GPIO / RFKILL / Antennae */
void ath9k_hw_cfg_gpio_input(struct ath_hw *ah, u32 gpio);
--
1.7.0.1
^ permalink raw reply related
* [PATCH] ath9k: make ath9k_hw_keysetmac static
From: John W. Linville @ 2010-06-29 19:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, ath9k-devel, John W. Linville
In-Reply-To: <1266572413.3991.55.camel@jlt3.sipsolutions.net>
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 3 +--
drivers/net/wireless/ath/ath9k/hw.h | 1 -
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 9d22444..6e87af4 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1498,7 +1498,7 @@ bool ath9k_hw_keyreset(struct ath_hw *ah, u16 entry)
}
EXPORT_SYMBOL(ath9k_hw_keyreset);
-bool ath9k_hw_keysetmac(struct ath_hw *ah, u16 entry, const u8 *mac)
+static bool ath9k_hw_keysetmac(struct ath_hw *ah, u16 entry, const u8 *mac)
{
u32 macHi, macLo;
u32 unicast_flag = AR_KEYTABLE_VALID;
@@ -1536,7 +1536,6 @@ bool ath9k_hw_keysetmac(struct ath_hw *ah, u16 entry, const u8 *mac)
return true;
}
-EXPORT_SYMBOL(ath9k_hw_keysetmac);
bool ath9k_hw_set_keycache_entry(struct ath_hw *ah, u16 entry,
const struct ath9k_keyval *k,
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index f0e0cc9..bb99e2e 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -859,7 +859,6 @@ u32 ath9k_regd_get_ctl(struct ath_regulatory *reg, struct ath9k_channel *chan);
/* Key Cache Management */
bool ath9k_hw_keyreset(struct ath_hw *ah, u16 entry);
-bool ath9k_hw_keysetmac(struct ath_hw *ah, u16 entry, const u8 *mac);
bool ath9k_hw_set_keycache_entry(struct ath_hw *ah, u16 entry,
const struct ath9k_keyval *k,
const u8 *mac);
--
1.7.0.1
^ permalink raw reply related
* [PATCH] iwlwifi: do not export iwl_leds_background
From: John W. Linville @ 2010-06-29 19:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Reinette Chatre, John W. Linville
In-Reply-To: <1266572413.3991.55.camel@jlt3.sipsolutions.net>
It is only used from within the iwlcore module.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/iwlwifi/iwl-led.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-led.c b/drivers/net/wireless/iwlwifi/iwl-led.c
index db5bfcb..486244b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-led.c
+++ b/drivers/net/wireless/iwlwifi/iwl-led.c
@@ -214,7 +214,6 @@ void iwl_leds_background(struct iwl_priv *priv)
priv->last_blink_time = jiffies;
priv->last_blink_rate = blink_idx;
}
-EXPORT_SYMBOL(iwl_leds_background);
void iwl_leds_init(struct iwl_priv *priv)
{
--
1.7.0.1
^ permalink raw reply related
* [PATCH] mac80211: remove unnecessary check in ieee80211_dump_survey
From: John W. Linville @ 2010-06-29 19:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Holger Schurig, Johannes Berg, John W. Linville
In-Reply-To: <1274906612.3658.58.camel@jlt3.sipsolutions.net>
This check is duplicated in drv_get_survey.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/mac80211/cfg.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index f4efbfa..e55970b 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -413,9 +413,6 @@ static int ieee80211_dump_survey(struct wiphy *wiphy, struct net_device *dev,
{
struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
- if (!local->ops->get_survey)
- return -EOPNOTSUPP;
-
return drv_get_survey(local, idx, survey);
}
--
1.7.0.1
^ permalink raw reply related
* [PATCH] mac80211: add basic tracing to drv_get_survey
From: John W. Linville @ 2010-06-29 19:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Holger Schurig, Johannes Berg, John W. Linville
In-Reply-To: <1274906612.3658.58.camel@jlt3.sipsolutions.net>
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/mac80211/driver-ops.h | 7 ++++++-
net/mac80211/driver-trace.h | 22 ++++++++++++++++++++++
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index c333173..14123dc 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -375,9 +375,14 @@ static inline int drv_get_survey(struct ieee80211_local *local, int idx,
struct survey_info *survey)
{
int ret = -EOPNOTSUPP;
+
+ trace_drv_get_survey(local, idx, survey);
+
if (local->ops->get_survey)
ret = local->ops->get_survey(&local->hw, idx, survey);
- /* trace_drv_get_survey(local, idx, survey, ret); */
+
+ trace_drv_return_int(local, ret);
+
return ret;
}
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 8da31ca..5d5d2a9 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -761,6 +761,28 @@ TRACE_EVENT(drv_ampdu_action,
)
);
+TRACE_EVENT(drv_get_survey,
+ TP_PROTO(struct ieee80211_local *local, int idx,
+ struct survey_info *survey),
+
+ TP_ARGS(local, idx, survey),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ __field(int, idx)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ __entry->idx = idx;
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT " idx:%d",
+ LOCAL_PR_ARG, __entry->idx
+ )
+);
+
TRACE_EVENT(drv_flush,
TP_PROTO(struct ieee80211_local *local, bool drop),
--
1.7.0.1
^ permalink raw reply related
* Compat-wireless release for 2010-06-29 is baked
From: Compat-wireless cronjob account @ 2010-06-29 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat
a78b3af..464e8d5 linux-2.6.35.y -> origin/linux-2.6.35.y
126c387..776ba1d master -> origin/master
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
b698fdf..4570588 history -> origin/history
+ 6dc1a02...1b72384 master -> origin/master (forced update)
b4322e7..5904b3b stable -> origin/stable
* [new tag] next-20100629 -> next-20100629
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
494378 - Total upstream lines of code being pulled
^ permalink raw reply
* Re: [PATCH] mac80211: auth retries if AP sends temporary deauth
From: John W. Linville @ 2010-06-29 17:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: Paul Stewart, linux-wireless
In-Reply-To: <1277624955.3684.0.camel@jlt3.sipsolutions.net>
On Sun, Jun 27, 2010 at 09:49:15AM +0200, Johannes Berg wrote:
> On Fri, 2010-06-25 at 00:33 -0700, Paul Stewart wrote:
>
> > If a STA gets sent a DEAUTH from an AP it is actively trying to
> > authenticate to, mac80211 currently shoots itself in the foot by
> > letting ieee80211_sta_rx_mgmt() clean up state for the connection
> > (removing an entry from authtry_bsses[] in wireless/mlme.c),
> > but the retry loop contiinues, leading to a kernel warning but no
> > connection.
> >
> > An AP is allowed by the spec to return DEAUTH as a result of a
> > temporary failure, one of which is "you are already authenticated
> > -- what are you talking about?"
>
> Do you know the reason code for that? I think the check here should be
> more fine-grained.
If/when you repost, please be sure to use the proper/expected format:
http://linux.yyz.us/patch-format.html
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Björn Smedman @ 2010-06-29 17:32 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <4C2A24D2.4070007@openwrt.org>
2010/6/29 Felix Fietkau <nbd@openwrt.org>:
> Please add another print to the end of ath9k_hw_check_alive() before the
> 'return false'. Make sure it prints the value of the 'reg' variable.
> If you see it in the log, then it's probably the baseband getting stuck.
Yes, hw reset is due to reg = 0x01702400 every 4 - 40 seconds or so:
...
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: slot 0 [tsf 4495367
tsftu 4390 intval 100] vif 80944e70
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: slot 3 [tsf 4520967
tsftu 4415 intval 100] vif (null)
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: slot 2 [tsf 4546567
tsftu 4440 intval 100] vif (null)
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: ath9k_hw_check_alive:
reg = 0x01702400
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: Reset due to hw dead
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: Reset HW!
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: ah->misc_mode 0xc
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: Setting CFG 0x10a
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: slot 0 [tsf 79211
tsftu 77 intval 100] vif 80944e70
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: resume beacon xmit
after 1 misses
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: slot 3 [tsf 117796
tsftu 115 intval 100] vif (null)
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: slot 2 [tsf 143366
tsftu 140 intval 100] vif (null)
Jan 1 00:03:21 OpenWrt user.debug kernel: ath: slot 1 [tsf 168967
tsftu 165 intval 100] vif (null)
...
> - Felix
/Björn
^ permalink raw reply
* Re: rt61pci AP performance issues
From: David Ellingsworth @ 2010-06-29 16:55 UTC (permalink / raw)
To: rt2x00 Users List, wireless
In-Reply-To: <AANLkTimZTGvPuWPTXSOfOjvxzQh5tSnlqNBpueASLAUF@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3496 bytes --]
On Fri, Jun 18, 2010 at 2:02 PM, David Ellingsworth
<david@identd.dyndns.org> wrote:
> I've been trying unsuccessfully for some time to use a rt61pci based
> wireless card as an Access Point for my network. With kernel version
> 2.6.32-4 (Debian version) the AP works but has intermittent problems.
> Notably, that version continuously prints the message
> "ieee80211_tx_status: headroom too small" to my system log and the
> driver simply stops working after a random amount of time. The first
> of these errors was fixed some time ago after I reported it, but the
> other still remains, even with the latest wireless-testing driver, and
> there's no indication as to the cause of the issue. With regards to
> this issue, it appears that performance steadily drops until it
> becomes unusable. With the latest wireless-testing driver I can
> reliably reproduce this issue by trying to transfer a large file from
> my server to a client. Any help diagnosing and correcting this issue
> would be greatly appreciated.
>
I have not received a response to this issue, so I'll try to clarify
it a bit. With the latest wireless-testing tree, clients are able to
associate to my rt61pci AP but the connection fails after about 10s or
less while transferring a file. Between v2.6.32 and the latest
wireless-testing tree, there have been many changes. These changes
introduced a lot of variability in the connection speed and stability.
All of this has made bisecting this issue very difficult..
Using v2.6.32 as a "good" point and ad57b053612 (the HEAD of
wireless-testing at the time) as a "bad" point, I began bisecting. I
then compiled and tested 15 different kernels. Some of them were
remarkably better and others were extremely worse. Upon completing,
git had identified a single commit as the cause. Unfortunately, the
commit it identified had nothing to do with the rt61pci driver or the
wireless networking stack. I therefore had done something wrong during
my testing.
Fortunately, all that work did not go to waste. During my testing, I
identified c91f48d61c as being remarkably better than both v2.6.32 and
the HEAD of the wireless testing branch. At that commit, the
performance is fast and stable and much closer to the HEAD of the
wireless-testing branch. Using it as the first good position, and
bisecting only 'net/mac80211/' and 'drivers/net/wireless/rt2x00/' I
was able to identify e46754f8c9333 as the first bad commit. This
commit was a merge of another branch and consists of about four other
commits, two which directly affect mac80211.
I haven't conducted any other tests beyond what was bisected in the
attached log. Performance across all those revisions remained somewhat
fast, and my markings were based solely on client link failure. Each
bad commit resulted in the link failing after about 10s while
transferring a file. At which point, the transfer would stop, the AP
would be unreachable via pings, but the client remained associated to
the AP. About 30s after that point, the client would timeout and
re-associate to the AP reactivating the link.
Given that I limited my bisection to only the above directories, the
cause could very well be in some other commit than the one identified.
Nonetheless, I hope this additional information helps identify the
cause so that it can be corrected. There's also the chance that even
if this is caused by a change in mac80211, the rt61pci driver may
still be at fault due to unexpected behavior.
Regards,
David Ellingsworthh
[-- Attachment #2: bisect.log --]
[-- Type: application/octet-stream, Size: 1905 bytes --]
# bad: [ad57b053612f4c17f98bcad81d35e5ff3e2cbbf5] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
# good: [c91f48d61c5b6fb36a6fc50de923db4db009b0dc] sfc: Survive ISR0=0 bug in the shared IRQ case
git bisect start 'HEAD' 'c91f48d61c5b6fb36a6fc50de923db4db009b0dc' 'net/mac80211/' 'drivers/net/wireless/rt2x00/'
# good: [058897a4e93a6fc6d331e2ef591b2d6571431265] mac80211: fix paged defragmentation
git bisect good 058897a4e93a6fc6d331e2ef591b2d6571431265
# bad: [a3f84ca4b8dc31d0034a8b23194a4470766c938c] rt2x00: Fix typo in rt2800_config_txpower
git bisect bad a3f84ca4b8dc31d0034a8b23194a4470766c938c
# skip: [06443e46c65915d74b03fe1de10c00748e4706ee] rt2x00: Fix HT40 operation in rt2800.
git bisect skip 06443e46c65915d74b03fe1de10c00748e4706ee
# bad: [3b51cc996e81d8a113416d8094fa4a88f8360a51] Merge branch 'master' into for-davem
git bisect bad 3b51cc996e81d8a113416d8094fa4a88f8360a51
# good: [4a35ecf8bf1c4b039503fa554100fe85c761de76] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
git bisect good 4a35ecf8bf1c4b039503fa554100fe85c761de76
# good: [4a1032faac94ebbf647460ae3e06fc21146eb280] Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
git bisect good 4a1032faac94ebbf647460ae3e06fc21146eb280
# good: [5c01d5669356e13f0fb468944c1dd4c6a7e978ad] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem
git bisect good 5c01d5669356e13f0fb468944c1dd4c6a7e978ad
# bad: [87eb367003887cdc81a5d183efea227b5b488961] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
git bisect bad 87eb367003887cdc81a5d183efea227b5b488961
# bad: [e46754f8c9333170f11780d8e3a70da1b1a88338] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
git bisect bad e46754f8c9333170f11780d8e3a70da1b1a88338
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Felix Fietkau @ 2010-06-29 16:52 UTC (permalink / raw)
To: Björn Smedman; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTik_d6tIKj3otsgaojVBPfvW1lz9OBRujeZLyv1U@mail.gmail.com>
On 2010-06-29 6:36 PM, Björn Smedman wrote:
> 2010/6/29 Felix Fietkau <nbd@openwrt.org>:
>> One beacon miss should never cause a TSF reset. Only a lot of
>> consecutive beacon misses trigger a hardware reset, which then resets
>> the TSF. Looking at your log, it appears that the beacon miss is a
>> symptom rather than a cause of the TSF jumps.
>> Can you add a debug statement to the hw reset function to see if it's
>> called before the TSF jumps?
>
> Yup, seems to be a hardware reset. Added an ath_print ("Reset HW!") at
> the beginning of ath9k_hw_reset() and used debug mask 0x101:
>
> ...
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 3 [tsf 14863367
> tsftu 14515 intval 100] vif (null)
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 2 [tsf 14888967
> tsftu 14540 intval 100] vif (null)
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 1 [tsf 14914568
> tsftu 14565 intval 100] vif (null)
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: Reset HW!
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: ah->misc_mode 0xc
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: Setting CFG 0x10a
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 0 [tsf 80123
> tsftu 78 intval 100] vif 80945e70
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: Reset HW!
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: ah->misc_mode 0xc
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: Setting CFG 0x10a
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 0 [tsf 80989
> tsftu 79 intval 100] vif 80945e70
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: resume beacon xmit
> after 1 misses
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 3 [tsf 117792
> tsftu 115 intval 100] vif (null)
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 2 [tsf 143368
> tsftu 140 intval 100] vif (null)
> Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 1 [tsf 168967
> tsftu 165 intval 100] vif (null)
> ...
Please add another print to the end of ath9k_hw_check_alive() before the
'return false'. Make sure it prints the value of the 'reg' variable.
If you see it in the log, then it's probably the baseband getting stuck.
- Felix
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Björn Smedman @ 2010-06-29 16:36 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <4C2A1776.2080508@openwrt.org>
2010/6/29 Felix Fietkau <nbd@openwrt.org>:
> One beacon miss should never cause a TSF reset. Only a lot of
> consecutive beacon misses trigger a hardware reset, which then resets
> the TSF. Looking at your log, it appears that the beacon miss is a
> symptom rather than a cause of the TSF jumps.
> Can you add a debug statement to the hw reset function to see if it's
> called before the TSF jumps?
Yup, seems to be a hardware reset. Added an ath_print ("Reset HW!") at
the beginning of ath9k_hw_reset() and used debug mask 0x101:
...
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 3 [tsf 14863367
tsftu 14515 intval 100] vif (null)
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 2 [tsf 14888967
tsftu 14540 intval 100] vif (null)
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 1 [tsf 14914568
tsftu 14565 intval 100] vif (null)
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: Reset HW!
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: ah->misc_mode 0xc
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: Setting CFG 0x10a
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 0 [tsf 80123
tsftu 78 intval 100] vif 80945e70
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: Reset HW!
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: ah->misc_mode 0xc
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: Setting CFG 0x10a
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 0 [tsf 80989
tsftu 79 intval 100] vif 80945e70
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: resume beacon xmit
after 1 misses
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 3 [tsf 117792
tsftu 115 intval 100] vif (null)
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 2 [tsf 143368
tsftu 140 intval 100] vif (null)
Jan 1 00:01:59 OpenWrt user.debug kernel: ath: slot 1 [tsf 168967
tsftu 165 intval 100] vif (null)
...
> - Felix
>
/Björn
^ permalink raw reply
* RE: [PATCH] compat: Fix panic caused by NULL pointer derefence in rtnl_fill_ifinfo
From: Rajkumar Manoharan @ 2010-06-29 16:26 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless@vger.kernel.org, linux-bluetooth@vger.kernel.org
>________________________________________
>From: Luis R. Rodriguez [mcgrof@gmail.com]
>Sent: Tuesday, June 29, 2010 8:51 PM
>To: Rajkumar Manoharan
>Cc: mcgrof@kernel.org; linux-wireless@vger.kernel.org; linux-bluetooth@vger.kernel.org
>Subject: Re: [PATCH] compat: Fix panic caused by NULL pointer derefence in rtnl_fill_ifinfo
>On Mon, Jun 28, 2010 at 11:38 PM, Rajkumar Manoharan
<rmanoharan@atheros.com> wrote:
> get stats netdev ops is blindy called for older kernels (< 2.6.29) and
> so assigning a NULL pointer from netdev_attach_ops causes a NULL pointer
> dereference.
>
> By default, netdev alloc provides an internal stats reference. So fill
> this only if ndo_get_stats is defined.
>
> Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
> ---
> compat/compat-2.6.29.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/compat/compat-2.6.29.c b/compat/compat-2.6.29.c
> index f94aed8..2e7e623 100644
> --- a/compat/compat-2.6.29.c
> +++ b/compat/compat-2.6.29.c
> @@ -35,7 +35,8 @@ void netdev_attach_ops(struct net_device *dev,
> dev->change_mtu = ops->ndo_change_mtu;
> dev->set_mac_address = ops->ndo_set_mac_address;
> dev->tx_timeout = ops->ndo_tx_timeout;
> - dev->get_stats = ops->ndo_get_stats;
> + if (ops->ndo_get_stats)
> + dev->get_stats = ops->ndo_get_stats;
>
> If ops->ndo_get_stats is NULL then dev->get_stats will be set to NULL.
> Do you know for sure this fixes something? If so can you explain how?
> I used to have a macro that checked for not NULL and if true set the
> callback but then later realized after Johannes poked me that this is
> silly given that if the op is NULL you are just setting it to NULL.
>
> I don't see the potential crash here.
>
> Luis
During alloc_netdev, get_stats is set to default callback (internal_stats).
It won't be NULL. Based on this assumption, get_stats is
invoked blindly in rtnl_fill_ifinfo without NULL check. So either
get_stats set with default callback or callback assigned by module.
It shouldn't be NULL.
Rajkumar
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Felix Fietkau @ 2010-06-29 15:55 UTC (permalink / raw)
To: Björn Smedman; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTint2L1xSMughBA5aHCFMRB5KMC8EfwcxJJU5XYW@mail.gmail.com>
On 2010-06-29 5:20 PM, Björn Smedman wrote:
> 2010/6/29 Felix Fietkau <nbd@openwrt.org>:
>> IMHO the most likely problem source is stuck beacons. Please compile the
>> driver with the debug option enabled and load it with
>> insmod ath9k debug=0x00000100
>
> It looks like it could be:
>
> ...
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 2 [tsf 1986567
> tsftu 1940 intval 100] vif (null)
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 1 [tsf 2012168
> tsftu 1965 intval 100] vif (null)
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 0 [tsf 2037767
> tsftu 1990 intval 100] vif 80945e70
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 0 [tsf 79033
> tsftu 77 intval 100] vif 80945e70
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: resume beacon xmit
> after 1 misses
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 3 [tsf 117790
> tsftu 115 intval 100] vif (null)
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 2 [tsf 143368
> tsftu 140 intval 100] vif (null)
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 1 [tsf 168967
> tsftu 165 intval 100] vif (null)
> ...
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 1 [tsf 14197768
> tsftu 13865 intval 100] vif (null)
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 14223368
> tsftu 13890 intval 100] vif 80945e70
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 3 [tsf 14248967
> tsftu 13915 intval 100] vif (null)
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 79180
> tsftu 77 intval 100] vif 80945e70
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: resume beacon xmit
> after 1 misses
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 3 [tsf 117791
> tsftu 115 intval 100] vif (null)
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 2 [tsf 143366
> tsftu 140 intval 100] vif (null)
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 1 [tsf 168967
> tsftu 165 intval 100] vif (null)
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 194567
> tsftu 190 intval 100] vif 80945e70
> ...
>
> What can cause a missed beacon? Are they just a "fact of life"?
>
> In any case I can't find any code that resets the tsf in this (single
> missed beacon) case. Will the hardware reset the tsf automatically
> whenever a single beacon is missed? Isn't that a bit overkill? Will it
> not cause problems for clients?
One beacon miss should never cause a TSF reset. Only a lot of
consecutive beacon misses trigger a hardware reset, which then resets
the TSF. Looking at your log, it appears that the beacon miss is a
symptom rather than a cause of the TSF jumps.
Can you add a debug statement to the hw reset function to see if it's
called before the TSF jumps?
- Felix
^ permalink raw reply
* Re: [PATCH] compat: Fix panic caused by NULL pointer derefence in rtnl_fill_ifinfo
From: Luis R. Rodriguez @ 2010-06-29 15:21 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: mcgrof, linux-wireless, linux-bluetooth
In-Reply-To: <1277793487-9071-1-git-send-email-rmanoharan@atheros.com>
On Mon, Jun 28, 2010 at 11:38 PM, Rajkumar Manoharan
<rmanoharan@atheros.com> wrote:
> get stats netdev ops is blindy called for older kernels (< 2.6.29) and
> so assigning a NULL pointer from netdev_attach_ops causes a NULL pointer
> dereference.
>
> By default, netdev alloc provides an internal stats reference. So fill
> this only if ndo_get_stats is defined.
>
> Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
> ---
> compat/compat-2.6.29.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/compat/compat-2.6.29.c b/compat/compat-2.6.29.c
> index f94aed8..2e7e623 100644
> --- a/compat/compat-2.6.29.c
> +++ b/compat/compat-2.6.29.c
> @@ -35,7 +35,8 @@ void netdev_attach_ops(struct net_device *dev,
> dev->change_mtu = ops->ndo_change_mtu;
> dev->set_mac_address = ops->ndo_set_mac_address;
> dev->tx_timeout = ops->ndo_tx_timeout;
> - dev->get_stats = ops->ndo_get_stats;
> + if (ops->ndo_get_stats)
> + dev->get_stats = ops->ndo_get_stats;
If ops->ndo_get_stats is NULL then dev->get_stats will be set to NULL.
Do you know for sure this fixes something? If so can you explain how?
I used to have a macro that checked for not NULL and if true set the
callback but then later realized after Johannes poked me that this is
silly given that if the op is NULL you are just setting it to NULL.
I don't see the potential crash here.
Luis
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Björn Smedman @ 2010-06-29 15:20 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <4C29284C.5050707@openwrt.org>
2010/6/29 Felix Fietkau <nbd@openwrt.org>:
> IMHO the most likely problem source is stuck beacons. Please compile the
> driver with the debug option enabled and load it with
> insmod ath9k debug=0x00000100
It looks like it could be:
...
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 2 [tsf 1986567
tsftu 1940 intval 100] vif (null)
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 1 [tsf 2012168
tsftu 1965 intval 100] vif (null)
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 0 [tsf 2037767
tsftu 1990 intval 100] vif 80945e70
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 0 [tsf 79033
tsftu 77 intval 100] vif 80945e70
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: resume beacon xmit
after 1 misses
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 3 [tsf 117790
tsftu 115 intval 100] vif (null)
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 2 [tsf 143368
tsftu 140 intval 100] vif (null)
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 1 [tsf 168967
tsftu 165 intval 100] vif (null)
...
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 1 [tsf 14197768
tsftu 13865 intval 100] vif (null)
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 14223368
tsftu 13890 intval 100] vif 80945e70
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 3 [tsf 14248967
tsftu 13915 intval 100] vif (null)
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 79180
tsftu 77 intval 100] vif 80945e70
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: resume beacon xmit
after 1 misses
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 3 [tsf 117791
tsftu 115 intval 100] vif (null)
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 2 [tsf 143366
tsftu 140 intval 100] vif (null)
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 1 [tsf 168967
tsftu 165 intval 100] vif (null)
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 194567
tsftu 190 intval 100] vif 80945e70
...
What can cause a missed beacon? Are they just a "fact of life"?
In any case I can't find any code that resets the tsf in this (single
missed beacon) case. Will the hardware reset the tsf automatically
whenever a single beacon is missed? Isn't that a bit overkill? Will it
not cause problems for clients?
> - Felix
/Björn
^ permalink raw reply
* Re: Compat-wireless release for 2010-06-26 is baked
From: Luis R. Rodriguez @ 2010-06-29 15:16 UTC (permalink / raw)
To: Andrei Emeltchenko
Cc: Compat-wireless cronjob account, linux-wireless, linux-bluetooth
In-Reply-To: <AANLkTilbJICU22JK-EMasnDWw-z-vWF3W72VnPtOY5Py@mail.gmail.com>
On Tue, Jun 29, 2010 at 5:31 AM, Andrei Emeltchenko
<andrei.emeltchenko.news@gmail.com> wrote:
> Hi,
>
> On Mon, Jun 28, 2010 at 7:38 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Mon, Jun 28, 2010 at 4:13 AM, Andrei Emeltchenko
>> <andrei.emeltchenko.news@gmail.com> wrote:
>>> Hi
>>>
>>> On Sat, Jun 26, 2010 at 10:02 PM, Compat-wireless cronjob account
>>> <compat@orbit-lab.org> wrote:
>>>
>>> Looks like the mail is sent to wrong ML?
>>
>> Its for BT too.
>
> I think those cron mails are not interesting to BT developers.
OK removed linux-bluetooth from the job.
Luis
^ permalink raw reply
* Re: [RFC 0/3] Update for some defects
From: John W. Linville @ 2010-06-29 13:48 UTC (permalink / raw)
To: Yuri Ershov; +Cc: johannes, ext-yuri.kululin, linux-wireless
In-Reply-To: <cover.1277808543.git.ext-yuri.ershov@nokia.com>
On Tue, Jun 29, 2010 at 03:08:05PM +0400, Yuri Ershov wrote:
> Yuri Ershov (3):
> mac80211: Put some code under MESH macro
> nl80211: Fix memory leaks
> cfg80211: Update of regulatory request initiator handling
These all seem fine to me.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Problem with firmware load on ipw2200
From: John W. Linville @ 2010-06-29 13:49 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4C29F711.1090306@lwfinger.net>
On Tue, Jun 29, 2010 at 08:37:21AM -0500, Larry Finger wrote:
> I'm trying to help an ipw2200 user on the openSUSE Wireless Forum and I'm
> stuck. The system is failing to load the firmware with error -2 (File or
> directory not found). The difficulty is that the required files are
> present with the correct permissions.
>
> What system component might be missing and/or borked to get this symptom?
selinux?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Problem with firmware load on ipw2200
From: Larry Finger @ 2010-06-29 13:37 UTC (permalink / raw)
To: wireless
I'm trying to help an ipw2200 user on the openSUSE Wireless Forum and I'm
stuck. The system is failing to load the firmware with error -2 (File or
directory not found). The difficulty is that the required files are
present with the correct permissions.
What system component might be missing and/or borked to get this symptom?
Thanks,
Larry
^ permalink raw reply
* Re: Compat-wireless release for 2010-06-26 is baked
From: Andrei Emeltchenko @ 2010-06-29 12:31 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Compat-wireless cronjob account, linux-wireless, linux-bluetooth
In-Reply-To: <AANLkTin1ZRFgTCylXOYW0HtkOjhXYWmPNZUGrqjMqhKL@mail.gmail.com>
Hi,
On Mon, Jun 28, 2010 at 7:38 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Mon, Jun 28, 2010 at 4:13 AM, Andrei Emeltchenko
> <andrei.emeltchenko.news@gmail.com> wrote:
>> Hi
>>
>> On Sat, Jun 26, 2010 at 10:02 PM, Compat-wireless cronjob account
>> <compat@orbit-lab.org> wrote:
>>
>> Looks like the mail is sent to wrong ML?
>
> Its for BT too.
I think those cron mails are not interesting to BT developers.
-- Andrei
^ permalink raw reply
* Re: [ath9k-devel] ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Felix Fietkau @ 2010-06-29 11:45 UTC (permalink / raw)
To: Benoit Papillault; +Cc: Björn Smedman, ath9k-devel, linux-wireless
In-Reply-To: <4C298DD2.8010704@free.fr>
On 2010-06-29 8:08 AM, Benoit Papillault wrote:
> Le 29/06/2010 00:55, Felix Fietkau a écrit :
>> On 2010-06-29 12:31 AM, Björn Smedman wrote:
>>> Hi all,
>>>
>>> I'm getting weird values from the debugfs file ieee80211/phy0/tsf: the
>>> value goes up and down rather randomly and only the lower 24 bits or
>>> so seem to ever be used (see below for details).
>>>
>>> The only thing running on phy0 is a single ap interface (and the
>>> monitor companion that hostapd sets up). I was expecting tsf to
>>> increase monotonically until all 64 bits had been used.
>>>
>>> For a moment I thought it might be the kernel snprintf (on mips)
>>> playing a trick on me so I tried the following patch. But the result
>>> is the same.
>> IMHO the most likely problem source is stuck beacons. Please compile the
>> driver with the debug option enabled and load it with
>> insmod ath9k debug=0x00000100
>>
>> - Felix
>
> Humm... I observed a similar behavior a while ago because only the 15
> lower bits of rstamp were used when being extended (but rstamp is 32
> bits in fact). If so, it has been fixed by Felix in the following commit :
Nope, different issue. The TSF extending applies only to rx timestamps,
however Björn has been observing weird TSF values from the hw register.
The Rx TSF timestamp is pretty much irrelevant in AP mode.
- Felix
^ permalink raw reply
* [RFC 0/3] Update for some defects
From: Yuri Ershov @ 2010-06-29 11:08 UTC (permalink / raw)
To: johannes; +Cc: ext-yuri.kululin, linux-wireless
Hello,
These are some proposals for wireless code minor defects.
Yuri Ershov (3):
mac80211: Put some code under MESH macro
nl80211: Fix memory leaks
cfg80211: Update of regulatory request initiator handling
net/mac80211/tx.c | 2 ++
net/wireless/nl80211.c | 2 ++
net/wireless/reg.c | 3 ++-
3 files changed, 6 insertions(+), 1 deletions(-)
^ permalink raw reply
* [RFC 3/3] cfg80211: Update of regulatory request initiator handling
From: Yuri Ershov @ 2010-06-29 11:08 UTC (permalink / raw)
To: johannes; +Cc: ext-yuri.kululin, linux-wireless
In-Reply-To: <cover.1277808543.git.ext-yuri.ershov@nokia.com>
In some cases there could be possible dereferencing freed pointer. The
update is intended to avoid this issue.
Signed-off-by: Yuri Ershov <ext-yuri.ershov@nokia.com>
---
net/wireless/reg.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 1ac2bdd..9ee2be9 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1831,6 +1831,7 @@ static void reg_process_hint(struct regulatory_request *reg_request)
{
int r = 0;
struct wiphy *wiphy = NULL;
+ enum nl80211_reg_initiator initiator = reg_request->initiator;
BUG_ON(!reg_request->alpha2);
@@ -1850,7 +1851,7 @@ static void reg_process_hint(struct regulatory_request *reg_request)
/* This is required so that the orig_* parameters are saved */
if (r == -EALREADY && wiphy &&
wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY)
- wiphy_update_regulatory(wiphy, reg_request->initiator);
+ wiphy_update_regulatory(wiphy, initiator);
out:
mutex_unlock(®_mutex);
mutex_unlock(&cfg80211_mutex);
--
1.7.0.4
^ permalink raw reply related
* [RFC 1/3] mac80211: Put some code under MESH macro
From: Yuri Ershov @ 2010-06-29 11:08 UTC (permalink / raw)
To: johannes; +Cc: ext-yuri.kululin, linux-wireless
In-Reply-To: <cover.1277808543.git.ext-yuri.ershov@nokia.com>
In the function ieee80211_subif_start_xmit the logic related with
meshdrlen is under CONFIG_MAC80211_MESH macro, but in one place it isn't.
This is some update for this
Signed-off-by: Yuri Ershov <ext-yuri.ershov@nokia.com>
---
---
net/mac80211/tx.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 698d471..007b76a 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1942,11 +1942,13 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
h_pos += encaps_len;
}
+#ifdef CONFIG_MAC80211_MESH
if (meshhdrlen > 0) {
memcpy(skb_push(skb, meshhdrlen), &mesh_hdr, meshhdrlen);
nh_pos += meshhdrlen;
h_pos += meshhdrlen;
}
+#endif
if (ieee80211_is_data_qos(fc)) {
__le16 *qos_control;
--
1.7.0.4
^ permalink raw reply related
* [RFC 2/3] nl80211: Fix memory leaks
From: Yuri Ershov @ 2010-06-29 11:08 UTC (permalink / raw)
To: johannes; +Cc: ext-yuri.kululin, linux-wireless
In-Reply-To: <cover.1277808543.git.ext-yuri.ershov@nokia.com>
In case of errors during message composing msg should be freed after canceling.
Signed-off-by: Yuri Kululin <ext-yuri.kululin@nokia.com>
Signed-off-by: Yuri Ershov <ext-yuri.ershov@nokia.com>
---
net/wireless/nl80211.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index a999fc1..c6bff6b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2769,6 +2769,7 @@ static int nl80211_get_mesh_params(struct sk_buff *skb,
nla_put_failure:
genlmsg_cancel(msg, hdr);
+ nlmsg_free(msg);
err = -EMSGSIZE;
out:
/* Cleanup */
@@ -2960,6 +2961,7 @@ static int nl80211_get_reg(struct sk_buff *skb, struct genl_info *info)
nla_put_failure:
genlmsg_cancel(msg, hdr);
+ nlmsg_free(msg);
err = -EMSGSIZE;
out:
mutex_unlock(&cfg80211_mutex);
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox