headers
Christian Lamparter | 4 Jul 00:49

[WIP] p54: deal with allocation failures in rx path

This patch tries to address a long standing issue: 
how to survive serve memory starvation situations,
without losing the device due to missing transfer-buffers.

And with a flick of __GFP_NOWARN, we're able to handle ?all? memory
allocation failures on the rx-side during operation without much fuss.

However, there is still an issue within the xmit-part.
This is likely due to p54's demand for a large free headroom for
every outgoing frame:

 + transport header (differs from device to device)
      -> 16 bytes transport header (USB 1st gen)
      -> 8 bytes for (USB 2nd gen)
      -> 0 bytes for spi & pci
 + 12 bytes for p54_hdr
 + 44 bytes for p54_tx_data
 + up to 3 bytes for alignment
(+ 802.11 header as well? )

and this is where ieee80211_skb_resize comes into the play...
which will try to _relocate_ (alloc new, copy, free old) frame data,
as the headroom is most of the time simply not enough.
=>
 Call Trace: (from Larry - Bug #13319 )
 [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
 [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
 [<ffffffff802b6362>] new_slab+0xcf/0x28b
 [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
 [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Lamparter | 3 Jul 20:59

[PATCH] p54: two endian fixes

This patch fixes all CHECK_ENDIAN complains:

1. p54/fwio.c:296:6: warning: restricted __le32 degrades to integer
    p54/fwio.c:296:6: warning: restricted __le32 degrades to integer

2. p54/p54spi.c:172:32: warning: incorrect type in initializer
   p54spi.c:172:32:    expected restricted __le32 [usertype] buffer
   p54/p54spi.c:172:32:    got unsigned int

Signed-off-by: Christian Lamparter <chunkeey@...>
---
Max,

drivers/net/wireless/p54/p54spi.c:115: warning: ‘p54spi_read16’ defined but not used

looks like this function can be nuked, or do you have plans with it?
---
diff --git a/drivers/net/wireless/p54/fwio.c b/drivers/net/wireless/p54/fwio.c
index 9bff43d..349375f 100644
--- a/drivers/net/wireless/p54/fwio.c
+++ b/drivers/net/wireless/p54/fwio.c
@@ -292,8 +292,9 @@ int p54_tx_cancel(struct p54_common *priv, __le32 req_id)
 {
 	struct sk_buff *skb;
 	struct p54_txcancel *cancel;
+	u32 _req_id = le32_to_cpu(req_id);

-	if (unlikely(req_id < priv->rx_start || req_id > priv->rx_end))
+	if (unlikely(_req_id < priv->rx_start || _req_id > priv->rx_end))
 		return -EINVAL;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Reiner Herrmann | 3 Jul 09:15
Favicon

mac80211: Force beacon update?

Hi,

I want to attach a custom IE to beacons, but some drivers (like b43)
are fetching their beacons via ieee80211_beacon_get() only once and
retransmit this beacon every time.
Some other drivers (like mac80211_hwsim, ath9k) are calling it
before every beacon transmission.

Is there a general way to make all drivers generate new beacons instead
of caching them or would I have to adapt them?
If adapting drivers is the only way, do you have any suggestions on
how to do that?

Thank you for your answers.

Regards,
  Reiner
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Luciano Coelho | 3 Jul 07:24

[PATCH v2] mac80211: minstrel: avoid accessing negative indices in rix_to_ndx()

If rix is not found in mi->r[], i will become -1 after the loop.  This value
is eventually used to access arrays, so we were accessing arrays with a
negative index, which is obviously not what we want to do.  This patch fixes
this potential problem.

Signed-off-by: Luciano Coelho <luciano.coelho@...>
Acked-by: Felix Fietkau <nbd@...>
---
 net/mac80211/rc80211_minstrel.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index b218b98..37771ab 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -66,7 +66,7 @@ rix_to_ndx(struct minstrel_sta_info *mi, int rix)
 	for (i = rix; i >= 0; i--)
 		if (mi->r[i].rix == rix)
 			break;
-	WARN_ON(mi->r[i].rix != rix);
+	WARN_ON(i < 0);
 	return i;
 }

@@ -181,6 +181,9 @@ minstrel_tx_status(void *priv, struct ieee80211_supported_band *sband,
 			break;

 		ndx = rix_to_ndx(mi, ar[i].idx);
+		if (ndx < 0)
+			continue;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Preston L. Bannister | 3 Jul 01:56
Favicon

Re: Delivery Status Notification (Failure)

subscribe
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Luciano Coelho | 2 Jul 23:52

[PATCH] mac80211: minstrel: avoid accessing negative indices in rix_to_ndx()

If rix is not found in mi->r[], i will become -1 after the loop.  This value
is eventually used to access arrays, so we were accessing arrays with a
negative index, which is obviously not what we want to do.  This patch fixes
this potential problem.

Signed-off-by: Luciano Coelho <luciano.coelho@...>
---
 net/mac80211/rc80211_minstrel.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index b218b98..e2dd248 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -66,7 +66,7 @@ rix_to_ndx(struct minstrel_sta_info *mi, int rix)
 	for (i = rix; i >= 0; i--)
 		if (mi->r[i].rix == rix)
 			break;
-	WARN_ON(mi->r[i].rix != rix);
+	WARN_ON(i < 0 || mi->r[i].rix != rix);
 	return i;
 }

@@ -181,6 +181,9 @@ minstrel_tx_status(void *priv, struct ieee80211_supported_band *sband,
 			break;

 		ndx = rix_to_ndx(mi, ar[i].idx);
+		if (ndx < 0)
+			continue;
+
(Continue reading)

Permalink | Reply | 2 comments |
headers
Catalin Marinas | 2 Jul 23:30
Favicon

Memory leak in iwlwifi or false positive?

Hi,

I'm trying to get kmemleak more robust and with the latest patches (not
pushed yet) it seems to no longer show so many random leaks. However, I
get a lot of leaks reported in the iwlwifi code, about 4800 and they do
not disappear from any subsequent memory scanning (as is usually the
case with false positives). There are a lot of kmalloc's of < 512 bytes
and /proc/slabinfo seems to be in line with this:

kmalloc-512         5440   5481

This happens shortly after booting. Note that if an object is freed,
kmemleak no longer tracks it and therefore no reporting. But in this
case it looks like the iwlwifi code really allocated ~4800 blocks. Is it
normal for this code to keep so many blocks allocated? If yes, it is
probably kmemleak missing some root object in the references tree.

I'm not familiar with this code so any help is greatly appreciated.

The majority of kmemleak traces look like this:

unreferenced object 0xc1be3d40 (size 512):
  comm "iwlagn", pid 1571, jiffies 4294903229
  backtrace:
    [<c01e1f0b>] kmemleak_alloc+0x14b/0x290
    [<c01db2e5>] __kmalloc+0x125/0x1e0
    [<f95c77ef>] iwl_tx_queue_init+0x3f/0x310 [iwlcore]
    [<f95c9276>] iwl_txq_ctx_reset+0x206/0x5a0 [iwlcore]
    [<f95c199a>] iwl_hw_nic_init+0xba/0x110 [iwlcore]
    [<f9765263>] __iwl_up+0xb3/0x340 [iwlagn]
(Continue reading)

Permalink | Reply | 3 comments |
headers
Johannes Berg | 2 Jul 21:31
Favicon

[PATCH] nl80211: limit to one pairwise cipher for associate()

In this case, only one cipher makes sense, unlike for
connect() where it may be possible to have the card or
driver select.

No changes to mac80211 due to the way the structs are
laid out -- but the loop in net/mac80211/cfg.c will
degrade to just zero or one passes.

Signed-off-by: Johannes Berg <johannes@...>
---
 net/wireless/nl80211.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

--- wireless-testing.orig/net/wireless/nl80211.c	2009-07-02 21:30:54.000000000 +0200
+++ wireless-testing/net/wireless/nl80211.c	2009-07-02 21:31:55.000000000 +0200
@@ -3119,7 +3119,8 @@ unlock_rtnl:
 }

 static int nl80211_crypto_settings(struct genl_info *info,
-				   struct cfg80211_crypto_settings *settings)
+				   struct cfg80211_crypto_settings *settings,
+				   int cipher_limit)
 {
 	settings->control_port = info->attrs[NL80211_ATTR_CONTROL_PORT];

@@ -3134,7 +3135,7 @@ static int nl80211_crypto_settings(struc
 		if (len % sizeof(u32))
 			return -EINVAL;

-		if (settings->n_ciphers_pairwise > NL80211_MAX_NR_CIPHER_SUITES)
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Kilroy | 2 Jul 21:22

[PATCH] orinoco: fix printk format specifier for size_t arguments

This addresses the following compile warnings on 64-bit platforms.

drivers/net/wireless/orinoco/scan.c: In function 'orinoco_add_hostscan_results':
drivers/net/wireless/orinoco/scan.c:194: warning: format '%d' expects type 'int', but argument 3 has
type 'size_t'
drivers/net/wireless/orinoco/scan.c:211: warning: format '%d' expects type 'int', but argument 3 has
type 'size_t'
drivers/net/wireless/orinoco/scan.c:211: warning: format '%d' expects type 'int', but argument 4 has
type 'size_t'

Signed-off-by: David Kilroy <kilroyd@...>
---

Thanks to Johannes for pointing this out.

This was introduced in patch 21 of the cfg80211 switch series "orinoco:
convert scanning to cfg80211"

---
 drivers/net/wireless/orinoco/scan.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/orinoco/scan.c b/drivers/net/wireless/orinoco/scan.c
index 522eb98..d2f10e9 100644
--- a/drivers/net/wireless/orinoco/scan.c
+++ b/drivers/net/wireless/orinoco/scan.c
@@ -190,7 +190,7 @@ void orinoco_add_hostscan_results(struct orinoco_private *priv,
 			/* Sanity check for atom_len */
 			if (atom_len < sizeof(struct prism2_scan_apinfo)) {
 				printk(KERN_ERR "%s: Invalid atom_len in scan "
(Continue reading)

Permalink | Reply | 1 comment |
headers
Johannes Berg | 2 Jul 18:23
Favicon

[PATCH] cfg80211: refuse authenticating to same BSSID twice

It is possible that there are different BSS structs with
the same BSSID, but we cannot authenticate with multiple
of them them because we need the BSSID to be unique for
deauthenticating/disassociating.

Signed-off-by: Johannes Berg <johannes@...>
---
 net/wireless/mlme.c |   22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

--- wireless-testing.orig/net/wireless/mlme.c	2009-07-02 18:18:51.000000000 +0200
+++ wireless-testing/net/wireless/mlme.c	2009-07-02 18:24:03.000000000 +0200
@@ -278,6 +278,21 @@ int cfg80211_mlme_auth(struct cfg80211_r
 	struct cfg80211_internal_bss *bss;
 	int i, err, slot = -1, nfree = 0;

+	if (wdev->current_bss &&
+	    memcmp(bssid, wdev->current_bss->pub.bssid, ETH_ALEN) == 0)
+		return -EALREADY;
+
+	for (i = 0; i < MAX_AUTH_BSSES; i++) {
+		if (wdev->authtry_bsses[i] &&
+		    memcmp(bssid, wdev->authtry_bsses[i]->pub.bssid,
+		    				ETH_ALEN) == 0)
+			return -EALREADY;
+		if (wdev->auth_bsses[i] &&
+		    memcmp(bssid, wdev->auth_bsses[i]->pub.bssid,
+		    				ETH_ALEN) == 0)
+			return -EALREADY;
+	}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Berg | 2 Jul 17:19
Favicon

[PATCH] cfg80211: keep track of BSSes

In order to avoid problems with BSS structs going away
while they're in use, I've long wanted to make cfg80211
keep track of them. Without the SME, that wasn't doable
but now that we have the SME we can do this too. It can
keep track of up to four separate authentications and
one association, regardless of whether it's controlled
by the cfg80211 SME or the userspace SME.

Signed-off-by: Johannes Berg <johannes@...>
---
 include/net/cfg80211.h  |   86 ++---------
 net/mac80211/cfg.c      |   22 +-
 net/mac80211/mlme.c     |    6 
 net/wireless/core.c     |    5 
 net/wireless/core.h     |   41 +++++
 net/wireless/ibss.c     |   12 -
 net/wireless/mlme.c     |  361 +++++++++++++++++++++++++++++++++++++++++++++---
 net/wireless/nl80211.c  |  144 +++++++++----------
 net/wireless/scan.c     |   31 ----
 net/wireless/sme.c      |  156 ++++++++++++--------
 net/wireless/wext-sme.c |    4 
 11 files changed, 591 insertions(+), 277 deletions(-)

--- wireless-testing.orig/include/net/cfg80211.h	2009-07-02 17:13:49.000000000 +0200
+++ wireless-testing/include/net/cfg80211.h	2009-07-02 17:17:11.000000000 +0200
@@ -584,7 +584,6 @@ enum cfg80211_signal_type {
  *	is no guarantee that these are well-formed!)
  * @len_information_elements: total length of the information elements
  * @signal: signal strength value (type depends on the wiphy's signal_type)
- * @hold: BSS should not expire
(Continue reading)

Permalink | Reply | 0 comments |

Gmane