* Re: [Bugme-new] [Bug 13856] New: sk_bound_dev_if should be set for a socket when using IP_MULITCAST_IF or IP_ADD_MEMBERSHIO
From: Andrew Morton @ 2009-07-29 19:52 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, manlidj
In-Reply-To: <bug-13856-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Tue, 28 Jul 2009 03:42:38 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13856
>
> Summary: sk_bound_dev_if should be set for a socket when using
> IP_MULITCAST_IF or IP_ADD_MEMBERSHIO
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.27.7
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: manlidj@hotmail.com
> Regression: No
>
>
> Currently there is no way to tell which interface a multicast packet arrived on
> except by using a raw socket and issuing the SO_BINDTODEVICE option which
> forces the sk_bound_dev_if for the socket to be set.
>
> Consider a multi-homed system where a service needs to listen for multicast
> SSDP messages on a number of interfaces. The system needs to know which
> interface a search message came in on in order to respond with the correct URL.
>
> The service needs to join the multicast group on all interfaces. It must bind
> on INADDR_ANY and then issue the IP_ADD_MEMBERSHIP call.
>
> 1. If it uses one socket and joins on all interfaces it will receive mulitcast
> from all interfaces but cannot tell which interface the message came in on
>
> 2. It it uses a socket per interface each bound on INADDR_ANY and issues
> IP_MULTICAST_IF. In this case any mulitcast socket, no matter what interface,
> will be forwarded to each socket because sk_bound_dev_if was not set (i.e. 0) -
> see net/ipv4/udp.c [ udp_v4_mcast_next ]
>
> Suggested solution is to set sk_bound_dev_if when IP_MULTICAST_IF is issued.
>
^ permalink raw reply
* [RESEND 2/2] net/9p: Insulate the client against an invalid error code sent by a 9p server.
From: Abhishek Kulkarni @ 2009-07-29 19:49 UTC (permalink / raw)
To: v9fs-developer; +Cc: linux-kernel, netdev
In-Reply-To: <1248896942-13027-1-git-send-email-adkulkar@umail.iu.edu>
A looney tunes server sending an invalid error code (which is !IS_ERR_VALUE)
can result in a client oops. So fix it by adding a check and converting unknown
or invalid error codes to -ESERVERFAULT.
Signed-off-by: Abhishek Kulkarni <adkulkar@umail.iu.edu>
---
:100644 100644 7bbd2d5... 5bf5f22... M net/9p/client.c
:100644 100644 fdebe43... 5251851... M net/9p/error.c
net/9p/client.c | 7 +------
net/9p/error.c | 2 +-
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/net/9p/client.c b/net/9p/client.c
index 7bbd2d5..5bf5f22 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -411,14 +411,9 @@ static int p9_check_errors(struct p9_client *c, struct p9_req_t *req)
if (c->dotu)
err = -ecode;
- if (!err) {
+ if (!err || !IS_ERR_VALUE(err))
err = p9_errstr2errno(ename, strlen(ename));
- /* string match failed */
- if (!err)
- err = -ESERVERFAULT;
- }
-
P9_DPRINTK(P9_DEBUG_9P, "<<< RERROR (%d) %s\n", -ecode, ename);
kfree(ename);
diff --git a/net/9p/error.c b/net/9p/error.c
index fdebe43..5251851 100644
--- a/net/9p/error.c
+++ b/net/9p/error.c
@@ -239,7 +239,7 @@ int p9_errstr2errno(char *errstr, int len)
errstr[len] = 0;
printk(KERN_ERR "%s: server reported unknown error %s\n",
__func__, errstr);
- errno = 1;
+ errno = ESERVERFAULT;
}
return -errno;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] eexpress: Read buffer overflow
From: Jarek Poplawski @ 2009-07-29 20:05 UTC (permalink / raw)
To: Roel Kluin; +Cc: David Miller, netdev, akpm
In-Reply-To: <4A704C40.1070606@gmail.com>
On Wed, Jul 29, 2009 at 03:18:56PM +0200, Roel Kluin wrote:
> start_code is 69 words, but the code always writes a multiple of 16 words,
> so the last 11 words written are outside the array.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> > Now you seem to make my previous math working :-)
> >
> >>> (max) i = 64, (max) j = 14, (64+14+16)/2 = 47 < 69, so it seems to copy
> >>> less than its size?
> >
> > Jarek P.
> >
>
> You're right, thanks for reviewing, this one should be correct.
Looks OK to me.
Thanks,
Jarek P.
>
> diff --git a/drivers/net/eexpress.c b/drivers/net/eexpress.c
> index 1686dca..1f016d6 100644
> --- a/drivers/net/eexpress.c
> +++ b/drivers/net/eexpress.c
> @@ -1474,13 +1474,13 @@ static void eexp_hw_init586(struct net_device *dev)
> outw(0x0000, ioaddr + 0x800c);
> outw(0x0000, ioaddr + 0x800e);
>
> - for (i = 0; i < (sizeof(start_code)); i+=32) {
> + for (i = 0; i < ARRAY_SIZE(start_code) * 2; i+=32) {
> int j;
> outw(i, ioaddr + SM_PTR);
> - for (j = 0; j < 16; j+=2)
> + for (j = 0; j < 16 && (i+j)/2 < ARRAY_SIZE(start_code); j+=2)
> outw(start_code[(i+j)/2],
> ioaddr+0x4000+j);
> - for (j = 0; j < 16; j+=2)
> + for (j = 0; j < 16 && (i+j+16)/2 < ARRAY_SIZE(start_code); j+=2)
> outw(start_code[(i+j+16)/2],
> ioaddr+0x8000+j);
> }
^ permalink raw reply
* Re: [PATCH] 3c515: Write outside array bounds
From: Jarek Poplawski @ 2009-07-29 20:43 UTC (permalink / raw)
To: Roel Kluin; +Cc: David S. Miller, netdev, Andrew Morton
In-Reply-To: <4A705904.4020505@gmail.com>
On Wed, Jul 29, 2009 at 04:13:24PM +0200, Roel Kluin wrote:
> Op 26-07-09 23:16, Jarek Poplawski schreef:
> > Roel Kluin wrote, On 07/26/2009 12:35 AM:
> >
> >> if dev_alloc_skb() fails on the first iteration, a write to
> >> cp->rx_ring[-1] occurs.
> >>
> >> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> >> ---
> >> Please review: can we error return like this?
> >
> >
> > I doubt we can return here: there is a lot of cleaning missing.
> >
> > Jarek P.
> I took drivers/net/3c59x.c as an example
>
> Is this going in the right direction?
The direction is right but a long and winding road... I guess it's for
somebody with drivers knowhow. It seems most of the corkscrew_close()
might be needed, including del_timer(). So, since this -1 case looks
quite unlikely, it might be reasonable to only limit the most obvious
damage with 'if (i != 0)' before [i - 1] write, like David advised
in lmc case?
Cheers,
Jarek P.
>
> diff --git a/drivers/net/3c515.c b/drivers/net/3c515.c
> index 3e00fa8..e94867d 100644
> --- a/drivers/net/3c515.c
> +++ b/drivers/net/3c515.c
> @@ -827,7 +827,7 @@ static int corkscrew_open(struct net_device *dev)
> skb = dev_alloc_skb(PKT_BUF_SZ);
> vp->rx_skbuff[i] = skb;
> if (skb == NULL)
> - break; /* Bad news! */
> + goto error; /* Bad news! */
> skb->dev = dev; /* Mark as being used by this device. */
> skb_reserve(skb, 2); /* Align IP on 16 byte boundaries */
> vp->rx_ring[i].addr = isa_virt_to_bus(skb->data);
> @@ -864,6 +864,17 @@ static int corkscrew_open(struct net_device *dev)
> ioaddr + EL3_CMD);
>
> return 0;
> +error:
> + pr_emerg("%s: no memory for rx ring\n", dev->name);
> + int j;
> + for (j = 0; j < i; j++) {
> + if (vp->rx_skbuff[j]) {
> + dev_kfree_skb(vp->rx_skbuff[j]);
> + vp->rx_skbuff[j] = NULL;
> + }
> + }
> + free_irq(dev->irq, dev);
> + return -ENOMEM;
> }
>
> static void corkscrew_timer(unsigned long data)
^ permalink raw reply
* pull request: wireless-2.6 2009-07-29
From: John W. Linville @ 2009-07-29 20:30 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is a small collection of fixes intended for 2.6.31. Several of
them are small fixes dug-out by the usual static analysis suspects.
There are also a couple of iwlwifi fixes that the Intel team thinks are
important -- they look reasonably safe to me and they should only effect
their drivers. Their are also some small fixes from Luis and Johannes.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit 8bae1b2b13beb4cf4c0f119f97640503c2b74b0f:
Don Skidmore (1):
ixgbe: fix for 82599 errata marking UDP checksum errors
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Dan Carpenter (1):
wireless: ERR_PTR vs null
Johannes Berg (2):
iwlwifi: fix TX queue race
mac80211: fix suspend
Luis R. Rodriguez (1):
mac80211: do not queue work after suspend in the dynamic ps timer
Roel Kluin (5):
airo: Buffer overflow
ath9k: Read outside array bounds
iwlwifi: Read outside array bounds
libertas: Read outside array bounds
libertas: Read buffer overflow
reinette chatre (1):
iwlagn: fix minimum number of queues setting
drivers/net/wireless/airo.c | 13 ++++++-------
drivers/net/wireless/ath/ath9k/eeprom.c | 4 ++--
drivers/net/wireless/iwlwifi/iwl-3945.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 6 ++++--
drivers/net/wireless/iwlwifi/iwl-tx.c | 14 ++++++++------
drivers/net/wireless/iwlwifi/iwl3945-base.c | 4 ++--
drivers/net/wireless/iwmc3200wifi/netdev.c | 6 ++----
drivers/net/wireless/libertas/assoc.c | 18 ++++++++----------
drivers/net/wireless/libertas/scan.c | 3 ++-
net/mac80211/mlme.c | 2 +-
net/mac80211/pm.c | 24 +++++++++++++++---------
net/mac80211/rx.c | 12 ++++++++++++
12 files changed, 63 insertions(+), 45 deletions(-)
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index c70604f..8ce5e4c 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -5918,20 +5918,19 @@ static int airo_set_essid(struct net_device *dev,
readSsidRid(local, &SSID_rid);
/* Check if we asked for `any' */
- if(dwrq->flags == 0) {
+ if (dwrq->flags == 0) {
/* Just send an empty SSID list */
memset(&SSID_rid, 0, sizeof(SSID_rid));
} else {
- int index = (dwrq->flags & IW_ENCODE_INDEX) - 1;
+ unsigned index = (dwrq->flags & IW_ENCODE_INDEX) - 1;
/* Check the size of the string */
- if(dwrq->length > IW_ESSID_MAX_SIZE) {
+ if (dwrq->length > IW_ESSID_MAX_SIZE)
return -E2BIG ;
- }
+
/* Check if index is valid */
- if((index < 0) || (index >= 4)) {
+ if (index >= ARRAY_SIZE(SSID_rid.ssids))
return -EINVAL;
- }
/* Set the SSID */
memset(SSID_rid.ssids[index].ssid, 0,
@@ -6819,7 +6818,7 @@ static int airo_set_txpow(struct net_device *dev,
return -EINVAL;
}
clear_bit (FLAG_RADIO_OFF, &local->flags);
- for (i = 0; cap_rid.txPowerLevels[i] && (i < 8); i++)
+ for (i = 0; i < 8 && cap_rid.txPowerLevels[i]; i++)
if (v == cap_rid.txPowerLevels[i]) {
readConfigRid(local, 1);
local->config.txPower = v;
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c b/drivers/net/wireless/ath/ath9k/eeprom.c
index a2fda70..ce0e86c 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -460,7 +460,7 @@ static int ath9k_hw_4k_check_eeprom(struct ath_hw *ah)
integer = swab32(eep->modalHeader.antCtrlCommon);
eep->modalHeader.antCtrlCommon = integer;
- for (i = 0; i < AR5416_MAX_CHAINS; i++) {
+ for (i = 0; i < AR5416_EEP4K_MAX_CHAINS; i++) {
integer = swab32(eep->modalHeader.antCtrlChain[i]);
eep->modalHeader.antCtrlChain[i] = integer;
}
@@ -914,7 +914,7 @@ static void ath9k_hw_set_4k_power_per_rate_table(struct ath_hw *ah,
ctlMode, numCtlModes, isHt40CtlMode,
(pCtlMode[ctlMode] & EXT_ADDITIVE));
- for (i = 0; (i < AR5416_NUM_CTLS) &&
+ for (i = 0; (i < AR5416_EEP4K_NUM_CTLS) &&
pEepData->ctlIndex[i]; i++) {
DPRINTF(ah->ah_sc, ATH_DBG_EEPROM,
" LOOP-Ctlidx %d: cfgCtl 0x%2.2x "
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.h b/drivers/net/wireless/iwlwifi/iwl-3945.h
index fbb3a57..2de6471 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.h
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.h
@@ -112,7 +112,7 @@ enum iwl3945_antenna {
#define IWL_TX_FIFO_NONE 7
/* Minimum number of queues. MAX_NUM is defined in hw specific files */
-#define IWL_MIN_NUM_QUEUES 4
+#define IWL39_MIN_NUM_QUEUES 4
#define IEEE80211_DATA_LEN 2304
#define IEEE80211_4ADDR_LEN 30
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index e2d620f..650e20a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -258,8 +258,10 @@ struct iwl_channel_info {
#define IWL_TX_FIFO_HCCA_2 6
#define IWL_TX_FIFO_NONE 7
-/* Minimum number of queues. MAX_NUM is defined in hw specific files */
-#define IWL_MIN_NUM_QUEUES 4
+/* Minimum number of queues. MAX_NUM is defined in hw specific files.
+ * Set the minimum to accommodate the 4 standard TX queues, 1 command
+ * queue, 2 (unused) HCCA queues, and 4 HT queues (one for each AC) */
+#define IWL_MIN_NUM_QUEUES 10
/* Power management (not Tx power) structures */
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index 9bbeec9..2e89040 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -720,8 +720,6 @@ int iwl_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
goto drop_unlock;
}
- spin_unlock_irqrestore(&priv->lock, flags);
-
hdr_len = ieee80211_hdrlen(fc);
/* Find (or create) index into station table for destination station */
@@ -729,7 +727,7 @@ int iwl_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
if (sta_id == IWL_INVALID_STATION) {
IWL_DEBUG_DROP(priv, "Dropping - INVALID STATION: %pM\n",
hdr->addr1);
- goto drop;
+ goto drop_unlock;
}
IWL_DEBUG_TX(priv, "station Id %d\n", sta_id);
@@ -750,14 +748,17 @@ int iwl_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
txq_id = priv->stations[sta_id].tid[tid].agg.txq_id;
swq_id = iwl_virtual_agg_queue_num(swq_id, txq_id);
}
- priv->stations[sta_id].tid[tid].tfds_in_queue++;
}
txq = &priv->txq[txq_id];
q = &txq->q;
txq->swq_id = swq_id;
- spin_lock_irqsave(&priv->lock, flags);
+ if (unlikely(iwl_queue_space(q) < q->high_mark))
+ goto drop_unlock;
+
+ if (ieee80211_is_data_qos(fc))
+ priv->stations[sta_id].tid[tid].tfds_in_queue++;
/* Set up driver data for this TFD */
memset(&(txq->txb[q->write_ptr]), 0, sizeof(struct iwl_tx_info));
@@ -902,7 +903,6 @@ int iwl_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
drop_unlock:
spin_unlock_irqrestore(&priv->lock, flags);
-drop:
return -1;
}
EXPORT_SYMBOL(iwl_tx_skb);
@@ -1171,6 +1171,8 @@ int iwl_tx_agg_start(struct iwl_priv *priv, const u8 *ra, u16 tid, u16 *ssn)
IWL_ERR(priv, "Start AGG on invalid station\n");
return -ENXIO;
}
+ if (unlikely(tid >= MAX_TID_COUNT))
+ return -EINVAL;
if (priv->stations[sta_id].tid[tid].agg.state != IWL_AGG_OFF) {
IWL_ERR(priv, "Start AGG when state is not IWL_AGG_OFF !\n");
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 956798f..2f50ab6 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -4018,10 +4018,10 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
SET_IEEE80211_DEV(hw, &pdev->dev);
if ((iwl3945_mod_params.num_of_queues > IWL39_MAX_NUM_QUEUES) ||
- (iwl3945_mod_params.num_of_queues < IWL_MIN_NUM_QUEUES)) {
+ (iwl3945_mod_params.num_of_queues < IWL39_MIN_NUM_QUEUES)) {
IWL_ERR(priv,
"invalid queues_num, should be between %d and %d\n",
- IWL_MIN_NUM_QUEUES, IWL39_MAX_NUM_QUEUES);
+ IWL39_MIN_NUM_QUEUES, IWL39_MAX_NUM_QUEUES);
err = -EINVAL;
goto out_ieee80211_free_hw;
}
diff --git a/drivers/net/wireless/iwmc3200wifi/netdev.c b/drivers/net/wireless/iwmc3200wifi/netdev.c
index aea5ccf..bf294e4 100644
--- a/drivers/net/wireless/iwmc3200wifi/netdev.c
+++ b/drivers/net/wireless/iwmc3200wifi/netdev.c
@@ -106,10 +106,8 @@ void *iwm_if_alloc(int sizeof_bus, struct device *dev,
int ret = 0;
wdev = iwm_wdev_alloc(sizeof_bus, dev);
- if (!wdev) {
- dev_err(dev, "no memory for wireless device instance\n");
- return ERR_PTR(-ENOMEM);
- }
+ if (IS_ERR(wdev))
+ return wdev;
iwm = wdev_to_iwm(wdev);
iwm->bus_ops = if_ops;
diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
index b9b3741..d699737 100644
--- a/drivers/net/wireless/libertas/assoc.c
+++ b/drivers/net/wireless/libertas/assoc.c
@@ -1,6 +1,7 @@
/* Copyright (C) 2006, Red Hat, Inc. */
#include <linux/types.h>
+#include <linux/kernel.h>
#include <linux/etherdevice.h>
#include <linux/ieee80211.h>
#include <linux/if_arp.h>
@@ -43,21 +44,21 @@ static int get_common_rates(struct lbs_private *priv,
u16 *rates_size)
{
u8 *card_rates = lbs_bg_rates;
- size_t num_card_rates = sizeof(lbs_bg_rates);
int ret = 0, i, j;
- u8 tmp[30];
+ u8 tmp[(ARRAY_SIZE(lbs_bg_rates) - 1) * (*rates_size - 1)];
size_t tmp_size = 0;
/* For each rate in card_rates that exists in rate1, copy to tmp */
- for (i = 0; card_rates[i] && (i < num_card_rates); i++) {
- for (j = 0; rates[j] && (j < *rates_size); j++) {
+ for (i = 0; i < ARRAY_SIZE(lbs_bg_rates) && card_rates[i]; i++) {
+ for (j = 0; j < *rates_size && rates[j]; j++) {
if (rates[j] == card_rates[i])
tmp[tmp_size++] = card_rates[i];
}
}
lbs_deb_hex(LBS_DEB_JOIN, "AP rates ", rates, *rates_size);
- lbs_deb_hex(LBS_DEB_JOIN, "card rates ", card_rates, num_card_rates);
+ lbs_deb_hex(LBS_DEB_JOIN, "card rates ", card_rates,
+ ARRAY_SIZE(lbs_bg_rates));
lbs_deb_hex(LBS_DEB_JOIN, "common rates", tmp, tmp_size);
lbs_deb_join("TX data rate 0x%02x\n", priv->cur_rate);
@@ -69,10 +70,7 @@ static int get_common_rates(struct lbs_private *priv,
lbs_pr_alert("Previously set fixed data rate %#x isn't "
"compatible with the network.\n", priv->cur_rate);
ret = -1;
- goto done;
}
- ret = 0;
-
done:
memset(rates, 0, *rates_size);
*rates_size = min_t(int, tmp_size, *rates_size);
@@ -322,7 +320,7 @@ static int lbs_associate(struct lbs_private *priv,
rates = (struct mrvl_ie_rates_param_set *) pos;
rates->header.type = cpu_to_le16(TLV_TYPE_RATES);
memcpy(&rates->rates, &bss->rates, MAX_RATES);
- tmplen = MAX_RATES;
+ tmplen = min_t(u16, ARRAY_SIZE(rates->rates), MAX_RATES);
if (get_common_rates(priv, rates->rates, &tmplen)) {
ret = -1;
goto done;
@@ -598,7 +596,7 @@ static int lbs_adhoc_join(struct lbs_private *priv,
/* Copy Data rates from the rates recorded in scan response */
memset(cmd.bss.rates, 0, sizeof(cmd.bss.rates));
- ratesize = min_t(u16, sizeof(cmd.bss.rates), MAX_RATES);
+ ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), MAX_RATES);
memcpy(cmd.bss.rates, bss->rates, ratesize);
if (get_common_rates(priv, cmd.bss.rates, &ratesize)) {
lbs_deb_join("ADHOC_JOIN: get_common_rates returned error.\n");
diff --git a/drivers/net/wireless/libertas/scan.c b/drivers/net/wireless/libertas/scan.c
index 601b542..6c95af3 100644
--- a/drivers/net/wireless/libertas/scan.c
+++ b/drivers/net/wireless/libertas/scan.c
@@ -5,6 +5,7 @@
* for sending scan commands to the firmware.
*/
#include <linux/types.h>
+#include <linux/kernel.h>
#include <linux/etherdevice.h>
#include <linux/if_arp.h>
#include <asm/unaligned.h>
@@ -876,7 +877,7 @@ static inline char *lbs_translate_scan(struct lbs_private *priv,
iwe.u.bitrate.disabled = 0;
iwe.u.bitrate.value = 0;
- for (j = 0; bss->rates[j] && (j < sizeof(bss->rates)); j++) {
+ for (j = 0; j < ARRAY_SIZE(bss->rates) && bss->rates[j]; j++) {
/* Bit rate given in 500 kb/s units */
iwe.u.bitrate.value = bss->rates[j] * 500000;
current_val = iwe_stream_add_value(info, start, current_val,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index aca22b0..07e7e41 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -721,7 +721,7 @@ void ieee80211_dynamic_ps_timer(unsigned long data)
{
struct ieee80211_local *local = (void *) data;
- if (local->quiescing)
+ if (local->quiescing || local->suspended)
return;
queue_work(local->hw.workqueue, &local->dynamic_ps_enable_work);
diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
index 7a549f9..5e3d476 100644
--- a/net/mac80211/pm.c
+++ b/net/mac80211/pm.c
@@ -55,15 +55,6 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
rcu_read_unlock();
- /* flush again, in case driver queued work */
- flush_workqueue(local->hw.workqueue);
-
- /* stop hardware - this must stop RX */
- if (local->open_count) {
- ieee80211_led_radio(local, false);
- drv_stop(local);
- }
-
/* remove STAs */
spin_lock_irqsave(&local->sta_lock, flags);
list_for_each_entry(sta, &local->sta_list, list) {
@@ -111,7 +102,22 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
drv_remove_interface(local, &conf);
}
+ /* stop hardware - this must stop RX */
+ if (local->open_count) {
+ ieee80211_led_radio(local, false);
+ drv_stop(local);
+ }
+
+ /*
+ * flush again, in case driver queued work -- it
+ * shouldn't be doing (or cancel everything in the
+ * stop callback) that but better safe than sorry.
+ */
+ flush_workqueue(local->hw.workqueue);
+
local->suspended = true;
+ /* need suspended to be visible before quiescing is false */
+ barrier();
local->quiescing = false;
return 0;
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index de5bba7..0936fc2 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2453,6 +2453,18 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb,
return;
}
+ /*
+ * If we're suspending, it is possible although not too likely
+ * that we'd be receiving frames after having already partially
+ * quiesced the stack. We can't process such frames then since
+ * that might, for example, cause stations to be added or other
+ * driver callbacks be invoked.
+ */
+ if (unlikely(local->quiescing || local->suspended)) {
+ kfree_skb(skb);
+ return;
+ }
+
if (status->flag & RX_FLAG_HT) {
/* rate_idx is MCS index */
if (WARN_ON(status->rate_idx < 0 ||
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply related
* pull request: wireless-next-2.6 2009-07-29
From: John W. Linville @ 2009-07-29 20:54 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Here is another batch of wireless bits intended for 2.6.32... Once
again, there is no particular theme to the bunch. This does cover the
usual round of driver updates for iwlwifi, ath9k, and others. There are
also some mac80211 and cfg80211 updates, including the final piece for
cfg80211 to supplant wireless extensions -- hooray!
Please let me know if there are problems!
John
P.S. There is a merge-test branch that contains sample merge conflict
resolutions. They are mostly simple.
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit 70034918930d2e5b68c09bced637228c50d9561a:
Stephen Rothwell (1):
net: fix multiple definitions of setup_w6692
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Alexander Beregalov (1):
ar9170: fix build error when !CONFIG_AR9170_LEDS
Gabor Juhos (2):
ath9k: fix race with IEEE80211_CONF_PS checks
ath9k: get rid of unnecessary setpower calls
Helmut Schaa (8):
mac80211: refactor the scan code
mac80211: advance the state machine immediately if no delay is needed
mac80211: introduce a new scan state "decision"
mac80211: Replace {sw, hw}_scanning variables with a bitfield
mac80211: implement basic background scanning
mac80211: rename scan_state to next_scan_state
cfg80211: increase scan result expire time
mac80211: fix an oops in ieee80211_scan_state_set_channel
Johannes Berg (16):
mac80211: cooperate more with network namespaces
cfg80211: make aware of net namespaces
mac80211: allow using network namespaces
mac80211: fix mlme timeouts
mac80211: fix PS-poll response, race
iwlwifi: fix up command sending
iwlwifi: remove command callback return value
cfg80211: fix circular lock dependency (1)
mac80211: fix receiving deauth
nl80211: add missing parameter clearing
cfg80211: fix disassoc while not associated
mac80211: verify info->control.vif is not NULL
cfg80211: combine iwfreq implementations
cfg80211: combine IWAP handlers
cfg80211: combine IWESSID handlers
cfg80211: self-contained wext handling where possible
John W. Linville (1):
ray_cs: remove bogus NULL check at head of ray_get_wireless_stats
Lars Ericsson (1):
rt2x00: Don't alter rt2x00dev->default_ant
Luis R. Rodriguez (4):
ath: map TH to FCC3_WORLD
mac80211: fix MLME issuing of probe requests while scanning
mac80211: fix oops due to missing private data
ath9k: remove unused ATH_PCI_VERSION
Pavel Machek (1):
iwlwifi: fix LED config option
Reinette Chatre (3):
iwlwifi: print packet contents in error case
iwlagn: fix null pointer access during ucode load on 1000
iwlagn: fix sparse warning when compiling without debug
Sujith (7):
mac80211: Add a few 802.11n defines for AMPDU parameters
ath9k: Trivial fix in Kconfig
ath9k: Fix a sparse warning
ath9k: Remove redundant HT macros
ath9k: Cleanup return values
ath9k: Remove a few redundant variables/macros
ath9k: Add debug counters for TX
Vivek Natarajan (2):
ath9k: Add init values for AR9287 based chipsets.
ath9k: Add support for AR9287 based chipsets.
Wey-Yi Guy (7):
iwlwifi: revert to active table when rate is not valid
iwlwifi: critical temperature enter/exit condition
iwlwifi: Thermal Throttling Management - Part 1
iwlwifi: Thermal Throttling Management - part 2
iwlwifi: Thermal Throttling debugfs function
iwlwifi: Name fix for MPDU density for TX aggregation
iwlwifi: debugFs to enable/disable HT40 support
drivers/net/wireless/ath/ar9170/main.c | 2 +
drivers/net/wireless/ath/ath9k/Kconfig | 4 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 11 +-
drivers/net/wireless/ath/ath9k/calib.c | 22 +-
drivers/net/wireless/ath/ath9k/debug.c | 85 ++
drivers/net/wireless/ath/ath9k/debug.h | 54 +
drivers/net/wireless/ath/ath9k/eeprom.c | 1203 +++++++++++++++++++++-
drivers/net/wireless/ath/ath9k/eeprom.h | 163 +++-
drivers/net/wireless/ath/ath9k/hw.c | 133 ++-
drivers/net/wireless/ath/ath9k/hw.h | 5 +-
drivers/net/wireless/ath/ath9k/initvals.h | 1516 +++++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/main.c | 35 +-
drivers/net/wireless/ath/ath9k/pci.c | 2 +
drivers/net/wireless/ath/ath9k/phy.h | 1 +
drivers/net/wireless/ath/ath9k/xmit.c | 85 +-
drivers/net/wireless/ath/regd_common.h | 2 +-
drivers/net/wireless/iwlwifi/Kconfig | 3 +
drivers/net/wireless/iwlwifi/iwl-1000.c | 77 ++-
drivers/net/wireless/iwlwifi/iwl-3945-led.c | 11 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 18 +-
drivers/net/wireless/iwlwifi/iwl-3945.h | 9 +-
drivers/net/wireless/iwlwifi/iwl-4965.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 45 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 59 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 85 ++-
drivers/net/wireless/iwlwifi/iwl-agn.c | 23 +-
drivers/net/wireless/iwlwifi/iwl-calib.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-commands.h | 7 +
drivers/net/wireless/iwlwifi/iwl-core.c | 35 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 6 +-
drivers/net/wireless/iwlwifi/iwl-debug.h | 2 +
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 84 ++
drivers/net/wireless/iwlwifi/iwl-dev.h | 116 ++-
drivers/net/wireless/iwlwifi/iwl-hcmd.c | 63 +-
drivers/net/wireless/iwlwifi/iwl-led.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-power.c | 526 ++++++++++
drivers/net/wireless/iwlwifi/iwl-power.h | 93 ++
drivers/net/wireless/iwlwifi/iwl-scan.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 48 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 100 ++-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 20 +-
drivers/net/wireless/iwmc3200wifi/Kconfig | 1 -
drivers/net/wireless/iwmc3200wifi/Makefile | 2 +-
drivers/net/wireless/iwmc3200wifi/iwm.h | 2 -
drivers/net/wireless/iwmc3200wifi/netdev.c | 1 -
drivers/net/wireless/iwmc3200wifi/wext.c | 187 ----
drivers/net/wireless/p54/txrx.c | 2 +-
drivers/net/wireless/ray_cs.c | 3 -
drivers/net/wireless/rt2x00/rt2x00config.c | 12 +-
drivers/net/wireless/rt2x00/rt2x00lib.h | 2 +-
drivers/net/wireless/rt2x00/rt2x00link.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 2 +-
include/linux/ieee80211.h | 25 +
include/linux/nl80211.h | 9 +
include/net/cfg80211.h | 104 +-
include/net/mac80211.h | 4 +
net/core/dev.c | 1 +
net/mac80211/Kconfig | 1 -
net/mac80211/Makefile | 1 -
net/mac80211/cfg.c | 14 +-
net/mac80211/ibss.c | 2 +-
net/mac80211/ieee80211_i.h | 45 +-
net/mac80211/iface.c | 22 +-
net/mac80211/main.c | 3 +-
net/mac80211/mesh.c | 2 +-
net/mac80211/mlme.c | 35 +-
net/mac80211/rx.c | 21 +-
net/mac80211/scan.c | 304 ++++--
net/mac80211/sta_info.h | 13 -
net/mac80211/tx.c | 109 +--
net/mac80211/util.c | 13 +
net/mac80211/wext.c | 235 -----
net/wireless/core.c | 78 ++-
net/wireless/core.h | 8 +-
net/wireless/ibss.c | 13 +-
net/wireless/mlme.c | 8 +
net/wireless/nl80211.c | 206 +++--
net/wireless/scan.c | 25 +-
net/wireless/sme.c | 5 +-
net/wireless/wext-compat.c | 180 +++-
net/wireless/wext-compat.h | 50 +
net/wireless/wext-sme.c | 13 +-
82 files changed, 5381 insertions(+), 1159 deletions(-)
delete mode 100644 drivers/net/wireless/iwmc3200wifi/wext.c
delete mode 100644 net/mac80211/wext.c
create mode 100644 net/wireless/wext-compat.h
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-07-29.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Matt Mackall @ 2009-07-29 21:48 UTC (permalink / raw)
To: Neil Horman; +Cc: Herbert Xu, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090729194300.GB17410@hmsreliant.think-freely.org>
On Wed, 2009-07-29 at 15:43 -0400, Neil Horman wrote:
> On Wed, Jul 29, 2009 at 02:07:58PM -0500, Matt Mackall wrote:
> > On Wed, 2009-07-29 at 15:35 +0800, Herbert Xu wrote:
> > > Hi:
> > >
> > > While working on TX mitigiation, I noticed that while netpoll
> > > takes care to avoid recursive dead locks on the NAPI path, it
> > > has no protection against the TX path when calling the poll
> > > function.
> > >
> > > So if a driver is in the TX path, and a printk occurs, then a
> > > recursive dead lock can occur if that driver tries to take the
> > > xmit lock in its poll function to clean up descriptors.
> > >
> > > Fortunately not a lot of drivers do this but at least some are
> > > vulnerable to it, e.g., tg3.
> > >
> > > So we need to make it very clear that the poll function must
> > > not take any locks or they must use try_lock if the driver is
> > > to support netpoll.
> >
> > What do you propose?
>
> I think there is actually some recursion protection. If you look in
> netpoll_send_skb (where all netpoll transmits pass through), we do a
> __netif_tx_trylock, and only continue down the tx path if we obtain the lock.
> If not, we call netpoll_poll, wait a while, and try again. I think that should
> prevent the deadlock condition you are concerned about.
Maybe. The general point remains that drivers implementing poll need to
be aware of possible recursion through printk/netconsole in the xmit
path. If there are private locks, netpoll is powerless to prevent
recursive lock attempts.
It occurs to me that we might be able to know when we've moved from core
kernel into a driver's tx path by wrapping the tx method pointer or call
its call sites with something that disabled netconsole until it exited.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* Re: [PATCH] [IPV4]: Buffer overflow
From: Jarek Poplawski @ 2009-07-29 22:02 UTC (permalink / raw)
To: Roel Kluin; +Cc: David S. Miller, netdev, Andrew Morton
In-Reply-To: <4A702A02.30509@gmail.com>
Roel Kluin wrote, On 07/29/2009 12:52 PM:
> If arp_format_neigh_entry() can be called with n->dev->addr_len == 0, then a
> write to hbuffer[-1] occurs.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Found with Parfait, http://research.sun.com/projects/parfait/
>
> It's not clear whether this can happen or not.
>
> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
> index c29d75d..252336f 100644
> --- a/net/ipv4/arp.c
> +++ b/net/ipv4/arp.c
> @@ -1304,7 +1304,8 @@ static void arp_format_neigh_entry(struct seq_file *seq,
> hbuffer[k++] = hex_asc_lo(n->ha[j]);
> hbuffer[k++] = ':';
> }
> - hbuffer[--k] = 0;
> + if (k != 0)
> + hbuffer[--k] = 0;
I guess for k == 0 we need hbuffer[0] = 0 too.
Jarek P.
> #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
> }
> #endif
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 2/2] c/r: Add AF_INET support (v3)
From: John Dykstra @ 2009-07-29 22:10 UTC (permalink / raw)
To: Oren Laadan
Cc: containers-qjLDD68F18O7TbgM5vRIOg, netdev-u79uwXL29TY76Z2rM5mHXA,
Dan Smith, Alexey Dobriyan
In-Reply-To: <4A6F306A.40303-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
On Tue, 2009-07-28 at 13:07 -0400, Oren Laadan wrote:
> When you destroy the virtual interface after (or during) the
> > migration, the TIME_WAIT socket will disappear from the sending
> host.
>
> Note that such sockets are unlikely to be referenced by _any_ process
> because they will have been closed already. So the checkpoint code
> will need to find such sockets not through file descriptors.
Dan, to maybe save you some searching... The time-wait chains can be
accessed via tcp_hashinfo.
-- John
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Herbert Xu @ 2009-07-29 22:38 UTC (permalink / raw)
To: Neil Horman; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090729194300.GB17410@hmsreliant.think-freely.org>
On Wed, Jul 29, 2009 at 03:43:00PM -0400, Neil Horman wrote:
>
> I think there is actually some recursion protection. If you look in
> netpoll_send_skb (where all netpoll transmits pass through), we do a
> __netif_tx_trylock, and only continue down the tx path if we obtain the lock.
> If not, we call netpoll_poll, wait a while, and try again. I think that should
> prevent the deadlock condition you are concerned about.
When netpoll_poll calls dev->poll which then takes the TX lock
you have no protection whatsoever. Some drivers do this in order
to ensure that TX descriptor cleanups do not race against the
transmitting side. See tg3 for an example.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Neil Horman @ 2009-07-29 23:15 UTC (permalink / raw)
To: Matt Mackall; +Cc: Herbert Xu, David S. Miller, netdev, Matt Carlson
In-Reply-To: <1248904097.4545.2934.camel@calx>
On Wed, Jul 29, 2009 at 04:48:17PM -0500, Matt Mackall wrote:
> On Wed, 2009-07-29 at 15:43 -0400, Neil Horman wrote:
> > On Wed, Jul 29, 2009 at 02:07:58PM -0500, Matt Mackall wrote:
> > > On Wed, 2009-07-29 at 15:35 +0800, Herbert Xu wrote:
> > > > Hi:
> > > >
> > > > While working on TX mitigiation, I noticed that while netpoll
> > > > takes care to avoid recursive dead locks on the NAPI path, it
> > > > has no protection against the TX path when calling the poll
> > > > function.
> > > >
> > > > So if a driver is in the TX path, and a printk occurs, then a
> > > > recursive dead lock can occur if that driver tries to take the
> > > > xmit lock in its poll function to clean up descriptors.
> > > >
> > > > Fortunately not a lot of drivers do this but at least some are
> > > > vulnerable to it, e.g., tg3.
> > > >
> > > > So we need to make it very clear that the poll function must
> > > > not take any locks or they must use try_lock if the driver is
> > > > to support netpoll.
> > >
> > > What do you propose?
> >
> > I think there is actually some recursion protection. If you look in
> > netpoll_send_skb (where all netpoll transmits pass through), we do a
> > __netif_tx_trylock, and only continue down the tx path if we obtain the lock.
> > If not, we call netpoll_poll, wait a while, and try again. I think that should
> > prevent the deadlock condition you are concerned about.
>
> Maybe. The general point remains that drivers implementing poll need to
> be aware of possible recursion through printk/netconsole in the xmit
> path. If there are private locks, netpoll is powerless to prevent
> recursive lock attempts.
>
Not quite. I agree private locking in a driver is a pain when you consider
netpoll clients, its not the tx/tx recursion you need to worry about though, its
shared locking between the tx and rx path that you need to be worried about.
We should be protected against deadlock on the _xmit_lock from what we discussed
above, but if you take a lock in the driver, then call printk, its possible that
you'll go down the ->poll routine path in the driver. If there you try to take
the same private lock, the result is then deadlock.
> It occurs to me that we might be able to know when we've moved from core
> kernel into a driver's tx path by wrapping the tx method pointer or call
> its call sites with something that disabled netconsole until it exited.
>
I was thinking that perhaps what we should do is simply not call netpoll_poll
from within netpoll_send_skb. That breaks the only spot that I see in which we
call a receive code from within the tx path, breaking the deadlock possibilty.
Perhaps instead we can call netif_rx_schedule on the network interfaces napi
struct. We already queue the frames and set a timer to try sending again later.
By calling netif_rx_schedule, we move the receive work to the net_rx_action
softirq (where it really should be).
Thoughts?
Neil
> --
> http://selenic.com : development and support for Mercurial and Linux
>
>
>
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Herbert Xu @ 2009-07-29 23:17 UTC (permalink / raw)
To: Neil Horman; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090729231517.GA32670@hmsreliant.think-freely.org>
On Wed, Jul 29, 2009 at 07:15:17PM -0400, Neil Horman wrote:
>
> Not quite. I agree private locking in a driver is a pain when you consider
> netpoll clients, its not the tx/tx recursion you need to worry about though, its
> shared locking between the tx and rx path that you need to be worried about.
> We should be protected against deadlock on the _xmit_lock from what we discussed
> above, but if you take a lock in the driver, then call printk, its possible that
> you'll go down the ->poll routine path in the driver. If there you try to take
> the same private lock, the result is then deadlock.
xmit_lock suffers from exactly the same problem in ->poll.
> I was thinking that perhaps what we should do is simply not call netpoll_poll
> from within netpoll_send_skb. That breaks the only spot that I see in which we
> call a receive code from within the tx path, breaking the deadlock possibilty.
> Perhaps instead we can call netif_rx_schedule on the network interfaces napi
> struct. We already queue the frames and set a timer to try sending again later.
> By calling netif_rx_schedule, we move the receive work to the net_rx_action
> softirq (where it really should be).
>
> Thoughts?
Alternatively we can modify the drivers to use try lock or other
mechanisms that do not result in a dead-lock.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] net: Keep interface binding when sending packets with ipi_ifindex = 0
From: John Dykstra @ 2009-07-30 0:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: Chia-chi Yeh, linux-kernel, netdev
In-Reply-To: <20090727144402.513369f1.akpm@linux-foundation.org>
On Mon, 2009-07-27 at 14:44 -0700, Andrew Morton wrote:
> (cc netdev)
>
> On Thu, 23 Jul 2009 14:39:28 -0700
> Chia-chi Yeh (_________) <chiachi@android.com> wrote:
>
> > In IPv4, sending a packet with ipi_ifindex = 0 via an interface-bound
> > socket will unbind the packet to that interface. This behavior is
> > different from IPv6 which treats ipi6_ifindex = 0 as unspecified.
> > Furthermore, IPv6 does not allow sending packets to other interface
> > than the bound one, but I am not sure if it is necessary in IPv4. The
> > following patch keeps the interface binding when ipi_ifindex = 0.
> >
> > Thanks,
> > Chia-chi
> >
> > --- a/net/ipv4/ip_sockglue.c 2009-07-24 04:50:45.000000000 +0800
> > +++ b/net/ipv4/ip_sockglue.c 2009-07-24 04:51:09.000000000 +0800
> > @@ -213,7 +213,8 @@
> > if (cmsg->cmsg_len != CMSG_LEN(sizeof(struct in_pktinfo)))
> > return -EINVAL;
> > info = (struct in_pktinfo *)CMSG_DATA(cmsg);
> > - ipc->oif = info->ipi_ifindex;
> > + if (info->ipi_ifindex)
> > + ipc->oif = info->ipi_ifindex;
> > ipc->addr = info->ipi_spec_dst.s_addr;
> > break;
> > }
A convenient copy of the man page says "When ipi_ifindex is not zero the
primary local address of the interface specified by the index overwrites
ipi_spec_dst for the routing table lookup."
But this is changing API behavior that's been this way since at least
the beginning of git history.
I guess Dave's letting this stand. I'm posting this just to make sure
this is an explicit decision.
--
John
^ permalink raw reply
* Re: IPv6 default routes timing out?
From: John Dykstra @ 2009-07-30 0:33 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev
In-Reply-To: <874osv8jyo.fsf@shaolin.home.digitalvampire.org>
On Wed, 2009-07-29 at 10:42 -0700, Roland Dreier wrote:
> I recently set up IPv6 on home home network -- openbsd 4.5 box serving
> as a router with wired and wireless ports, advertising routes via the
> openbsd rtadvd daemon. I have no problem on boxes on the wired
> network, which gets a default route like:
>
> default via fe80::240:63ff:feda:3d15 dev eth0 proto kernel metric 1024 expires 8630sec mtu 1500 advmss 1440 hoplimit 64
>
> However on laptops on the wireless network, I've seen the route
> timeout and apparently never reappear. This happens running both old
> kernels like 2.6.24 and also with 2.6.31-rc4, and on systems with both
> ipw2200 and iwlagn wirelss. The symptom is that if I leave my laptop
> running, say, overnight, in the morning the ipv6 default route is
> gone. ipv4 networking still works fine, and if I try explicit
> link-local ipv6 addresses on the laptop, they work fine too. But the
> ipv6 internet is gone because the kernel has no idea how to route
> packets to it.
>
> The openbsd rtadvd config is pretty basic, just:
>
> ral0:\
> :addr="2001:470:8379:2::":prefixlen#64:rltime#9000:\
> :maxinterval#120:mininterval#60:
>
> Any ideas as to what I'm doing wrong, or where the problem might be?
First thing I'd do is leave wireshark running overnight on the laptop
and see if the multicast router ads are making it to there.
--
John
^ permalink raw reply
* Re: [Bugme-new] [Bug 13856] New: sk_bound_dev_if should be set for a socket when using IP_MULITCAST_IF or IP_ADD_MEMBERSHIO
From: John Dykstra @ 2009-07-30 0:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon, manlidj
In-Reply-To: <20090729125203.efbcb7ef.akpm@linux-foundation.org>
> ReportedBy: manlidj@hotmail.com
> > Currently there is no way to tell which interface a multicast packet arrived on
> > except by using a raw socket and issuing the SO_BINDTODEVICE option which
> > forces the sk_bound_dev_if for the socket to be set.
I thought the IP_PKTINFO cmsg was the usual way to do this.
--
John
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Neil Horman @ 2009-07-30 1:02 UTC (permalink / raw)
To: Herbert Xu; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090729231735.GB14066@gondor.apana.org.au>
On Thu, Jul 30, 2009 at 07:17:35AM +0800, Herbert Xu wrote:
> On Wed, Jul 29, 2009 at 07:15:17PM -0400, Neil Horman wrote:
> >
> > Not quite. I agree private locking in a driver is a pain when you consider
> > netpoll clients, its not the tx/tx recursion you need to worry about though, its
> > shared locking between the tx and rx path that you need to be worried about.
> > We should be protected against deadlock on the _xmit_lock from what we discussed
> > above, but if you take a lock in the driver, then call printk, its possible that
> > you'll go down the ->poll routine path in the driver. If there you try to take
> > the same private lock, the result is then deadlock.
>
> xmit_lock suffers from exactly the same problem in ->poll.
>
Under what conditions do you try to take the xmit_lock from within a drivers
->poll routine? Do you have an example?
Neil
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Neil Horman @ 2009-07-30 1:06 UTC (permalink / raw)
To: Herbert Xu; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090729223831.GA14066@gondor.apana.org.au>
On Thu, Jul 30, 2009 at 06:38:32AM +0800, Herbert Xu wrote:
> On Wed, Jul 29, 2009 at 03:43:00PM -0400, Neil Horman wrote:
> >
> > I think there is actually some recursion protection. If you look in
> > netpoll_send_skb (where all netpoll transmits pass through), we do a
> > __netif_tx_trylock, and only continue down the tx path if we obtain the lock.
> > If not, we call netpoll_poll, wait a while, and try again. I think that should
> > prevent the deadlock condition you are concerned about.
>
> When netpoll_poll calls dev->poll which then takes the TX lock
> you have no protection whatsoever. Some drivers do this in order
> to ensure that TX descriptor cleanups do not race against the
> transmitting side. See tg3 for an example.
but nothing in that path takes the xmit_lock. The poll_lock is taken in that
patch, but thats for recieve_side syncronization, not transmit side. Nothing in
the tg3 driver (to use your example), that I can see takes the xmit_lock in the
rx path either, so I'm not really sure where you comming from here.
Neil
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] iscsi: Use GFP_ATOMIC in iscsi_offload_mesg().
From: Mike Christie @ 2009-07-30 1:40 UTC (permalink / raw)
To: open-iscsi-/JYPxA39Uh5TLH3MbocFFw
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1248893392.16148.262.camel@HP1>
On 07/29/2009 01:49 PM, Michael Chan wrote:
> Changing to GFP_ATOMIC because the only caller in cnic/bnx2i may
> be calling this function while holding spin_lock.
>
> This problem was discovered by Mike Christie.
>
> Signed-off-by: Michael Chan<mchan-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> drivers/scsi/scsi_transport_iscsi.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c
> index 783e33c..b47240c 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -990,7 +990,7 @@ int iscsi_offload_mesg(struct Scsi_Host *shost,
> struct iscsi_uevent *ev;
> int len = NLMSG_SPACE(sizeof(*ev) + data_size);
>
> - skb = alloc_skb(len, GFP_NOIO);
> + skb = alloc_skb(len, GFP_ATOMIC);
> if (!skb) {
> printk(KERN_ERR "can not deliver iscsi offload message:OOM\n");
> return -ENOMEM;
> @@ -1012,7 +1012,7 @@ int iscsi_offload_mesg(struct Scsi_Host *shost,
>
> memcpy((char *)ev + sizeof(*ev), data, data_size);
>
> - return iscsi_multicast_skb(skb, ISCSI_NL_GRP_UIP, GFP_NOIO);
> + return iscsi_multicast_skb(skb, ISCSI_NL_GRP_UIP, GFP_ATOMIC);
> }
> EXPORT_SYMBOL_GPL(iscsi_offload_mesg);
>
Using GFP_NOIO and changing the locking is my preference normally, but
if the locking changes are going to be a problem, then this is ok with
me since we can fail allocations in other parts of the code.
Acked-by: Mike Christie <michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org>
Dave Miller probably wants to take this in his tree since it fixes a bug
with this patch
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=6d7760a88c25057c2c2243e5dfe2d731064bd31d
^ permalink raw reply
* Dear E-mail User
From: E-mail Ballot Result @ 2009-07-30 3:21 UTC (permalink / raw)
Please contact our payment department immediately to claim your winning/prize of One Million Euro.
Thanks,
Martin Freeman
Mail: pbl.uk02@live.com
^ permalink raw reply
* Re: [PATCH NEXT] netxen: fix CONFIG_INET=n build
From: David Miller @ 2009-07-30 4:42 UTC (permalink / raw)
To: randy.dunlap; +Cc: dhananjay, netdev, linux-kernel, linux-next
In-Reply-To: <20090728122352.6d4a2b05.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Tue, 28 Jul 2009 12:23:52 -0700
> On Tue, 28 Jul 2009 12:10:03 -0700 Dhananjay Phadke wrote:
>
>> Wrap dest IP hashing code with #ifdef CONFIG_INET,
>> this feature makes no sense without INET, but other
>> driver can still work.
>>
>> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
>
> Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH V3] CAN: Add Flexcan CAN controller driver
From: Sascha Hauer @ 2009-07-30 8:37 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Linux Netdev List, Socketcan-core
In-Reply-To: <4A7011BA.7040906@grandegger.com>
On Wed, Jul 29, 2009 at 11:09:14AM +0200, Wolfgang Grandegger wrote:
> Sascha Hauer wrote:
> > And another go...
> >
> > Sascha
> >
> >
> >>From 9f6f6fb67d57d082e056dec8121f1423c1b4fa0b Mon Sep 17 00:00:00 2001
> > From: Sascha Hauer <s.hauer@pengutronix.de>
> > Date: Tue, 21 Jul 2009 10:47:19 +0200
> > Subject: [PATCH] CAN: Add Flexcan CAN driver
> >
> > This core is found on some Freescale SoCs and also some Coldfire
> > SoCs. Support for Coldfire is missing though at the moment as
> > they have an older revision of the core which does not have RX FIFO
> > support.
> >
> > V3: integrated comments from Oliver Hartkopp
> > V2: integrated comments from Wolfgang Grandegger
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > drivers/net/can/Kconfig | 6 +
> > drivers/net/can/Makefile | 1 +
> > drivers/net/can/flexcan.c | 719 +++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 726 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/net/can/flexcan.c
> >
> > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> > index 33821a8..99c6da4 100644
> > --- a/drivers/net/can/Kconfig
> > +++ b/drivers/net/can/Kconfig
> > @@ -74,6 +74,12 @@ config CAN_KVASER_PCI
> > This driver is for the the PCIcanx and PCIcan cards (1, 2 or
> > 4 channel) from Kvaser (http://www.kvaser.com).
> >
> > +config CAN_FLEXCAN
> > + tristate "Support for Freescale FLEXCAN based chips"
> > + depends on CAN_DEV
> > + ---help---
> > + Say Y here if you want to support for Freescale FlexCAN.
> > +
> > config CAN_DEBUG_DEVICES
> > bool "CAN devices debugging messages"
> > depends on CAN
> > diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
> > index 523a941..25f2032 100644
> > --- a/drivers/net/can/Makefile
> > +++ b/drivers/net/can/Makefile
> > @@ -8,5 +8,6 @@ obj-$(CONFIG_CAN_DEV) += can-dev.o
> > can-dev-y := dev.o
> >
> > obj-$(CONFIG_CAN_SJA1000) += sja1000/
> > +obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o
> >
> > ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
> > diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
> > new file mode 100644
> > index 0000000..77661b3
> > --- /dev/null
> > +++ b/drivers/net/can/flexcan.c
> [...]
> > +static void flexcan_error(struct net_device *ndev, u32 stat)
> > +{
> > + struct can_frame *cf;
> > + struct sk_buff *skb;
> > + struct flexcan_priv *priv = netdev_priv(ndev);
> > + struct net_device_stats *stats = &ndev->stats;
> > + enum can_state state = priv->can.state;
> > + int error_warning = 0, rx_errors = 0, tx_errors = 0;
> > +
> > + skb = dev_alloc_skb(sizeof(struct can_frame));
> > + if (!skb)
> > + return;
> > +
> > + skb->dev = ndev;
> > + skb->protocol = __constant_htons(ETH_P_CAN);
> > + skb->ip_summed = CHECKSUM_UNNECESSARY;
> > +
> > + cf = (struct can_frame *)skb_put(skb, sizeof(*cf));
> > + memset(cf, 0, sizeof(*cf));
> > +
> > + cf->can_id = CAN_ERR_FLAG;
> > + cf->can_dlc = CAN_ERR_DLC;
> > +
> > + if (stat & ERRSTAT_RWRNINT) {
> > + error_warning = 1;
> > + cf->data[1] |= CAN_ERR_CRTL_RX_WARNING;
> > + }
> > +
> > + if (stat & ERRSTAT_TWRNINT) {
> > + error_warning = 1;
> > + cf->data[1] |= CAN_ERR_CRTL_TX_WARNING;
> > + }
>
> What is the meaning of this error warning interrupt? It does *not*
> change the state.
This TWRNINT means that the Tx error counter has transitioned from < 96
to >= 96 (analog the RWRNINT for the Rx error counter). Unfortunately
the state bits handled below do not reflect this error warning state.
So this interrupt signals us that we have been in error warning state
once but we have no possibility to detect if we are still in error
warning state. I don't know how to handle this correctly. I could
disable this interrupt and ignore it completely.
>
> > + switch ((stat >> 4) & 0x3) {
> > + case 0:
> > + state = CAN_STATE_ERROR_ACTIVE;
> > + break;
> > + case 1:
> > + state = CAN_STATE_ERROR_PASSIVE;
> > + break;
> > + default:
> > + state = CAN_STATE_BUS_OFF;
> > + break;
> > + }
>
> I'm still not happy with the error message generation. If a state change
> to error passive happens, it should be signaled to the user. Here my ideas:
>
> if (state != priv->can.state) {
> if (state == CAN_STATE_ERROR_WARNING) {
> cf->data[1] |= CAN_ERR_CRTL_RX_WARNING;
> priv->can.can_stats.error_warning++;
> } else if (state == CAN_STATE_ERROR_PASSIVE) {
> cf->data[1] |= CAN_ERR_CRTL_RX_PASSIVE;
> priv->can.can_stats.error_passive++;
> }
>
> It might have missed something, though.
Sorry, I missed that from your previous mail. As we can't properly
detect ERROR_WARNING state this would reduce to:
if (state != priv->can.state && state == CAN_STATE_ERROR_WARNING) {
cf->data[1] |= CAN_ERR_CRTL_RX_WARNING;
priv->can.can_stats.error_warning++;
}
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH V3] CAN: Add Flexcan CAN controller driver
From: Wolfgang Grandegger @ 2009-07-30 8:51 UTC (permalink / raw)
To: Sascha Hauer; +Cc: Socketcan-core, Linux Netdev List
In-Reply-To: <20090730083729.GC2714@pengutronix.de>
Sascha Hauer wrote:
> On Wed, Jul 29, 2009 at 11:09:14AM +0200, Wolfgang Grandegger wrote:
>> Sascha Hauer wrote:
>>> And another go...
>>>
>>> Sascha
>>>
>>>
>>> >From 9f6f6fb67d57d082e056dec8121f1423c1b4fa0b Mon Sep 17 00:00:00 2001
>>> From: Sascha Hauer <s.hauer@pengutronix.de>
>>> Date: Tue, 21 Jul 2009 10:47:19 +0200
>>> Subject: [PATCH] CAN: Add Flexcan CAN driver
>>>
>>> This core is found on some Freescale SoCs and also some Coldfire
>>> SoCs. Support for Coldfire is missing though at the moment as
>>> they have an older revision of the core which does not have RX FIFO
>>> support.
>>>
>>> V3: integrated comments from Oliver Hartkopp
>>> V2: integrated comments from Wolfgang Grandegger
>>>
>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>> ---
>>> drivers/net/can/Kconfig | 6 +
>>> drivers/net/can/Makefile | 1 +
>>> drivers/net/can/flexcan.c | 719 +++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 726 insertions(+), 0 deletions(-)
>>> create mode 100644 drivers/net/can/flexcan.c
>>>
>>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
>>> index 33821a8..99c6da4 100644
>>> --- a/drivers/net/can/Kconfig
>>> +++ b/drivers/net/can/Kconfig
>>> @@ -74,6 +74,12 @@ config CAN_KVASER_PCI
>>> This driver is for the the PCIcanx and PCIcan cards (1, 2 or
>>> 4 channel) from Kvaser (http://www.kvaser.com).
>>>
>>> +config CAN_FLEXCAN
>>> + tristate "Support for Freescale FLEXCAN based chips"
>>> + depends on CAN_DEV
>>> + ---help---
>>> + Say Y here if you want to support for Freescale FlexCAN.
>>> +
>>> config CAN_DEBUG_DEVICES
>>> bool "CAN devices debugging messages"
>>> depends on CAN
>>> diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
>>> index 523a941..25f2032 100644
>>> --- a/drivers/net/can/Makefile
>>> +++ b/drivers/net/can/Makefile
>>> @@ -8,5 +8,6 @@ obj-$(CONFIG_CAN_DEV) += can-dev.o
>>> can-dev-y := dev.o
>>>
>>> obj-$(CONFIG_CAN_SJA1000) += sja1000/
>>> +obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o
>>>
>>> ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
>>> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
>>> new file mode 100644
>>> index 0000000..77661b3
>>> --- /dev/null
>>> +++ b/drivers/net/can/flexcan.c
>> [...]
>>> +static void flexcan_error(struct net_device *ndev, u32 stat)
>>> +{
>>> + struct can_frame *cf;
>>> + struct sk_buff *skb;
>>> + struct flexcan_priv *priv = netdev_priv(ndev);
>>> + struct net_device_stats *stats = &ndev->stats;
>>> + enum can_state state = priv->can.state;
>>> + int error_warning = 0, rx_errors = 0, tx_errors = 0;
>>> +
>>> + skb = dev_alloc_skb(sizeof(struct can_frame));
>>> + if (!skb)
>>> + return;
>>> +
>>> + skb->dev = ndev;
>>> + skb->protocol = __constant_htons(ETH_P_CAN);
>>> + skb->ip_summed = CHECKSUM_UNNECESSARY;
>>> +
>>> + cf = (struct can_frame *)skb_put(skb, sizeof(*cf));
>>> + memset(cf, 0, sizeof(*cf));
>>> +
>>> + cf->can_id = CAN_ERR_FLAG;
>>> + cf->can_dlc = CAN_ERR_DLC;
>>> +
>>> + if (stat & ERRSTAT_RWRNINT) {
>>> + error_warning = 1;
>>> + cf->data[1] |= CAN_ERR_CRTL_RX_WARNING;
>>> + }
>>> +
>>> + if (stat & ERRSTAT_TWRNINT) {
>>> + error_warning = 1;
>>> + cf->data[1] |= CAN_ERR_CRTL_TX_WARNING;
>>> + }
>> What is the meaning of this error warning interrupt? It does *not*
>> change the state.
>
> This TWRNINT means that the Tx error counter has transitioned from < 96
> to >= 96 (analog the RWRNINT for the Rx error counter). Unfortunately
> the state bits handled below do not reflect this error warning state.
>
> So this interrupt signals us that we have been in error warning state
> once but we have no possibility to detect if we are still in error
> warning state. I don't know how to handle this correctly. I could
> disable this interrupt and ignore it completely.
>
>>> + switch ((stat >> 4) & 0x3) {
>>> + case 0:
>>> + state = CAN_STATE_ERROR_ACTIVE;
>>> + break;
>>> + case 1:
>>> + state = CAN_STATE_ERROR_PASSIVE;
>>> + break;
>>> + default:
>>> + state = CAN_STATE_BUS_OFF;
>>> + break;
>>> + }
>> I'm still not happy with the error message generation. If a state change
>> to error passive happens, it should be signaled to the user. Here my ideas:
>>
>> if (state != priv->can.state) {
>> if (state == CAN_STATE_ERROR_WARNING) {
>> cf->data[1] |= CAN_ERR_CRTL_RX_WARNING;
>> priv->can.can_stats.error_warning++;
>> } else if (state == CAN_STATE_ERROR_PASSIVE) {
>> cf->data[1] |= CAN_ERR_CRTL_RX_PASSIVE;
>> priv->can.can_stats.error_passive++;
>> }
>>
>> It might have missed something, though.
>
> Sorry, I missed that from your previous mail. As we can't properly
> detect ERROR_WARNING state this would reduce to:
>
> if (state != priv->can.state && state == CAN_STATE_ERROR_WARNING) {
> cf->data[1] |= CAN_ERR_CRTL_RX_WARNING;
> priv->can.can_stats.error_warning++;
> }
Why you can't detect error warning? When the [RT]WRNINT comes, the error
waning state has entered. By looking to the manual, the state changes to
error warning and bus-off are directly signaled via interrupt. A change
to error passive might be visible when bus error ints occurs. You could
add some dev_dbg's to the "if (stat & ERRSTAT_[RT]WRNINT)" and "switch"
blocks above and check with sending a message with no cable connected.
Wolfgang.
^ permalink raw reply
* RTNL: assertion failed at net/core/dev.c (3961)
From: Meelis Roos @ 2009-07-30 8:23 UTC (permalink / raw)
To: netdev
I'm running 2.6.31-rc4 on an i386 pc and got these two similar
but different in cause assertion failures on boot. Seems to be
repeatable. I saw similar messages on a kernel around -rc3 but it had
SIT troubles so I did not test more earlier rc-s.
This seems to be VLAN+IPv6 related, so some more info on the
configurartion:
eth0 is plain ethernet, internal LAN, IPv6 address autoconfigured from
external 6to4 address.
eth1 is ethernet, external interface. Dynamic IPv4, 6to4 tunnel is
created automatically from it. Only link-local IPv6 on this
interface. This is untagged, but it also carries VLAN 4 tagged.
eth1.4 is the VLAN on eth1 that carries iptv. Dynamic IPv4, only
link-local IPv6.
eth2 is plain internal LAN, like eth0 - static IPv4, IPv6 from 6to4.
tun6to4 is sti tunnel for 6to4, cofigured from eth1's IP.
eth0 and eth1 are 8139too, eth2 is uli526x.
RTNL: assertion failed at net/core/dev.c (3961)
Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #327
Call Trace:
[<c127fd2b>] ? printk+0x1d/0x32
[<c120c43c>] dev_unicast_sync+0x3b/0xfe
[<f8a0b19d>] vlan_dev_set_rx_mode+0x2f/0x45 [8021q]
[<c120bab5>] __dev_set_rx_mode+0x88/0x9e
[<c1211c48>] dev_mc_add+0x52/0x7c
[<f890d5d1>] igmp6_group_added+0x5e/0x160 [ipv6]
[<f8900923>] ? fib6_clean_node+0x0/0x9f [ipv6]
[<f890d9e6>] ipv6_dev_mc_inc+0x2b9/0x2dc [ipv6]
[<f88f6745>] addrconf_join_solict+0x43/0x56 [ipv6]
[<f88f197d>] ipv6_dev_ac_inc+0x15c/0x1ab [ipv6]
[<f88f5f55>] addrconf_join_anycast+0x82/0x9b [ipv6]
[<f88f75b4>] __ipv6_ifa_notify+0xd6/0x153 [ipv6]
[<f88f8584>] ? addrconf_dad_timer+0x0/0x120 [ipv6]
[<f88f7662>] ipv6_ifa_notify+0x31/0x4c [ipv6]
[<f88f76a3>] addrconf_dad_completed+0x26/0xb7 [ipv6]
[<f88f8607>] addrconf_dad_timer+0x83/0x120 [ipv6]
[<f89fd942>] ? garp_join_timer+0x0/0x79 [garp]
[<f89fd9a5>] ? garp_join_timer+0x63/0x79 [garp]
[<c102dbff>] run_timer_softirq+0x152/0x1ca
[<c1029b9b>] __do_softirq+0x69/0xe6
[<c1029b32>] ? __do_softirq+0x0/0xe6
<IRQ> [<c10298a2>] ? irq_exit+0x36/0x7b
[<c1012a71>] ? smp_apic_timer_interrupt+0x70/0x8c
[<c10032a1>] ? apic_timer_interrupt+0x31/0x38
[<c1008b67>] ? default_idle+0x36/0x5c
[<c1001cbb>] ? cpu_idle+0x72/0x9f
[<c1278d08>] ? rest_init+0x74/0x87
[<c13c9af9>] ? start_kernel+0x278/0x28e
[<c13c9312>] ? i386_start_kernel+0x40/0x56
ADDRCONF(NETDEV_UP): eth2: link is not ready
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3000+ processors (1 cpu
cores) (version 2.20.00)
powernow-k8: 0 : fid 0xa (1800 MHz), vid 0x6
powernow-k8: 1 : fid 0x2 (1000 MHz), vid 0x12
Marking TSC unstable due to cpufreq changes
RTNL: assertion failed at net/core/dev.c (3961)
Pid: 2744, comm: avahi-daemon Not tainted 2.6.31-rc4 #327
Call Trace:
[<c127fd2b>] ? printk+0x1d/0x32
[<c120c43c>] dev_unicast_sync+0x3b/0xfe
[<f8a0b19d>] vlan_dev_set_rx_mode+0x2f/0x45 [8021q]
[<c120bab5>] __dev_set_rx_mode+0x88/0x9e
[<c1211c48>] dev_mc_add+0x52/0x7c
[<f890d5d1>] igmp6_group_added+0x5e/0x160 [ipv6]
[<c1202560>] ? sock_alloc_send_pskb+0x9c/0x267
[<f890d9e6>] ipv6_dev_mc_inc+0x2b9/0x2dc [ipv6]
[<f890eb15>] ipv6_sock_mc_join+0x15d/0x1ce [ipv6]
[<f8902565>] do_ipv6_setsockopt+0x8a7/0xc2e [ipv6]
[<c11ff715>] ? sock_recvmsg+0xdf/0x108
[<c11ff877>] ? sock_sendmsg+0xd8/0x100
[<c10384fe>] ? autoremove_wake_function+0x0/0x54
[<c108eb47>] ? file_update_time+0x9e/0xd0
[<c11ffba2>] ? sys_sendto+0x10d/0x146
[<f890293f>] ipv6_setsockopt+0x53/0xb0 [ipv6]
[<f8905951>] udpv6_setsockopt+0x4c/0x67 [ipv6]
[<c1201262>] sock_common_setsockopt+0x22/0x38
[<c11ff150>] sys_setsockopt+0x79/0xa8
[<c1200cd1>] sys_socketcall+0x129/0x18a
[<c1002bbb>] sysenter_do_call+0x12/0x26
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: RTNL: assertion failed at net/core/dev.c (3961)
From: Eric Dumazet @ 2009-07-30 9:08 UTC (permalink / raw)
To: Meelis Roos; +Cc: netdev, Jiri Pirko
In-Reply-To: <Pine.SOC.4.64.0907301114150.10041@math.ut.ee>
Meelis Roos a écrit :
> I'm running 2.6.31-rc4 on an i386 pc and got these two similar
> but different in cause assertion failures on boot. Seems to be
> repeatable. I saw similar messages on a kernel around -rc3 but it had
> SIT troubles so I did not test more earlier rc-s.
>
> This seems to be VLAN+IPv6 related, so some more info on the
> configurartion:
>
> eth0 is plain ethernet, internal LAN, IPv6 address autoconfigured from
> external 6to4 address.
>
> eth1 is ethernet, external interface. Dynamic IPv4, 6to4 tunnel is
> created automatically from it. Only link-local IPv6 on this
> interface. This is untagged, but it also carries VLAN 4 tagged.
>
> eth1.4 is the VLAN on eth1 that carries iptv. Dynamic IPv4, only
> link-local IPv6.
>
> eth2 is plain internal LAN, like eth0 - static IPv4, IPv6 from 6to4.
>
> tun6to4 is sti tunnel for 6to4, cofigured from eth1's IP.
>
> eth0 and eth1 are 8139too, eth2 is uli526x.
>
> RTNL: assertion failed at net/core/dev.c (3961)
> Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #327
> Call Trace:
> [<c127fd2b>] ? printk+0x1d/0x32
> [<c120c43c>] dev_unicast_sync+0x3b/0xfe
> [<f8a0b19d>] vlan_dev_set_rx_mode+0x2f/0x45 [8021q]
> [<c120bab5>] __dev_set_rx_mode+0x88/0x9e
> [<c1211c48>] dev_mc_add+0x52/0x7c
> [<f890d5d1>] igmp6_group_added+0x5e/0x160 [ipv6]
> [<f8900923>] ? fib6_clean_node+0x0/0x9f [ipv6]
> [<f890d9e6>] ipv6_dev_mc_inc+0x2b9/0x2dc [ipv6]
> [<f88f6745>] addrconf_join_solict+0x43/0x56 [ipv6]
> [<f88f197d>] ipv6_dev_ac_inc+0x15c/0x1ab [ipv6]
> [<f88f5f55>] addrconf_join_anycast+0x82/0x9b [ipv6]
> [<f88f75b4>] __ipv6_ifa_notify+0xd6/0x153 [ipv6]
> [<f88f8584>] ? addrconf_dad_timer+0x0/0x120 [ipv6]
> [<f88f7662>] ipv6_ifa_notify+0x31/0x4c [ipv6]
> [<f88f76a3>] addrconf_dad_completed+0x26/0xb7 [ipv6]
> [<f88f8607>] addrconf_dad_timer+0x83/0x120 [ipv6]
> [<f89fd942>] ? garp_join_timer+0x0/0x79 [garp]
> [<f89fd9a5>] ? garp_join_timer+0x63/0x79 [garp]
> [<c102dbff>] run_timer_softirq+0x152/0x1ca
> [<c1029b9b>] __do_softirq+0x69/0xe6
> [<c1029b32>] ? __do_softirq+0x0/0xe6
> <IRQ> [<c10298a2>] ? irq_exit+0x36/0x7b
> [<c1012a71>] ? smp_apic_timer_interrupt+0x70/0x8c
> [<c10032a1>] ? apic_timer_interrupt+0x31/0x38
> [<c1008b67>] ? default_idle+0x36/0x5c
> [<c1001cbb>] ? cpu_idle+0x72/0x9f
> [<c1278d08>] ? rest_init+0x74/0x87
> [<c13c9af9>] ? start_kernel+0x278/0x28e
> [<c13c9312>] ? i386_start_kernel+0x40/0x56
> ADDRCONF(NETDEV_UP): eth2: link is not ready
> powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3000+ processors (1 cpu
> cores) (version 2.20.00)
> powernow-k8: 0 : fid 0xa (1800 MHz), vid 0x6
> powernow-k8: 1 : fid 0x2 (1000 MHz), vid 0x12
> Marking TSC unstable due to cpufreq changes
> RTNL: assertion failed at net/core/dev.c (3961)
> Pid: 2744, comm: avahi-daemon Not tainted 2.6.31-rc4 #327
> Call Trace:
> [<c127fd2b>] ? printk+0x1d/0x32
> [<c120c43c>] dev_unicast_sync+0x3b/0xfe
> [<f8a0b19d>] vlan_dev_set_rx_mode+0x2f/0x45 [8021q]
> [<c120bab5>] __dev_set_rx_mode+0x88/0x9e
> [<c1211c48>] dev_mc_add+0x52/0x7c
> [<f890d5d1>] igmp6_group_added+0x5e/0x160 [ipv6]
> [<c1202560>] ? sock_alloc_send_pskb+0x9c/0x267
> [<f890d9e6>] ipv6_dev_mc_inc+0x2b9/0x2dc [ipv6]
> [<f890eb15>] ipv6_sock_mc_join+0x15d/0x1ce [ipv6]
> [<f8902565>] do_ipv6_setsockopt+0x8a7/0xc2e [ipv6]
> [<c11ff715>] ? sock_recvmsg+0xdf/0x108
> [<c11ff877>] ? sock_sendmsg+0xd8/0x100
> [<c10384fe>] ? autoremove_wake_function+0x0/0x54
> [<c108eb47>] ? file_update_time+0x9e/0xd0
> [<c11ffba2>] ? sys_sendto+0x10d/0x146
> [<f890293f>] ipv6_setsockopt+0x53/0xb0 [ipv6]
> [<f8905951>] udpv6_setsockopt+0x4c/0x67 [ipv6]
> [<c1201262>] sock_common_setsockopt+0x22/0x38
> [<c11ff150>] sys_setsockopt+0x79/0xa8
> [<c1200cd1>] sys_socketcall+0x129/0x18a
> [<c1002bbb>] sysenter_do_call+0x12/0x26
>
>
Thanks for your detailed report Meelis
Seems because of following commit.
So assumption that dev_unicast_sync() is always called with RTNL is currently
false.
commit ccffad25b5136958d4769ed6de5e87992dd9c65c
Author: Jiri Pirko <jpirko@redhat.com>
Date: Fri May 22 23:22:17 2009 +0000
net: convert unicast addr list
This patch converts unicast address list to standard list_head using
previously introduced struct netdev_hw_addr. It also relaxes the
locking. Original spinlock (still used for multicast addresses) is not
needed and is no longer used for a protection of this list. All
reading and writing takes place under rtnl (with no changes).
I also removed a possibility to specify the length of the address
while adding or deleting unicast address. It's always dev->addr_len.
The convertion touched especially e1000 and ixgbe codes when the
change is not so trivial.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
^ permalink raw reply
* Re: tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Dave Young @ 2009-07-30 9:15 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Alan Cox, Marcel Holtmann, Linux Netdev List, linux-bluetooth
In-Reply-To: <4A705604.3040807@hartkopp.net>
On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver@hartkopp.net> wrote:
> Dave Young wrote:
>> On Mon, Jul 27, 2009 at 01:39:03PM +0200, Oliver Hartkopp wrote:
>>> Oliver Hartkopp wrote:
>>>> Dave Young wrote:
>>>>> On Sat, Jul 25, 2009 at 01:10:46PM +0100, Alan Cox wrote:
>>>>>>>> tty_register_device appears to have been called with a NULL pointer. Not
>>>>>>>> sure why however.
>>>>>>> if that is the pointer for the struct device, then that used to be fine
>>>>>>> in the past. Not all RFCOMM device have a parent when they are created.
>>>>>> The tty layer doesn't care about the struct device really. Nothing there
>>>>>> has changed. The NULL passed appears to be the driver argument.
>>>>> Agree with you, because in rfcomm_init, rfcomm thread run before tty initilized, the following patch may fix the problem.
>>>>> oliver, could you verify it it fix your problem?
>>>> Hi Dave,
>>>>
>>>> i get this problem really seldom on my Laptop and i did not manage to get a
>>>> reproducible Oops of that problem.
>>>>
>>>> Anyway the code you are pointing to seems to have a problem and your added
>>>> error handling looks good to me - even if i don't know if the initializations
>>>> can be reordered in that way.
>>>>
>>>> I'll try your patch, but it could take a *long* time to prove it right ;-)
>>>>
>>> Just FYI:
>>>
>>> Your patch compiled, the system booted without problems and nothing is broken
>>> so far. I checked the BT, WLAN and BT dial-up with success. So it looks good
>>> to me.
>>
>> Thanks for the testing. Marcel, could you take a look?
>
> Hi Dave,
>
> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
> attached screenshot).
Weird, the oops occurs between sock init and tty init routines. Could
you tell your bluez version and your configuration?
--
Regards
dave
^ permalink raw reply
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