Re: [PATCH 0/3] netpoll/netconsole fixes
On Thu, 19 Oct 2006 10:15:41 -0700 Stephen Hemminger [EMAIL PROTECTED] wrote: The netpoll transmit skb management is a mess, it has two paths and it's on Txq. These patches try and clean this up. I got a reject storm when applying the third patch then screwed it up rather than fixing it up. A rediff and resend is needed, please. Make sure it's against the latest -linus or -davem, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] netpoll: initialize skb for UDP
From: Stephen Hemminger [EMAIL PROTECTED] Date: Thu, 19 Oct 2006 10:15:42 -0700 Need to fully initialize skb to keep lower layers and queueing happy. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Applied, thanks Stephen. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: smallish review of acx1xx-wireless-driver.patch
On Fri, Oct 20, 2006 at 06:37:04AM +0400, Alexey Dobriyan wrote: Main griefs: a) home-grown lock debugger (what can it do what lockdep can't?) b) lack of endian annotations. I have a 95% patch for that. let me dig it up again. it depends on a previous patch to kill the (huge) remainders of the old included linux-wlan-ng derived wireless stack in the driver. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] One NET_INC_STATS() could be NET_INC_STATS_BH in tcp_v4_err()
From: Eric Dumazet [EMAIL PROTECTED] Date: Thu, 19 Oct 2006 17:45:26 +0200 I believe this NET_INC_STATS() call can be replaced by NET_INC_STATS_BH(), a little bit cheaper. Signed-off-by: Eric Dumazet [EMAIL PROTECTED] Applied, although I hope tcp_v4_err() never becomes a fast path :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [NET] can use __get_cpu_var() instead of per_cpu() in loopback driver
As BHs are off in loopback_xmit(), preemption cannot occurs, so we can use __get_cpu_var() instead of per_cpu() (and avoid a preempt_enable()/preempt_disable() pair) Signed-off-by: Eric Dumazet [EMAIL PROTECTED] --- net-2.6/drivers/net/loopback.c 2006-10-19 16:46:27.0 +0200 +++ net-2.6-ed/drivers/net/loopback.c 2006-10-20 09:11:04.0 +0200 @@ -153,14 +153,14 @@ #endif dev-last_rx = jiffies; - lb_stats = per_cpu(pcpu_lstats, get_cpu()); + /* it's OK to use __get_cpu_var() because BHs are off */ + lb_stats = __get_cpu_var(pcpu_lstats); lb_stats-bytes += skb-len; lb_stats-packets++; - put_cpu(); netif_rx(skb); - return(0); + return 0; } static struct net_device_stats loopback_stats;
Re: [PATCH] [NET] Size listen hash tables using backlog hint
From: Eric Dumazet [EMAIL PROTECTED] Date: Thu, 19 Oct 2006 11:27:50 +0200 Here is the second try for this patch. Many thanks for your feedback. [PATCH] [NET] Size listen hash tables using backlog hint This version looks very good. It's not a major bug fix (obviously) so we'll have to defer it to 2.6.20, so please resubmit once I open up the net-2.6.20 tree. Thanks a lot! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] inet_peer : group together avl_left, avl_right, v4daddr to speedup lookups on some CPUS
From: Eric Dumazet [EMAIL PROTECTED] Date: Thu, 19 Oct 2006 12:57:42 +0200 Lot of routers/embedded devices still use CPUS with 16/32 bytes cache lines. (486, Pentium, ... PIII) It makes sense to group together fields used at lookup time so they fit in one cache line. This reduce cache footprint and speedup lookups. Signed-off-by: Eric Dumazet [EMAIL PROTECTED] Applied, thanks Eric. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] can use __get_cpu_var() instead of per_cpu() in loopback driver
From: Eric Dumazet [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 09:18:35 +0200 As BHs are off in loopback_xmit(), preemption cannot occurs, so we can use __get_cpu_var() instead of per_cpu() (and avoid a preempt_enable()/preempt_disable() pair) Signed-off-by: Eric Dumazet [EMAIL PROTECTED] Applied, thanks Eric. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bluetooth update for 2.6
Hi Dave, here are another three bugfixes for the 2.6.19 kernel. Please forward them to Linus as soon as possible. Regards Marcel Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git This will update the following files: drivers/bluetooth/dtl1_cs.c |1 + drivers/bluetooth/hci_usb.c |3 +++ net/bluetooth/hidp/core.c |6 ++ 3 files changed, 6 insertions(+), 4 deletions(-) through these ChangeSets: Commit: 26cd6d320a0c757e26a529fce3b561ff18a14a57 Author: Marcel Holtmann [EMAIL PROTECTED] Fri, 20 Oct 2006 08:55:48 +0200 [Bluetooth] Fix HID disconnect NULL pointer dereference The latest HID disconnect sequence change introduced a NULL pointer dereference. For the quirk to handle buggy remote HID implementations, it is enough to wait for a potential control channel disconnect from the remote side and it is also enough to wait only 500 msecs. Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] Commit: 7817d1d21393737dddacafa9d229b8431b25e3c3 Author: Marcel Holtmann [EMAIL PROTECTED] Fri, 20 Oct 2006 08:55:34 +0200 [Bluetooth] Add missing entry for Nokia DTL-4 PCMCIA card The device id for the Nokia DTL-4 PCMCIA card was missing. This patch adds it back to the list of supported devices. Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] Commit: f57be46de356456b6eb2d8fb7af1143b4ec7f3cb Author: Marcel Holtmann [EMAIL PROTECTED] Fri, 20 Oct 2006 08:55:29 +0200 [Bluetooth] Add support for newer ANYCOM USB dongles This patch adds the vendor and product id of the ANYCOM Bluetooth USB-200 and USB-250 dongles and sets a flag to send HCI_Reset as the first command. Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bluetooth update for 2.6
From: Marcel Holtmann [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 09:49:48 +0200 Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git I've pulled these patches into my tree, thanks a lot! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
From: Stephen Hemminger [EMAIL PROTECTED] Date: Thu, 19 Oct 2006 10:15:43 -0700 The original skb management for netpoll was a mess, it had two queue paths and a callback. This changes it to have a per-instance transmit queue and use a tasklet rather than a work queue for the congested case. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] I think you mis-diffed this one: - WARN_ON(skb-protocol == 0); That line doesn't exist in my copy of net/core/netpoll.c even with your first patch applied. Also, you forgot to remove the -drop callback pointer from struct netpoll, which you should do if it really isn't used any more. I think you might run into problems there, as I believe the netdump stuff does make non-trivial use of the -drop callback. Indeed, it uses the -dump callback for invoking a special netpoll_start_netdump() function. I'm pretty sure -dump was created specifically to accomodate netdump. So this is something else which will need to be worked out before we can apply this patch. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] netpoll/netconsole fixes
From: Andrew Morton [EMAIL PROTECTED] Date: Thu, 19 Oct 2006 23:57:19 -0700 I got a reject storm when applying the third patch then screwed it up rather than fixing it up. A rediff and resend is needed, please. Make sure it's against the latest -linus or -davem, thanks. And I got rejects on #2 :-) His first patch is in my net-2.6 tree as of a few minutes ago, that one was fine. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH REPOST 1/2] NET: Accurate packet scheduling for ATM/ADSL (kernel)
jamal wrote: The poor guy has been persistent and has some good ideas and we need to encourage him to stick around. Why dont you help him get the patch in the shape you think is reasonable? I know you are busy elsewhere and your patch has been a while since you last promised. I will try to help as well. I have explained what I would like to see several times and sent a patch to demonstrate it. I'd be happy to help further (I would like to see this go in eventually), but there's nothing I can do besides repeating myself as long as we only get to see the same patch again and again. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AF_KEY extended xfrm_state selector handling
BTW, why not use xfrm instead? Then you dont have to worry about racoon. What do you mean by this? - Do you suggest that there is another IKE implemetation for Linux 2.6 IPSec stack which uses netlink socket (XFRM) for kernel communication? If so, would you please point me to it? Or - Do you mean to make racoon use the netlink socket (XFRM) instead of PF_KEY for the kernel communication? (Well I'm not brave enough to tackle that.) Or - Do you mean something completely else? Unless you care about running this in some other OS (I suspect these OSes probably have made use of SADB_EXT_ADDRESS_PROXY so that may be a futile effort in any case). I can see this might be problem, but a conditional compilation of the relevant bits of racoon should be enough to cope with that. cheers, jamal PS:- Nothing stands out for me in your patch, so i have no comment; i OK, could you please apply it then? wasnt sure if the concept of tcp/udp port meant much to the concept of a security association It is crucial for the multiple clients behind the same NAT scenario. Regards Michal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/2]d80211: hardware TKIP support for ipw3945
ipw3945 TKIP hwcrypto only support RC4 encryption,
so the stack needs to pre compute the michael MIC and the RC4key
for it.
Signed-off-by: Hong Liu [EMAIL PROTECTED]
---
include/net/d80211.h |7 +++
net/d80211/tkip.c| 25 +++--
net/d80211/tkip.h|2 ++
net/d80211/wpa.c | 10 +-
4 files changed, 33 insertions(+), 11 deletions(-)
a759f6251a0a5c7a8529c2ebd579acd6f0183cb4
diff --git a/include/net/d80211.h b/include/net/d80211.h
index a80f48b..48e1e01 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -176,6 +176,7 @@ struct ieee80211_tx_control {
*/
int icv_len:8; /* Length of the ICV/MIC field in octets */
int iv_len:8; /* Length of the IV field in octets */
+ u8 rc4key[16]; /* generated RC4 key for hw TKIP */
unsigned int queue:4; /* hardware queue to use for this frame;
* 0 = highest, hw-queues-1 = lowest */
unsigned int sw_retry_attempt:4; /* no. of times hw has tried to
@@ -476,6 +477,12 @@ struct ieee80211_hw {
/* Force software encryption for TKIP packets if WMM is enabled. */
unsigned int no_tkip_wmm_hwaccel:1;
+ /* Do TKIP key mixing in stack, send the generated RC4 key with
+* with each TX frame */
+ unsigned int tkip_include_rc4key:1;
+ /* calculate michael MIC in stack */
+ unsigned int tkip_include_mmic:1;
+
/* set if the payload needs to be padded at even boundaries after the
* header */
unsigned int extra_hdr_room:1;
diff --git a/net/d80211/tkip.c b/net/d80211/tkip.c
index 7e3665a..c031814 100644
--- a/net/d80211/tkip.c
+++ b/net/d80211/tkip.c
@@ -190,17 +190,9 @@ u8 * ieee80211_tkip_add_iv(u8 *pos, stru
return pos;
}
-
-/* Encrypt packet payload with TKIP using @key. @pos is a pointer to the
- * beginning of the buffer containing payload. This payload must include
- * headroom of eight octets for IV and Ext. IV and taildroom of four octets
- * for ICV. @payload_len is the length of payload (_not_ including extra
- * headroom and tailroom). @ta is the transmitter addresses. */
-void ieee80211_tkip_encrypt_data(struct crypto_tfm *tfm, struct ieee80211_key
*key,
-u8 *pos, size_t payload_len, u8 *ta)
+void ieee80211_tkip_gen_rc4key(struct ieee80211_key *key,
+ u8 *rc4key, u8* ta)
{
- u8 rc4key[16];
-
/* Calculate per-packet key */
if (key-u.tkip.iv16 == 0 || !key-u.tkip.tx_initialized) {
/* IV16 wrapped around - perform TKIP phase 1 */
@@ -212,6 +204,19 @@ void ieee80211_tkip_encrypt_data(struct
tkip_mixing_phase2(key-u.tkip.p1k, key-key[ALG_TKIP_TEMP_ENCR_KEY],
key-u.tkip.iv16, rc4key);
+}
+
+/* Encrypt packet payload with TKIP using @key. @pos is a pointer to the
+ * beginning of the buffer containing payload. This payload must include
+ * headroom of eight octets for IV and Ext. IV and taildroom of four octets
+ * for ICV. @payload_len is the length of payload (_not_ including extra
+ * headroom and tailroom). @ta is the transmitter addresses. */
+void ieee80211_tkip_encrypt_data(struct crypto_tfm *tfm, struct ieee80211_key
*key,
+u8 *pos, size_t payload_len, u8 *ta)
+{
+ u8 rc4key[16];
+
+ ieee80211_tkip_gen_rc4key(key, rc4key, ta);
pos = ieee80211_tkip_add_iv(pos, key, rc4key[0], rc4key[1], rc4key[2]);
ieee80211_wep_encrypt_data(tfm, rc4key, 16, pos, payload_len);
}
diff --git a/net/d80211/tkip.h b/net/d80211/tkip.h
index e36b85c..407556b 100644
--- a/net/d80211/tkip.h
+++ b/net/d80211/tkip.h
@@ -15,6 +15,8 @@ #include ieee80211_key.h
u8 * ieee80211_tkip_add_iv(u8 *pos, struct ieee80211_key *key,
u8 iv0, u8 iv1, u8 iv2);
+void ieee80211_tkip_gen_rc4key(struct ieee80211_key *key,
+ u8 *rc4key, u8* ta);
void ieee80211_tkip_encrypt_data(struct crypto_tfm *tfm, struct ieee80211_key
*key,
u8 *pos, size_t payload_len, u8 *ta);
enum {
diff --git a/net/d80211/wpa.c b/net/d80211/wpa.c
index 31abf9b..5e62464 100644
--- a/net/d80211/wpa.c
+++ b/net/d80211/wpa.c
@@ -104,7 +104,8 @@ #ifdef CONFIG_HOSTAPD_WPA_TESTING
#endif /* CONFIG_HOSTAPD_WPA_TESTING */
if (!tx-key-force_sw_encrypt !tx-local-conf.sw_decrypt
- !tx-fragmented !wpa_test) {
+ !tx-fragmented !tx-local-hw-tkip_include_mmic
+ !wpa_test) {
/* hwaccel - with no need for preallocated room for Michael MIC
*/
return TXRX_CONTINUE;
@@ -336,6 +337,13 @@ #endif /* CONFIG_HOSTAPD_WPA_TESTING */
0x7f),
(u8) key-u.tkip.iv16);
+ if (tx-local-hw-tkip_include_rc4key) {
+ hdr = (struct ieee80211_hdr *)skb-data;
+
[patch 2/2] d80211: fix wep_tfm race
The TX/RX path all use the local-wep_tfm to encrypt and decrypt
packets. Each {en|de}crypt operation need set a new RC4key,
this may corrupt the previous set key that is still being used.
Thus cause a lot of decrypton error or encryption with the wrong key.
Use two tfm (tx_tfm and rx_tfm) to avoid this race.
Signed-off-by: Hong Liu [EMAIL PROTECTED]
---
net/d80211/ieee80211_i.h |3 ++-
net/d80211/wep.c | 18 +-
net/d80211/wpa.c |6 --
3 files changed, 19 insertions(+), 8 deletions(-)
634c9615ce3cd06dc7f6aff05e43e61490a53472
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index 425fc9b..152b41a 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -402,7 +402,8 @@ #define IEEE80211_IRQSAFE_QUEUE_LIMIT 12
int long_retry_limit; /* dot11LongRetryLimit */
int short_preamble; /* use short preamble with IEEE 802.11b */
- struct crypto_tfm *wep_tfm;
+ struct crypto_tfm *wep_tx_tfm;
+ struct crypto_tfm *wep_rx_tfm;
u32 wep_iv;
int key_tx_rx_threshold; /* number of times any key can be used in TX
* or RX before generating a rekey
diff --git a/net/d80211/wep.c b/net/d80211/wep.c
index 22c2e53..06e0230 100644
--- a/net/d80211/wep.c
+++ b/net/d80211/wep.c
@@ -26,16 +26,23 @@ int ieee80211_wep_init(struct ieee80211_
/* start WEP IV from a random value */
get_random_bytes(local-wep_iv, WEP_IV_LEN);
- local-wep_tfm = crypto_alloc_tfm(arc4, 0);
- if (!local-wep_tfm)
+ local-wep_tx_tfm = crypto_alloc_tfm(arc4, 0);
+ if (!local-wep_tx_tfm)
return -ENOMEM;
+ local-wep_rx_tfm = crypto_alloc_tfm(arc4, 0);
+ if (!local-wep_rx_tfm) {
+ crypto_free_tfm(local-wep_tx_tfm);
+ return -ENOMEM;
+ }
+
return 0;
}
void ieee80211_wep_free(struct ieee80211_local *local)
{
- crypto_free_tfm(local-wep_tfm);
+ crypto_free_tfm(local-wep_tx_tfm);
+ crypto_free_tfm(local-wep_rx_tfm);
}
static inline int ieee80211_wep_weak_iv(u32 iv, int keylen)
@@ -172,7 +179,8 @@ int ieee80211_wep_encrypt(struct ieee802
/* Add room for ICV */
skb_put(skb, WEP_ICV_LEN);
- ieee80211_wep_encrypt_data(local-wep_tfm, rc4key, klen, iv +
WEP_IV_LEN, len);
+ ieee80211_wep_encrypt_data(local-wep_tx_tfm, rc4key, klen,
+ iv + WEP_IV_LEN, len);
kfree(rc4key);
@@ -252,7 +260,7 @@ int ieee80211_wep_decrypt(struct ieee802
/* Copy rest of the WEP key (the secret part) */
memcpy(rc4key + 3, key-key, key-keylen);
- if (ieee80211_wep_decrypt_data(local-wep_tfm, rc4key, klen,
+ if (ieee80211_wep_decrypt_data(local-wep_rx_tfm, rc4key, klen,
skb-data + hdrlen + WEP_IV_LEN,
len)) {
printk(KERN_DEBUG WEP decrypt failed (ICV)\n);
diff --git a/net/d80211/wpa.c b/net/d80211/wpa.c
index 5e62464..ef707ad 100644
--- a/net/d80211/wpa.c
+++ b/net/d80211/wpa.c
@@ -352,7 +352,8 @@ #endif /* CONFIG_HOSTAPD_WPA_TESTING */
skb_put(skb, TKIP_ICV_LEN);
hdr = (struct ieee80211_hdr *) skb-data;
- ieee80211_tkip_encrypt_data(tx-local-wep_tfm, key, pos, len,
hdr-addr2);
+ ieee80211_tkip_encrypt_data(tx-local-wep_tx_tfm,
+ key, pos, len, hdr-addr2);
return 0;
}
@@ -495,7 +496,8 @@ #endif /* CONFIG_HOSTAPD_WPA_TESTING */
hwaccel = 1;
}
- res = ieee80211_tkip_decrypt_data(rx-local-wep_tfm, key, skb-data +
hdrlen,
+ res = ieee80211_tkip_decrypt_data(rx-local-wep_rx_tfm,
+ key, skb-data + hdrlen,
skb-len - hdrlen, rx-sta-addr,
hwaccel, rx-u.rx.queue);
if (res != TKIP_DECRYPT_OK || wpa_test) {
--
1.3.3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/2] d80211: fix wep_tfm race
The TX/RX path all use the local-wep_tfm to encrypt and decrypt
packets. Each {en|de}crypt operation need set a new RC4key,
this may corrupt the previous set key that is still being used.
Thus cause a lot of decrypton error or encryption with the wrong key.
Use two tfm (tx_tfm and rx_tfm) to avoid this race.
Signed-off-by: Hong Liu [EMAIL PROTECTED]
---
net/d80211/ieee80211_i.h |3 ++-
net/d80211/wep.c | 18 +-
net/d80211/wpa.c |6 --
3 files changed, 19 insertions(+), 8 deletions(-)
634c9615ce3cd06dc7f6aff05e43e61490a53472
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index 425fc9b..152b41a 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -402,7 +402,8 @@ #define IEEE80211_IRQSAFE_QUEUE_LIMIT 12
int long_retry_limit; /* dot11LongRetryLimit */
int short_preamble; /* use short preamble with IEEE 802.11b */
- struct crypto_tfm *wep_tfm;
+ struct crypto_tfm *wep_tx_tfm;
+ struct crypto_tfm *wep_rx_tfm;
u32 wep_iv;
int key_tx_rx_threshold; /* number of times any key can be used in TX
* or RX before generating a rekey
diff --git a/net/d80211/wep.c b/net/d80211/wep.c
index 22c2e53..06e0230 100644
--- a/net/d80211/wep.c
+++ b/net/d80211/wep.c
@@ -26,16 +26,23 @@ int ieee80211_wep_init(struct ieee80211_
/* start WEP IV from a random value */
get_random_bytes(local-wep_iv, WEP_IV_LEN);
- local-wep_tfm = crypto_alloc_tfm(arc4, 0);
- if (!local-wep_tfm)
+ local-wep_tx_tfm = crypto_alloc_tfm(arc4, 0);
+ if (!local-wep_tx_tfm)
return -ENOMEM;
+ local-wep_rx_tfm = crypto_alloc_tfm(arc4, 0);
+ if (!local-wep_rx_tfm) {
+ crypto_free_tfm(local-wep_tx_tfm);
+ return -ENOMEM;
+ }
+
return 0;
}
void ieee80211_wep_free(struct ieee80211_local *local)
{
- crypto_free_tfm(local-wep_tfm);
+ crypto_free_tfm(local-wep_tx_tfm);
+ crypto_free_tfm(local-wep_rx_tfm);
}
static inline int ieee80211_wep_weak_iv(u32 iv, int keylen)
@@ -172,7 +179,8 @@ int ieee80211_wep_encrypt(struct ieee802
/* Add room for ICV */
skb_put(skb, WEP_ICV_LEN);
- ieee80211_wep_encrypt_data(local-wep_tfm, rc4key, klen, iv +
WEP_IV_LEN, len);
+ ieee80211_wep_encrypt_data(local-wep_tx_tfm, rc4key, klen,
+ iv + WEP_IV_LEN, len);
kfree(rc4key);
@@ -252,7 +260,7 @@ int ieee80211_wep_decrypt(struct ieee802
/* Copy rest of the WEP key (the secret part) */
memcpy(rc4key + 3, key-key, key-keylen);
- if (ieee80211_wep_decrypt_data(local-wep_tfm, rc4key, klen,
+ if (ieee80211_wep_decrypt_data(local-wep_rx_tfm, rc4key, klen,
skb-data + hdrlen + WEP_IV_LEN,
len)) {
printk(KERN_DEBUG WEP decrypt failed (ICV)\n);
diff --git a/net/d80211/wpa.c b/net/d80211/wpa.c
index 5e62464..ef707ad 100644
--- a/net/d80211/wpa.c
+++ b/net/d80211/wpa.c
@@ -352,7 +352,8 @@ #endif /* CONFIG_HOSTAPD_WPA_TESTING */
skb_put(skb, TKIP_ICV_LEN);
hdr = (struct ieee80211_hdr *) skb-data;
- ieee80211_tkip_encrypt_data(tx-local-wep_tfm, key, pos, len,
hdr-addr2);
+ ieee80211_tkip_encrypt_data(tx-local-wep_tx_tfm,
+ key, pos, len, hdr-addr2);
return 0;
}
@@ -495,7 +496,8 @@ #endif /* CONFIG_HOSTAPD_WPA_TESTING */
hwaccel = 1;
}
- res = ieee80211_tkip_decrypt_data(rx-local-wep_tfm, key, skb-data +
hdrlen,
+ res = ieee80211_tkip_decrypt_data(rx-local-wep_rx_tfm,
+ key, skb-data + hdrlen,
skb-len - hdrlen, rx-sta-addr,
hwaccel, rx-u.rx.queue);
if (res != TKIP_DECRYPT_OK || wpa_test) {
--
1.3.3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AF_KEY extended xfrm_state selector handling
From: Michal Růžička [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 10:56:13 +0200 - Do you suggest that there is another IKE implemetation for Linux 2.6 IPSec stack which uses netlink socket (XFRM) for kernel communication? If so, would you please point me to it? OpenSWAN is an IKE implementation that works with Linux and uses XFRM. It actually uses AF_KEY too, but only to probe the list of available crypto algorithms. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Announce] New netchannels implementation. Userspace network stack.
Netchannel [1] is pure bridge between low-level hardware and user, without any special protocol processing involved between them. Users are not limited to userspace only - I will use this netchannel infrastructure for fast NAT implementation, which is purely kernelspace user (although it is possible to create NAT in userspace, but price of the kernelspace board crossing is too high, which only needs to change some fields in the header and recalculate checksum). Userspace network stack [2] is another user of the new netchannel subsystem. Current netchannel version supports data transfer using copy*user(). One could ask how does it differ from netfilter's queue target? There are three differencies (read advantages): * it does not depend on netfilter (and thus does not introduce it's slow path) * it is very scalable, since it does not use neither hash tables, nor lists * it does not depend on netfilter (and thus does not introduce it's slow path). Yes, again, since if we get into account NAT implementation, then we need to add dependency on connection tracking, which is not needed for existing netchannels implementation. It is also much smaller and scalable compared to tun/tap devices. And some other small advantages: possibility to perform zero-copy sending and receiving using network allocator's [3] facilities (not implemented in the current version of netchannels), it is very small, there are no locks in the very short fast path (except RCU and skb queue linking lock, which is held for 5 operations) and so on... There are also some limitations: it is only possible to get one packet per read from netchannel's file descriptor (it is possible to extend it to read several packets, but right now I leave it as is), it is ipv4 only (I'm lazy and only implemented tree comparison functions for IPv4 addresses). First user of the netchannel subsystem is userspace network stack [2], which supports: * TCP/UDP sending and receiving. * Timestamp, window scaling, MSS TCP options. * PAWS. * Slow start and congestion control. * Route table (including startic ARP cache). * Socket-like interface. * IP and ethernet processing code. * complete retransmit algorithm. * fast retransmit support. * support for TCP listen state (only point-to-point mode, i.e. no new data channels are created, when new client is connected, instead state is changed according to protocol (TCP state is changed to ESTABLISHED). * support for the new netchannels interface. Speed/CPU usage graph for the socket code (which uses epoll and send/recv) is attached. With the same 100 Mbit speed, CPU usage for netchanenls and userspace network stack is about 2-3 times smaller than socket one with small packet (128 bytes) sending/receiving. There is very strange behaviour of userspace time() function, which if being used actively results in extremely high kernel load and following functions start to appear on the top of profiles: * get_offset_pmtmr() - 25%, second position, even higher than sysenter_past_esp(). * do_gettimeofday() - 0.6%, 4'th place. * delay_pmtmr() - 0.29%, 11'th place. First place is poll_idle(). Testing system, which runs either netchannel or socket tests runs HT-enabled Xeon: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 7 with 1GB of RAM and e100 network adapter on Linux 2.6.17-rc3. Main (vanilla) system is amd64 with 1GB of RAM and 8169 gigabit adapter on Linux 2.6.18-1.2200.fc5, software is either netcat dumping data into /dev/null or sendfile based server. All sources are available on project's homepages. Thank you. 1. Netchannels subsystem. http://tservice.net.ru/~s0mbre/old/?section=projectsitem=netchannel 2. Userspace network stack. http://tservice.net.ru/~s0mbre/old/?section=projectsitem=unetstack 3. Network allocator. http://tservice.net.ru/~s0mbre/old/?section=projectsitem=nta If you have read upto here, then I want you to know that adverticement is over. Thanks again. -- Evgeniy Polyakov atcp_speed.png Description: PNG image
Re: [PATCH 4/6] net: use bitrev8
Andrew Morton wrote: On Thu, 19 Oct 2006 01:46:47 +0900 Akinobu Mita [EMAIL PROTECTED] wrote: Use bitrev8 for bmac, mace, macmace, macsonic, and skfp drivers. [] === --- work-fault-inject.orig/drivers/net/Kconfig +++ work-fault-inject/drivers/net/Kconfig @@ -2500,6 +2500,7 @@ config DEFXX config SKFP tristate SysKonnect FDDI PCI support depends on FDDI PCI +select BITREVERSE ---help--- Say Y here if you have a SysKonnect FDDI PCI adapter. The following adapters are supported by this driver: [] But select is problematic and I do wonder whether it'd be simpler to just link the thing into vmlinux. Why it's problematic? Maintenance costs of various missing selects? I don't want extra stuff in kernel (vmlinux) if it's not used. /mjt - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Announce] New netchannels implementation. Userspace network stack.
Netchannels implementation.
Patch is against 2.6.17-rc3 tree. If there will be any interest to have
such subsystem in vanila tree I will regenerate patch against
appropriate git tree.
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index f48bef1..7a4a758 100644
--- a/arch/i386/kernel/syscall_table.S
+++ b/arch/i386/kernel/syscall_table.S
@@ -315,3 +315,5 @@ ENTRY(sys_call_table)
.long sys_splice
.long sys_sync_file_range
.long sys_tee /* 315 */
+ .long sys_vmsplice
+ .long sys_netchannel_control
diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S
index 5a92fed..fdfb997 100644
--- a/arch/x86_64/ia32/ia32entry.S
+++ b/arch/x86_64/ia32/ia32entry.S
@@ -696,4 +696,5 @@ #endif
.quad sys_sync_file_range
.quad sys_tee
.quad compat_sys_vmsplice
+ .quad sys_netchannel_control
ia32_syscall_end:
diff --git a/include/asm-i386/unistd.h b/include/asm-i386/unistd.h
index eb4b152..777cd85 100644
--- a/include/asm-i386/unistd.h
+++ b/include/asm-i386/unistd.h
@@ -322,8 +322,9 @@ #define __NR_splice 313
#define __NR_sync_file_range 314
#define __NR_tee 315
#define __NR_vmsplice 316
+#define __NR_netchannel_control317
-#define NR_syscalls 317
+#define NR_syscalls 318
/*
* user-visible error numbers are in the range -1 - -128: see
diff --git a/include/asm-x86_64/unistd.h b/include/asm-x86_64/unistd.h
index feb77cb..4459bad 100644
--- a/include/asm-x86_64/unistd.h
+++ b/include/asm-x86_64/unistd.h
@@ -617,8 +617,10 @@ #define __NR_sync_file_range 277
__SYSCALL(__NR_sync_file_range, sys_sync_file_range)
#define __NR_vmsplice 278
__SYSCALL(__NR_vmsplice, sys_vmsplice)
+#define __NR_netchannel_control279
+__SYSCALL(__NR_netchannel_control, sys_netchannel_control)
-#define __NR_syscall_max __NR_vmsplice
+#define __NR_syscall_max __NR_netchannel_control
#ifndef __NO_STUBS
diff --git a/include/linux/netchannel.h b/include/linux/netchannel.h
new file mode 100644
index 000..23e9f1e
--- /dev/null
+++ b/include/linux/netchannel.h
@@ -0,0 +1,88 @@
+/*
+ * netchannel.h
+ *
+ * 2006 Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __NETCHANNEL_H
+#define __NETCHANNEL_H
+
+#include linux/types.h
+
+enum netchannel_commands {
+ NETCHANNEL_CREATE = 0,
+ NETCHANNEL_RECV,
+ NETCHANNEL_SEND,
+};
+
+enum netchannel_type {
+ NETCHANNEL_COPY_USER = 0,
+ NETCHANNEL_NTA,
+};
+
+struct unetchannel
+{
+ __u32 faddr, laddr; /* foreign/local hashes
*/
+ __u16 fport, lport; /* foreign/local ports
*/
+ __u8proto; /* IP protocol number */
+ __u8copy:3, /* Netchannel type:
copy_to_user, mmap or something */
+ state:5;/* Some initial state */
+ __u8memory_limit_order; /* Memor limit order */
+ __u8init_stat_work; /* Start statistic
dumping */
+};
+
+struct unetchannel_control
+{
+ struct unetchannel unc;
+ __u32 cmd;
+ __u16 len, header_len;
+ __u32 flags;
+ __u32 timeout;
+ int fd;
+};
+
+#ifdef __KERNEL__
+
+struct netchannel
+{
+ struct rb_node netchannel_node;
+ atomic_trefcnt;
+ struct rcu_head rcu_head;
+ struct unetchannel unc;
+ unsigned long hit;
+
+ struct page * (*nc_alloc_page)(unsigned int size);
+ void(*nc_free_page)(struct page *page);
+ int (*nc_recv_data)(struct netchannel *, unsigned
int *timeout, __u16 *len, void __user *arg);
+ int (*nc_send_data)(struct netchannel *, unsigned
int *timeout, __u16 len, __u16 header_len, void __user *arg);
+
+ struct sk_buff_head recv_queue;
+
[IPv6] fib: initialize tb6_lock in common place to give lockdep a key
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6/net/ipv6/ip6_fib.c
===
--- net-2.6.orig/net/ipv6/ip6_fib.c 2006-10-20 12:33:57.0 +0200
+++ net-2.6/net/ipv6/ip6_fib.c 2006-10-20 12:39:13.0 +0200
@@ -169,7 +169,6 @@
static struct fib6_table fib6_main_tbl = {
.tb6_id = RT6_TABLE_MAIN,
- .tb6_lock = RW_LOCK_UNLOCKED,
.tb6_root = {
.leaf = ip6_null_entry,
.fn_flags = RTN_ROOT | RTN_TL_ROOT | RTN_RTINFO,
@@ -187,6 +186,12 @@
{
unsigned int h;
+ /*
+* Initialize table lock at a single place to give lockdep a key,
+* tables aren't visible prior to being linked to the list.
+*/
+ rwlock_init(tb-tb6_lock);
+
h = tb-tb6_id (FIB_TABLE_HASHSZ - 1);
/*
@@ -199,7 +204,6 @@
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
static struct fib6_table fib6_local_tbl = {
.tb6_id = RT6_TABLE_LOCAL,
- .tb6_lock = RW_LOCK_UNLOCKED,
.tb6_root = {
.leaf = ip6_null_entry,
.fn_flags = RTN_ROOT | RTN_TL_ROOT | RTN_RTINFO,
@@ -213,7 +217,6 @@
table = kzalloc(sizeof(*table), GFP_ATOMIC);
if (table != NULL) {
table-tb6_id = id;
- table-tb6_lock = RW_LOCK_UNLOCKED;
table-tb6_root.leaf = ip6_null_entry;
table-tb6_root.fn_flags = RTN_ROOT | RTN_TL_ROOT | RTN_RTINFO;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [NET] reduce sizeof(struct flowi) by 20 bytes
Hi all
As suggested by David, just kill off some unused fields in dnports to reduce
sizef(struct flowi). If they come back, they should be moved to nl_u.dn_u in
order not to enlarge again struct flowi
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
diff --git a/include/net/dn.h b/include/net/dn.h
index 465b783..c39385b 100644
--- a/include/net/dn.h
+++ b/include/net/dn.h
@@ -199,11 +199,13 @@ static inline void dn_sk_ports_copy(stru
{
fl-uli_u.dnports.sport = scp-addrloc;
fl-uli_u.dnports.dport = scp-addrrem;
+#if 0 /* not yet used */
fl-uli_u.dnports.objnum = scp-addr.sdn_objnum;
if (fl-uli_u.dnports.objnum == 0) {
fl-uli_u.dnports.objnamel =
(__u8)dn_ntohs(scp-addr.sdn_objnamel);
memcpy(fl-uli_u.dnports.objname, scp-addr.sdn_objname, 16);
}
+#endif
}
extern unsigned dn_mss_from_pmtu(struct net_device *dev, int mtu);
diff --git a/include/net/flow.h b/include/net/flow.h
index 3b44d72..bdc0e49 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -68,9 +68,11 @@ #define FLOWI_FLAG_MULTIPATHOLDROUTE 0x0
struct {
__le16 sport;
__le16 dport;
+#if 0 /* not yet used, should move to nl_u.dn_u */
__u8objnum;
__u8objnamel; /* Not 16 bits since max val is 16 */
__u8objname[16]; /* Not zero terminated */
+#endif
} dnports;
__be32 spi;
Re: [PATCH] [NET] One NET_INC_STATS() could be NET_INC_STATS_BH in tcp_v4_err()
On 10/20/06, David Miller [EMAIL PROTECTED] wrote: From: Eric Dumazet [EMAIL PROTECTED] Date: Thu, 19 Oct 2006 17:45:26 +0200 I believe this NET_INC_STATS() call can be replaced by NET_INC_STATS_BH(), a little bit cheaper. Signed-off-by: Eric Dumazet [EMAIL PROTECTED] Applied, although I hope tcp_v4_err() never becomes a fast path :-) I'll queue a cset in my net-2.6 tree to do the equivalent for dccp_v4_err() :-) - Arnaldo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] [NET]: RFC-compliant UDP-Lite support (RFC 3828)
[UDP] This is a finalised, polished and tidied up revision of the full UDP-Lite
patch.
It features:
* RFC 3828 - compliant support for UDP-Lite over IPv4 and IPv6
* consolidated and shared generic code between UDP and UDP-Lite
(thanks to the help of Dave Miller)
* separation of files specific to UDP-Lite
* MIB/statistics support in /proc/net/snmp{6} and /proc/net/udplite{6}
* basic netfilter/xfrm support
* API documentation in Documentation/networking/udplite.txt
C h a n g e l o g
-
Although no negative feedback has been received from IPv6-developers, the
integration of UDP-Litev6
has been overhauled, in particular to make the protocol initialisation in
af_inet6.c consistent with
the existing code. The detailed changes:
* added IPV6_ADDRFORM support for UDP-Lite
* updated documentation with regard to most recent changes
* rewrote the UDP-Lite initialisation in af_inet6.c from scratch - it
is now fully
consistent with the existing coding style
* fixed typos
* made the error handling in udpv6_queue_rcv_skb consistent: to return
`-1' on error
(it used to return 0 when either skb_checksum_complete or
sock_queue_rcv_skb failed)
Apart from this, the v6-side technically is not much different from the
v4-side, which has been
under revision/discussion as an RFC patch for a while. The code has been
thoroughly tested.
If there are no further objections or code comments, I propose this for
inclusion in 2.6.20.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
Documentation/networking/udplite.txt | 281281 + 0 - 0 !
include/linux/in.h |11 + 0 - 0 !
include/linux/socket.h |11 + 0 - 0 !
include/linux/udp.h | 1212 +0 - 0 !
include/net/ipv6.h | 129 + 3 - 0 !
include/net/transp_v6.h |22 + 0 - 0 !
include/net/udp.h| 9187 +4 - 0 !
include/net/udplite.h| 149149 + 0 - 0 !
include/net/xfrm.h |22 + 0 - 0 !
net/ipv4/af_inet.c |87 + 1 - 0 !
net/ipv4/netfilter/ipt_LOG.c | 118 + 3 - 0 !
net/ipv4/proc.c | 1313 +0 - 0 !
net/ipv4/udp.c | 481285 + 196 - 0 !
net/ipv4/udplite.c | 118118 + 0 - 0 !
net/ipv4/xfrm4_policy.c |11 + 0 - 0 !
net/ipv6/af_inet6.c | 2120 +1 - 0 !
net/ipv6/ipv6_sockglue.c | 119 + 2 - 0 !
net/ipv6/netfilter/ip6t_LOG.c| 107 + 3 - 0 !
net/ipv6/proc.c | 1111 +0 - 0 !
net/ipv6/udp.c | 330189 + 141 - 0 !
net/ipv6/udplite.c | 103103 + 0 - 0 !
net/ipv6/xfrm6_policy.c |11 + 0 - 0 !
net/netfilter/xt_multiport.c |53 + 2 - 0 !
net/netfilter/xt_tcpudp.c| 2019 +1 - 0 !
24 files changed, 1338 insertions(+), 357 deletions(-)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [IPv6]: UDP-Lite support
[UDPv6]: Support for UDP-Litev6 (RFC 3828).
* consolidated with UDP basis
* basic xfrm/netfilter support
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
include/net/ipv6.h| 12 +
include/net/transp_v6.h |2
net/ipv6/af_inet6.c | 21 ++
net/ipv6/ipv6_sockglue.c | 11 +
net/ipv6/netfilter/ip6t_LOG.c | 10 -
net/ipv6/proc.c | 11 +
net/ipv6/udp.c| 330 --
net/ipv6/udplite.c| 103 +
net/ipv6/xfrm6_policy.c |1
9 files changed, 351 insertions(+), 150 deletions(-)
diff --git a/include/net/transp_v6.h b/include/net/transp_v6.h
index 61f724c..409da3a 100644
--- a/include/net/transp_v6.h
+++ b/include/net/transp_v6.h
@@ -11,6 +11,7 @@ #ifdef __KERNEL__
extern struct proto rawv6_prot;
extern struct proto udpv6_prot;
+extern struct proto udplitev6_prot;
extern struct proto tcpv6_prot;
struct flowi;
@@ -24,6 +25,7 @@ extern void ipv6_destopt_init(void);
/* transport protocols */
extern voidrawv6_init(void);
extern voidudpv6_init(void);
+extern voidudplitev6_init(void);
extern voidtcpv6_init(void);
extern int udpv6_connect(struct sock *sk,
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index e0c3934..6b13ae2 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -49,6 +49,7 @@ #include net/ip6_route.h
#include net/addrconf.h
#include net/ip.h
#include net/udp.h
+#include net/udplite.h
#include net/raw.h
#include net/inet_common.h
#include net/tcp_states.h
@@ -66,23 +67,9 @@ static inline int udp_v6_get_port(struct
return udp_get_port(sk, snum, ipv6_rcv_saddr_equal);
}
-static void udp_v6_hash(struct sock *sk)
-{
- BUG();
-}
-
-static void udp_v6_unhash(struct sock *sk)
-{
- write_lock_bh(udp_hash_lock);
- if (sk_del_node_init(sk)) {
- inet_sk(sk)-num = 0;
- sock_prot_dec_use(sk-sk_prot);
- }
- write_unlock_bh(udp_hash_lock);
-}
-
-static struct sock *udp_v6_lookup(struct in6_addr *saddr, u16 sport,
- struct in6_addr *daddr, u16 dport, int dif)
+static struct sock *__udp6_lib_lookup(struct in6_addr *saddr, __be16 sport,
+ struct in6_addr *daddr, __be16 dport,
+ int dif, struct hlist_head udptable[])
{
struct sock *sk, *result = NULL;
struct hlist_node *node;
@@ -90,7 +77,7 @@ static struct sock *udp_v6_lookup(struct
int badness = -1;
read_lock(udp_hash_lock);
- sk_for_each(sk, node, udp_hash[hnum (UDP_HTABLE_SIZE - 1)]) {
+ sk_for_each(sk, node, udptable[hnum (UDP_HTABLE_SIZE - 1)]) {
struct inet_sock *inet = inet_sk(sk);
if (inet-num == hnum sk-sk_family == PF_INET6) {
@@ -132,15 +119,6 @@ static struct sock *udp_v6_lookup(struct
}
/*
- *
- */
-
-static void udpv6_close(struct sock *sk, long timeout)
-{
- sk_common_release(sk);
-}
-
-/*
* This should be easy, if there is something there we
* return it, otherwise we block.
*/
@@ -153,7 +131,7 @@ static int udpv6_recvmsg(struct kiocb *i
struct inet_sock *inet = inet_sk(sk);
struct sk_buff *skb;
size_t copied;
- int err;
+ int err, copy_only, is_udplite = IS_UDPLITE(sk);
if (addr_len)
*addr_len=sizeof(struct sockaddr_in6);
@@ -172,15 +150,21 @@ try_again:
msg-msg_flags |= MSG_TRUNC;
}
- if (skb-ip_summed==CHECKSUM_UNNECESSARY) {
- err = skb_copy_datagram_iovec(skb, sizeof(struct udphdr),
msg-msg_iov,
- copied);
- } else if (msg-msg_flagsMSG_TRUNC) {
- if (__skb_checksum_complete(skb))
+ /*
+* Decide whether to checksum and/or copy data.
+*/
+ copy_only = (skb-ip_summed==CHECKSUM_UNNECESSARY);
+
+ if (is_udplite || (!copy_onlymsg-msg_flagsMSG_TRUNC)) {
+ if (__udp_lib_checksum_complete(skb))
goto csum_copy_err;
- err = skb_copy_datagram_iovec(skb, sizeof(struct udphdr),
msg-msg_iov,
- copied);
- } else {
+ copy_only = 1;
+ }
+
+ if (copy_only)
+ err = skb_copy_datagram_iovec(skb, sizeof(struct udphdr),
+ msg-msg_iov, copied );
+ else {
err = skb_copy_and_csum_datagram_iovec(skb, sizeof(struct
udphdr), msg-msg_iov);
if (err == -EINVAL)
goto csum_copy_err;
@@ -231,14 +215,15 @@ csum_copy_err:
skb_kill_datagram(sk, skb, flags);
if (flags MSG_DONTWAIT) {
-
Re: watchdog timeout panic in e1000 driver
Kenzo Iwami wrote: Hi, Thank you for your comment. A watchdog timeout panic occurred in e1000 driver (7.2.9-NAPI). where's the panic message ? attached the panic message (e1000_panic). [...] This problem only occurs on a server using ethernet controller inside 631xESB/632xESB, and NMI watchdog enabled. why only this system? have you seen/tried it on other machines? This problem is caused by e1000_get_software_semaphore() being called from within the interrupt handler, while the interrupted code is still holding this semaphore. e1000_get_software_semaphore() is called from e1000_get_hw_eeprom_semaphore() only when hw-mac_type is e1000_80003es2lan. This condition is true only for MACs inside 631xESB/632xESB. When this problem happens e1000_get_software_semaphore() will wait for 16 seconds (inside the interrupt handler) before it fails, thus causing the watchdog timeout. I haven't actually tried it on other machines, but theoretically, it will only happen on MAC inside 631xESB/632xESB chip set. [...] Reverting this could would not be a fix, but only a workaround that leaves the problem still in the code, and as such not progress in the right direction. I find this report extremely edgy, but I'll look into the fact that the driver attempts to sleep for 16384 + 1 msec, which seems overly long :) As a side note, most other e1000 NIC's use hardcoded word_size numbers, but esb2 systems read it from a register/eeprom. Can you send me the output of `ethtool -e ethX` ? off-list is OK, it might be large. attached is the output of ethtool -e ethX (eeprom_eth0). thanks. This panic report falls in the category how hard can I break my system as root. Explicitly abusing the system performing restricted calls depletes resources and harasses the sw lock (in this case). The reason that the driver attempts to wait that long is that in the case of ESB2 systems, the SPI interface to the EEPROM can be slow, thus taking a long time to complete certain commands. We're looking into making this theoretical lock time shorter in the mean time, thanks for reporting this. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
On Fri, 20 Oct 2006 00:15:30 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Thu, 19 Oct 2006 10:15:43 -0700 The original skb management for netpoll was a mess, it had two queue paths and a callback. This changes it to have a per-instance transmit queue and use a tasklet rather than a work queue for the congested case. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] I think you mis-diffed this one: - WARN_ON(skb-protocol == 0); That line doesn't exist in my copy of net/core/netpoll.c even with your first patch applied. Also, you forgot to remove the -drop callback pointer from struct netpoll, which you should do if it really isn't used any more. I think you might run into problems there, as I believe the netdump stuff does make non-trivial use of the -drop callback. Indeed, it uses the -dump callback for invoking a special netpoll_start_netdump() function. I'm pretty sure -dump was created specifically to accomodate netdump. Netdump is not in the tree, so I can't fix it. Also netdump is pretty much superseded by kdump. So this is something else which will need to be worked out before we can apply this patch. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] netpoll: rework skb transmit queue
Change netpoll to use a skb queue for transmit. This solves problems
where there are two tx paths that can cause things to get out of order
and different semantics when netconsole output goes through fast and
slow paths.
The only user of the drop hook was netconsole, and I fixed that path.
This probably breaks netdump, but that is out of tree, so it needs
to fix itself.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/netconsole.c |1
include/linux/netpoll.h |3 +
net/core/netpoll.c | 109 --
3 files changed, 31 insertions(+), 82 deletions(-)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index bf58db2..fad5bf2 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -60,7 +60,6 @@ static struct netpoll np = {
.local_port = 6665,
.remote_port = ,
.remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
- .drop = netpoll_queue,
};
static int configured = 0;
diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h
index 1efe60c..835ca0d 100644
--- a/include/linux/netpoll.h
+++ b/include/linux/netpoll.h
@@ -27,11 +27,12 @@ struct netpoll {
struct netpoll_info {
spinlock_t poll_lock;
int poll_owner;
- int tries;
int rx_flags;
spinlock_t rx_lock;
struct netpoll *rx_np; /* netpoll that registered an rx_hook */
struct sk_buff_head arp_tx; /* list of arp requests to reply to */
+ struct sk_buff_head tx_q;
+ struct tasklet_struct tx_task;
};
void netpoll_poll(struct netpoll *np);
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 9308af0..22332fd 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -40,10 +40,6 @@ static DEFINE_SPINLOCK(skb_list_lock);
static int nr_skbs;
static struct sk_buff *skbs;
-static DEFINE_SPINLOCK(queue_lock);
-static int queue_depth;
-static struct sk_buff *queue_head, *queue_tail;
-
static atomic_t trapped;
#define NETPOLL_RX_ENABLED 1
@@ -56,50 +52,31 @@ #define MAX_SKB_SIZE \
static void zap_completion_queue(void);
static void arp_reply(struct sk_buff *skb);
-static void queue_process(void *p)
+static void netpoll_run(unsigned long arg)
{
- unsigned long flags;
+ struct net_device *dev = (struct net_device *) arg;
+ struct netpoll_info *npinfo = dev-npinfo;
struct sk_buff *skb;
- while (queue_head) {
- spin_lock_irqsave(queue_lock, flags);
-
- skb = queue_head;
- queue_head = skb-next;
- if (skb == queue_tail)
- queue_head = NULL;
-
- queue_depth--;
+ while ((skb = skb_dequeue(npinfo-tx_q))) {
+ if (!netif_running(dev) || !netif_device_present(dev)) {
+ __kfree_skb(skb);
+ continue;
+ }
- spin_unlock_irqrestore(queue_lock, flags);
+ netif_tx_lock(dev);
+ if (netif_queue_stopped(dev) ||
+ dev-hard_start_xmit(skb, dev) != NETDEV_TX_OK) {
+ skb_queue_head(npinfo-tx_q, skb);
+ netif_tx_unlock(dev);
+ tasklet_schedule(npinfo-tx_task);
+ return;
+ }
- dev_queue_xmit(skb);
+ netif_tx_unlock(dev);
}
}
-static DECLARE_WORK(send_queue, queue_process, NULL);
-
-void netpoll_queue(struct sk_buff *skb)
-{
- unsigned long flags;
-
- if (queue_depth == MAX_QUEUE_DEPTH) {
- __kfree_skb(skb);
- return;
- }
-
- spin_lock_irqsave(queue_lock, flags);
- if (!queue_head)
- queue_head = skb;
- else
- queue_tail-next = skb;
- queue_tail = skb;
- queue_depth++;
- spin_unlock_irqrestore(queue_lock, flags);
-
- schedule_work(send_queue);
-}
-
static int checksum_udp(struct sk_buff *skb, struct udphdr *uh,
unsigned short ulen, u32 saddr, u32 daddr)
{
@@ -270,50 +247,17 @@ repeat:
static void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb)
{
- int status;
- struct netpoll_info *npinfo;
-
- if (!np || !np-dev || !netif_running(np-dev)) {
- __kfree_skb(skb);
- return;
- }
+ struct net_device *dev = np-dev;
+ struct netpoll_info *npinfo = dev-npinfo;
- npinfo = np-dev-npinfo;
+ skb_queue_tail(npinfo-tx_q, skb);
/* avoid recursion */
if (npinfo-poll_owner == smp_processor_id() ||
- np-dev-xmit_lock_owner == smp_processor_id()) {
- if (np-drop)
- np-drop(skb);
- else
- __kfree_skb(skb);
+ dev-xmit_lock_owner == smp_processor_id())
return;
- }
- do {
- npinfo-tries--;
-
Re: [PATCH] bcm43xx-softmac: add PCI-E code
Hi Larry, Larry Finger wrote: From: Stefano Brivio [EMAIL PROTECTED] The current bcm43xx driver does not contain code to handle PCI-E interfaces such as the BCM4311 and BCM4312. This patch, originally written by Stefano Brivio adds the necessary code to enable these interfaces. I am testing this on a Compaq VS6120US laptop. This is my first experience with using bcm43xx. I'm connecting to a WPA network. bcm43xx: Chip ID 0x4311, rev 0x1 bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243, disabled bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243, disabled bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243, enabled bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Most of the time, it doesn't work. wpa_supplicant scans, gets scan results, tries to associate, and then things stop there. Sometimes the association completes but the WPA PSK stuff times out, sometimes the WPA PSK stuff completes and it gets an IP, but doesn't get any further. After bringing down the interface, it cannot be brought up again: bcm43xx: Radio turned off bcm43xx: DMA-32 0x0200 (RX) max used slots: 7/64 bcm43xx: DMA-32 0x02A0 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0280 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0260 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0240 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0220 (TX) max used slots: 7/512 bcm43xx: DMA-32 0x0200 (TX) max used slots: 0/512 bcm43xx: ASSERTION FAILED (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED) at: drivers/net/wireless/bcm43xx/bcm43xx_main.c:1852:bcm43xx_interrupt_handler() bcm43xx: IRQ_READY timeout bcm43xx: core_up for active 802.11 core failed (-19) Unloading and reloading the driver allows the interface to come up again. Approximately 1 in 5 times it does get an IP and I can connect to stuff. I realise this report probably isn't all that useful, but this laptop is going to be out of the office for a while, I guess I'll just lend him a ZD1211 if he needs wireless. Daniel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx-softmac: add PCI-E code
On Friday 20 October 2006 17:46, Daniel Drake wrote: Hi Larry, Larry Finger wrote: From: Stefano Brivio [EMAIL PROTECTED] The current bcm43xx driver does not contain code to handle PCI-E interfaces such as the BCM4311 and BCM4312. This patch, originally written by Stefano Brivio adds the necessary code to enable these interfaces. I am testing this on a Compaq VS6120US laptop. This is my first experience with using bcm43xx. I'm connecting to a WPA network. Which kernel are you using exactly? bcm43xx: Chip ID 0x4311, rev 0x1 bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243, disabled Pretty high revision numbers. I think we need additional code to completely support these. ChipCommon (0x800) has some special things at rev 10 bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243, disabled bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243, enabled bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Most of the time, it doesn't work. wpa_supplicant scans, gets scan results, tries to associate, and then things stop there. Sometimes the association completes but the WPA PSK stuff times out, sometimes the WPA PSK stuff completes and it gets an IP, but doesn't get any further. After bringing down the interface, it cannot be brought up again: bcm43xx: Radio turned off bcm43xx: DMA-32 0x0200 (RX) max used slots: 7/64 bcm43xx: DMA-32 0x02A0 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0280 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0260 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0240 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0220 (TX) max used slots: 7/512 bcm43xx: DMA-32 0x0200 (TX) max used slots: 0/512 bcm43xx: ASSERTION FAILED (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED) at: drivers/net/wireless/bcm43xx/bcm43xx_main.c:1852:bcm43xx_interrupt_handler() That one's strange... I'm interrested in seeing a complete dmesg log of this. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx-softmac: add PCI-E code
Michael Buesch wrote: Which kernel are you using exactly? 2.6.19-rc2 bcm43xx: Radio turned off bcm43xx: DMA-32 0x0200 (RX) max used slots: 7/64 bcm43xx: DMA-32 0x02A0 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0280 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0260 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0240 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0220 (TX) max used slots: 7/512 bcm43xx: DMA-32 0x0200 (TX) max used slots: 0/512 bcm43xx: ASSERTION FAILED (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED) at: drivers/net/wireless/bcm43xx/bcm43xx_main.c:1852:bcm43xx_interrupt_handler() That one's strange... I'm interrested in seeing a complete dmesg log of this. On load: bcm43xx driver ACPI: PCI Interrupt Link [LK1E] enabled at IRQ 11 ACPI: PCI Interrupt :03:00.0[A] - Link [LK1E] - GSI 11 (level, low) - IRQ 11 PCI: Setting latency timer of device :03:00.0 to 64 bcm43xx: Chip ID 0x4311, rev 0x1 bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243, disabled bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243, disabled bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243, enabled bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off ifup: bcm43xx: PHY connected bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18 02:36:27) bcm43xx: Radio turned on bcm43xx: Chip initialized bcm43xx: 32-bit DMA initialized bcm43xx: Keys cleared bcm43xx: Selected 802.11 core (phytype 2) ifdown: bcm43xx: Radio turned off bcm43xx: DMA-32 0x0200 (RX) max used slots: 0/64 bcm43xx: DMA-32 0x02A0 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0280 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0260 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0240 (TX) max used slots: 0/512 bcm43xx: DMA-32 0x0220 (TX) max used slots: 42/512 bcm43xx: DMA-32 0x0200 (TX) max used slots: 0/512 ifup now fails: # ifconfig eth1 up SIOCSIFFLAGS: No such device bcm43xx: IRQ_READY timeout bcm43xx: core_up for active 802.11 core failed (-19) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 08:18:57 -0700 Netdump is not in the tree, so I can't fix it. Also netdump is pretty much superseded by kdump. Unless kdump is %100 ready you can be sure vendors will ship netdump for a little while longer. I think gratuitously breaking netdump is not the best idea. It's not like netdump is some binary blob you can't get the source to easily. :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
On Fri, 20 Oct 2006 12:24:27 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 08:18:57 -0700 Netdump is not in the tree, so I can't fix it. Also netdump is pretty much superseded by kdump. Unless kdump is %100 ready you can be sure vendors will ship netdump for a little while longer. I think gratuitously breaking netdump is not the best idea. It's not like netdump is some binary blob you can't get the source to easily. :-) Sorry, but why should we treat out-of-tree vendor code any differently than out-of-tree other code. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 08:40:15 -0700 The only user of the drop hook was netconsole, and I fixed that path. This probably breaks netdump, but that is out of tree, so it needs to fix itself. I believe that netdump needs to requeue things because dropping the packet is simply not allowed, and the -drop callback gives the netdump code a way to handle things without actually dropping the packet. If that's true, you can't just free the SKB on it. Are you sure your new TX strategy can avoid such drops properly? Please take a quick peek at the netdump code, it's available, and make some reasonable effort to determine whether it can still work with your new code. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
On Fri, 20 Oct 2006 12:27:53 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 08:40:15 -0700 The only user of the drop hook was netconsole, and I fixed that path. This probably breaks netdump, but that is out of tree, so it needs to fix itself. I believe that netdump needs to requeue things because dropping the packet is simply not allowed, and the -drop callback gives the netdump code a way to handle things without actually dropping the packet. If that's true, you can't just free the SKB on it. Are you sure your new TX strategy can avoid such drops properly? Yes, it has a queue. if it can't send it waits and retries. Please take a quick peek at the netdump code, it's available, and make some reasonable effort to determine whether it can still work with your new code. Where, I'm not digging in side some RHEL rpm patch pile to find it. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] wrr (weighted round-robin) bonding
On Thursday, 19 October 2006 21:04, Andy Gospodarek wrote: It would seem to me that extending an existing mode would be more desirable than adding yet another mode to worry about. I don't even like the fact that there are as many as there are, but I understand why they are there. Ack. I will probably update wrr bonding patch to replace rr mode. I recently extended rr mode to allow an additional parameter called that rr_repeat that would allow someone to send more than a single frame out of each device before moving to the next one. It seemed this could be helpful when dealing with switches that constantly re-learned source MAC addresses. Network performance would suffer whenever rr_repeat was 1, but box performance might be better if there weren't so many locks taken. Thanks. I'll consider adding such functionality. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Ethernet Cheap Cryptography
On Thursday, 19 October 2006 05:57, Stephen J. Bevan wrote: And if the packets come out of order i.e. you get a packet with a new key followed by a packet with the old key? As IV from invalid frames are saved ccrypt will synchronize anyway, but I was wrong in one aspect - in current implementation each reorder will cost two frames, not one. This could be possibly reduced to only one, but I must find a time to investigate that more. If the keying is done manually an attacker won't know when the keys are changed. However, if keying is coordinated over the same link via a protocol (as is done with IKE for IPsec) then the attacker can see (or at least guess) the packets carrying the keying protcol thus know re-keying is going to occur. Simple random delay should do the trick. For completness there are also switches that :- * take notice of the TOS/DiffServ bits in an IP header and will re-order based on them Looks like a good reason to change frame type field so it does not look like IP packet. * will re-order frames due to redundancy, load-balancing, spanning-tree changes ... etc. In summary - using ccrypt with switches may lead to problems. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] wrr (weighted round-robin) bonding
Dawid Ciezarkiewicz [EMAIL PROTECTED] wrote: On Thursday, 19 October 2006 21:04, Andy Gospodarek wrote: It would seem to me that extending an existing mode would be more desirable than adding yet another mode to worry about. I don't even like the fact that there are as many as there are, but I understand why they are there. Ack. I will probably update wrr bonding patch to replace rr mode. Also, if acceptance into the mainline is your ultimate goal, the ioctl control interface will be a very difficult sell. You'd want to look into some other control mechanism, most likely an additional sysfs entry. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Ethernet Cheap Cryptography
Stephen J. Bevan wrote: Pawel Foremski writes: Secondly, IPsec won't decrease MSS in TCP encapsulated in PPPoE traffic, for example. Various, commercial, IPsec products decrease the MSS for TCP encapsulated in PPPoE. I've not checked the Linux 2.6 IPsec code to see if it does or if it can easily be made to. Consider such an example: our task is to bridge two LANs managed by a third-party ISP over a wireless link, with the highest performance possible for such medium. The ISP has its clients on one LAN and a PPPoE concentrator on the second one. Because the ISP doesn't trust us or is not aware of our bridge, it uses MPPE to secure PPP. We cannot enforce any changes to the way the ISP provides services to its end users. In ASCII art, that would be: [PPPoE server]---[Linux#1]--ccrypt--[dumb WiFi bridge] ))) \/ || [PPPoE client]---[Linux#2]--ccrypt--[dumb WiFi bridge] ((( =/ Obviously, the dumb WiFi bridge cannot speak anything other than 1500-byte, plain (not encrypted) Ethernet. IMHO it's quite probable to come up with another example. Only if the rekeying traffic is the only being transmitted. IMHO a border case. Unless you mask the size of your (re-)keying traffic by randomly padding the packets then they can be detected even in the middle of other traffic. Yeah, you're right, forgot about padding. Sure, but that's IMHO little bit off-topic in regard to ccrypt, which is just an encryption back-end (eventually the rekeying daemon will sit in the userspace). Sure. However, there has to be a user-kernel API and the question is whether what you have now is sufficient when a daemon is added or whether it will need to change? If it does need to change it will need to be backwards compatible or need to be a separate API? Ah, so you were asking about API. Then, Dawid should probably answer that question as he's implemented the whole ccrypt. The sysfs API may not always be available for userspace tools, good point. Also at least for IPsec, the kernel knows something about IKE in that generally IKE traffic is not encrypted by IPsec. Instead IKE has its own encryption which it bootstraps using shared-secrets/certificates/publicpreivate key pairs. In the case of ccrypt either the ccryptKE protocol would need to bypass ccrypt or you need to way to start off with known keys, but not the same keys every time or that can be exploited. I think in case of ccrypt it could be administrators task to ensure that the ccrypt key exchange traffic won't be encrypted by it. Dawid mentioned using vlans or macvlans, but I guess it wouldn't be much complicated to add another possibilities in future, if required. P.S. Please excuse me not CCing this post to all interested people, but temporarily I'm using gmane gateway through knode (real pain ... ;-) -- Pawel Foremski [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] wrr (weighted round-robin) bonding
On Friday, 20 October 2006 21:53, Jay Vosburgh wrote: Dawid Ciezarkiewicz [EMAIL PROTECTED] wrote: On Thursday, 19 October 2006 21:04, Andy Gospodarek wrote: It would seem to me that extending an existing mode would be more desirable than adding yet another mode to worry about. I don't even like the fact that there are as many as there are, but I understand why they are there. Ack. I will probably update wrr bonding patch to replace rr mode. Also, if acceptance into the mainline is your ultimate goal, the ioctl control interface will be a very difficult sell. You'd want to look into some other control mechanism, most likely an additional sysfs entry. Oh. I'm quite puzzled here. What is current policy? I'd like sysfs interfaces better than ioctl - they are much cleaner etc. - but I thought ioctl will be better here because current bonding control uses ioctl and extending it is much simpler. More generally: should I use sysfs always when adding anything to kernel and use it even when extending older functionality? If wrr bonding have chances for inclusion into mainline I'll do any necessary changes to let it meet requirements. I'd like to know if functionality from Andy's patch is desired to be a part of such round-robin bonding extension. I think I could easily integrate it with wrr. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] wrr (weighted round-robin) bonding
On Fri, Oct 20, 2006 at 10:52:00PM +0200, Dawid Ciezarkiewicz wrote: Oh. I'm quite puzzled here. What is current policy? I'd like sysfs interfaces better than ioctl - they are much cleaner etc. - but I thought ioctl will be better here because current bonding control uses ioctl and extending it is much simpler. I can't tell you for sure if there is a 'policy' about this, but I would encourage you to focus energy on sysfs rather than the ioctl interface. In the future I would guess more will begin to use sysfs rather than ifenslave. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes
On Oct 3, 2006, at 10:18, Maciej W. Rozycki wrote:
Hello,
This patch fixes a couple of problems discovered with interrupt
handling
in the phylib core, namely:
1. The driver uses timer and workqueue calls, but does not include
linux/timer.h nor linux/workqueue.h.
Good catch.
2. The driver uses schedule_work() for handling interrupts, but
does not
make sure any pending work scheduled thus has been completed before
driver's structures get freed from memory. This is especially
important as interrupts may keep arriving if the line is shared
with
another PHY.
The solution is to ignore phy_interrupt() calls if the reported
device
has already been halted and calling flush_scheduled_work() from
phy_stop_interrupts() (but guarded with current_is_keventd() in
case
the function has been called through keventd from the MAC device's
close call to avoid a deadlock on the netlink lock).
I've been trying to figure out this problem since you posted this,
and I'm not sure I understand it fully (And I apologize profusely for
the horror that is the PHY interrupt handling code. I'd love to
rewrite it if there's some cleaner way.). But let me see if I can
follow the chain of reasoning that led to this patch, and see if we
can figure out a solution that doesn't involve creating a work queue
just for bringing down the PHY.
1) Invoking phy_stop is meant to stop the system from looking for PHY
status updates. Currently, another PHY sharing the interrupt can
cause the HALTED PHY to reenable interrupts. Checking for HALTED in
the interrupt handler fixes this, but it's incorrect. The
phy_interrupt handler does not grab the lock, and so you could get this:
phy_stop
lock
clear any pending interrupts
disable interrupts on this PHY
--- interrupt from another PHY causes this PHY's interrupt handler
to be invoked
HALTED isn't set, so phy_change is scheduled
--- set HALTED, unlock
scheduled work is done:
interrupt is reenabled
Sadly, I think the only way to fix this problem is to have phy_change
check for HALTED, and react appropriately.
2) The PHY lib doesn't clear out remaining work in the work queue
when it's bringing down a PHY. This is clearly wrong, but I'm
confused how *any* driver does this? It seems to me that any network
driver which has a work queue is going to be unable to flush the
pending work when it is brought down. So what's the solution to this?
I'm not too enthusiastic about requiring the ethernet drivers to call
phy_disconnect in a separate thread after close is called.
Assuming there's not some sort of squash work queue function that
can be invoked with rtnl_lock held, I think phy_disconnect should
schedule itself to flush the queue. This would also require that
mdiobus_unregister hold off on freeing phydevs if any of the phys
were still waiting for pending flush_pending calls to finish. Which
would, in turn, require mdiobus_unregister to schedule cleaning up
memory for some later time.
I'm not enthusiastic about that implementation, either, but it
maintains the abstractions I consider important for this code. The
ethernet driver should not need to know what structures the PHY lib
uses to implement its interrupt handling, and how to work around
their failings, IMHO.
And now, to be more specific, a few comments on the patch, directly:
Please consider.
Maciej
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
patch-mips-2.6.18-20060920-phy-irq-16
diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/
drivers/net/phy/phy.c linux-mips-2.6.18-20060920/drivers/net/phy/phy.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/phy.c
2006-08-05 04:58:46.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/phy.c 2006-10-03
14:19:21.0 +
@@ -7,6 +7,7 @@
* Author: Andy Fleming
*
* Copyright (c) 2004 Freescale Semiconductor, Inc.
+ * Copyright (c) 2006 Maciej W. Rozycki
*
* This program is free software; you can redistribute it and/or
modify it
* under the terms of the GNU General Public License as
published by the
@@ -32,6 +33,8 @@
#include linux/mii.h
#include linux/ethtool.h
#include linux/phy.h
+#include linux/timer.h
+#include linux/workqueue.h
#include asm/io.h
#include asm/irq.h
@@ -484,6 +487,9 @@ static irqreturn_t phy_interrupt(int irq
{
struct phy_device *phydev = phy_dat;
+ if (PHY_HALTED == phydev-state)
+ return IRQ_NONE;/* It can't be ours. */
+
As I mentioned, this doesn't protect it, since it doesn't grab the
lock. And it can't grab the lock, or we'd have to disable interrupts
while doing phy transactions. And we can't do that, because one
design goal is to allow some bus drivers to use interrupts to signal
that the transaction has completed. Admittedly, this is still quite
broken right now. I'm
[patch 7/9] com20020 build fix
From: Randy Dunlap [EMAIL PROTECTED]
com20020.c needs to export functions if either of the ISA or PCI modules
are built as loadable modules. Or they could always be exported.
WARNING: com20020_found [drivers/net/arcnet/com20020-pci.ko] undefined!
WARNING: com20020_check [drivers/net/arcnet/com20020-pci.ko] undefined!
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
Cc: Toralf Forster [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/arcnet/com20020.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff -puN drivers/net/arcnet/com20020.c~com20020-build-fix
drivers/net/arcnet/com20020.c
--- a/drivers/net/arcnet/com20020.c~com20020-build-fix
+++ a/drivers/net/arcnet/com20020.c
@@ -337,13 +337,16 @@ static void com20020_set_mc_list(struct
}
}
-#ifdef MODULE
-
+#if defined(CONFIG_ARCNET_COM20020_PCI_MODULE) || \
+defined(CONFIG_ARCNET_COM20020_ISA_MODULE)
EXPORT_SYMBOL(com20020_check);
EXPORT_SYMBOL(com20020_found);
+#endif
MODULE_LICENSE(GPL);
+#ifdef MODULE
+
int init_module(void)
{
BUGLVL(D_NORMAL) printk(VERSION);
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 8/8] e1000: Reset all functions after a PCI error
From: Linas Vepstas [EMAIL PROTECTED] During the handling of the PCI error recovery sequence, the current e1000 driver erroneously blocks a device reset for any but the first PCI function. It shouldn't -- this is a cut-n-paste error from a different driver (which tolerated only one hardware reset per hardware card). Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Cc: Jesse Brandeburg [EMAIL PROTECTED] Acked-by: Auke Kok [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c |4 1 files changed, 4 deletions(-) diff -puN drivers/net/e1000/e1000_main.c~e1000-reset-all-functions-after-a-pci-error drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c~e1000-reset-all-functions-after-a-pci-error +++ a/drivers/net/e1000/e1000_main.c @@ -4914,10 +4914,6 @@ static pci_ers_result_t e1000_io_slot_re pci_enable_wake(pdev, PCI_D3hot, 0); pci_enable_wake(pdev, PCI_D3cold, 0); - /* Perform card reset only on one instance of the card */ - if (PCI_FUNC (pdev-devfn) != 0) - return PCI_ERS_RESULT_RECOVERED; - e1000_reset(adapter); E1000_WRITE_REG(adapter-hw, WUS, ~0); _ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/8] sundance: remove TxStartThresh and RxEarlyThresh
From: Jesse Huang [EMAIL PROTECTED]
For patent issue need to remove TxStartThresh and RxEarlyThresh. This patent
is cut-through patent. If use this function, Tx will start to transmit after
few data be move in to Tx FIFO. We are not allow to use those function in
DFE530/DFE550/DFE580/DL10050/IP100/IP100A. It will decrease a little
performance.
Signed-off-by: Jesse Huang [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/sundance.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff -puN
drivers/net/sundance.c~sundance-remove-txstartthresh-and-rxearlythresh
drivers/net/sundance.c
--- a/drivers/net/sundance.c~sundance-remove-txstartthresh-and-rxearlythresh
+++ a/drivers/net/sundance.c
@@ -264,8 +264,6 @@ enum alta_offsets {
ASICCtrl = 0x30,
EEData = 0x34,
EECtrl = 0x36,
- TxStartThresh = 0x3c,
- RxEarlyThresh = 0x3e,
FlashAddr = 0x40,
FlashData = 0x44,
TxStatus = 0x46,
@@ -,6 +1109,7 @@ static irqreturn_t intr_handler(int irq,
int tx_cnt;
int tx_status;
int handled = 0;
+ int i;
do {
@@ -1153,17 +1152,14 @@ static irqreturn_t intr_handler(int irq,
np-stats.tx_fifo_errors++;
if (tx_status 0x02)
np-stats.tx_window_errors++;
+
/*
** This reset has been verified on
** DFE-580TX boards ! [EMAIL PROTECTED]
*/
if (tx_status 0x10) { /* TxUnderrun */
- unsigned short txthreshold;
-
- txthreshold = ioread16 (ioaddr
+ TxStartThresh);
/* Restart Tx FIFO and
transmitter */
sundance_reset(dev,
(NetworkReset|FIFOReset|TxReset) 16);
- iowrite16 (txthreshold, ioaddr
+ TxStartThresh);
/* No need to reset the Tx
pointer here */
}
/* Restart the Tx. */
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 4/9] atm/firestream: handle thrown error
From: Jeff Garzik [EMAIL PROTECTED]
gcc emits the following warning:
drivers/atm/firestream.c: In function âfs_openâ:
drivers/atm/firestream.c:870: warning: âtmc0â may be used uninitialized in
this function
This indicates a real bug. We should check make_rate() return value for
potential errors.
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
Cc: chas williams [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/atm/firestream.c |4
1 files changed, 4 insertions(+)
diff -puN drivers/atm/firestream.c~atm-firestream-handle-thrown-error
drivers/atm/firestream.c
--- a/drivers/atm/firestream.c~atm-firestream-handle-thrown-error
+++ a/drivers/atm/firestream.c
@@ -1002,6 +1002,10 @@ static int fs_open(struct atm_vcc *atm_v
r = ROUND_UP;
}
error = make_rate (pcr, r, tmc0, NULL);
+ if (error) {
+ kfree(tc);
+ return error;
+ }
}
fs_dprintk (FS_DEBUG_OPEN, pcr = %d.\n, pcr);
}
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 4/8] subdance: fix TX Pause bug (reset_tx, intr_handler)
From: Jesse Huang [EMAIL PROTECTED]
Fix TX Pause bug (reset_tx, intr_handler). When MaxCollisions occurred, need
to re-enable Tx. But just after re-enable, MaxCollisions maybe occurred again
and with TxStatusOverflow. This will cause driver can't check new
MaxCollisions to re-enable Tx again, because TxStatusOverflow. For this
reason, after re-enable Tx, we need to make sure Tx was actually enabled.
Signed-off-by: Jesse Huang [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/sundance.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff -puN
drivers/net/sundance.c~sundance-fix-tx-pause-bug-reset_tx-intr_handler
drivers/net/sundance.c
--- a/drivers/net/sundance.c~sundance-fix-tx-pause-bug-reset_tx-intr_handler
+++ a/drivers/net/sundance.c
@@ -1079,6 +1079,8 @@ reset_tx (struct net_device *dev)
/* free all tx skbuff */
for (i = 0; i TX_RING_SIZE; i++) {
+ np-tx_ring[i].next_desc = 0;
+
skb = np-tx_skbuff[i];
if (skb) {
pci_unmap_single(np-pci_dev,
@@ -1094,6 +1096,10 @@ reset_tx (struct net_device *dev)
}
np-cur_tx = np-dirty_tx = 0;
np-cur_task = 0;
+
+ np-last_tx = 0;
+ iowrite8(127, ioaddr + TxDMAPollPeriod);
+
iowrite16 (StatsEnable | RxEnable | TxEnable, ioaddr + MACCtrl1);
return 0;
}
@@ -1162,8 +1168,14 @@ static irqreturn_t intr_handler(int irq,
sundance_reset(dev,
(NetworkReset|FIFOReset|TxReset) 16);
/* No need to reset the Tx
pointer here */
}
- /* Restart the Tx. */
- iowrite16 (TxEnable, ioaddr + MACCtrl1);
+ /* Restart the Tx. Need to make sure tx
enabled */
+ i = 10;
+ do {
+ iowrite16(ioread16(ioaddr +
MACCtrl1) | TxEnable, ioaddr + MACCtrl1);
+ if (ioread16(ioaddr + MACCtrl1)
TxEnabled)
+ break;
+ mdelay(1);
+ } while (--i);
}
/* Yup, this is a documentation bug. It cost
me *hours*. */
iowrite16 (0, ioaddr + TxStatus);
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/8] 8139too: force media setting cleanup
From: Bernard Lee [EMAIL PROTECTED]
Setting bit 4 5 alone in 8139too module media option does not really
force 100Mbps full-duplex mode. When media option bit 0-3 is cleared,
8139too module does not force media setting. Therefore, bit 0-3 requires
to be set for bit 4 5 to take effect. The hidden bit 0-3 setting is not
stated in module description.
It can be fixed by changing rtl8139_private structure default_port bitfield
from 4-bit to 6-bit.
Besides, module media bit 9 is a duplicate of bit 4 (full-duplex). It is
suggested that bit 9 is freed. A remark is added to module description
that bit 0 can be used to force setting. It helps to clarify 10Mbps
half-duplex mode.
Signed-off-by: Bernard Lee [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/8139too.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff -puN drivers/net/8139too.c~8139too-force-media-setting-fix
drivers/net/8139too.c
--- a/drivers/net/8139too.c~8139too-force-media-setting-fix
+++ a/drivers/net/8139too.c
@@ -586,7 +586,7 @@ struct rtl8139_private {
signed char phys[4];/* MII device addresses. */
char twistie, twist_row, twist_col; /* Twister tune state. */
unsigned int watchdog_fired : 1;
- unsigned int default_port : 4; /* Last dev-if_port value. */
+ unsigned int default_port : 6; /* Last dev-if_port value. */
unsigned int have_thread : 1;
spinlock_t lock;
spinlock_t rx_lock;
@@ -612,7 +612,7 @@ module_param_array(full_duplex, int, NUL
module_param(debug, int, 0);
MODULE_PARM_DESC (debug, 8139too bitmapped message enable number);
MODULE_PARM_DESC (multicast_filter_limit, 8139too maximum number of filtered
multicast addresses);
-MODULE_PARM_DESC (media, 8139too: Bits 4+9: force full duplex, bit 5:
100Mbps);
+MODULE_PARM_DESC (media, 8139too: bit 0: force setting, bit 4: full duplex,
bit 5: 100Mbps);
MODULE_PARM_DESC (full_duplex, 8139too: Force full duplex for board(s) (1));
static int read_eeprom (void __iomem *ioaddr, int location, int addr_len);
@@ -1068,8 +1068,8 @@ static int __devinit rtl8139_init_one (s
/* The lower four bits are the media type. */
option = (board_idx = MAX_UNITS) ? 0 : media[board_idx];
if (option 0) {
- tp-mii.full_duplex = (option 0x210) ? 1 : 0;
- tp-default_port = option 0xFF;
+ tp-mii.full_duplex = (option 0x10) ? 1 : 0;
+ tp-default_port = option 0x3F;
if (tp-default_port)
tp-mii.force_media = 1;
}
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 8/9] nicstar: Fix a bogus casting warning
From: Alan Cox [EMAIL PROTECTED]
Not enough to make Nicstar 64bit friendly but got squashed in passing so might
as well be applied
Signed-off-by: Alan Cox [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/atm/nicstar.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/atm/nicstar.c~nicstar-fix-a-bogus-casting-warning
drivers/atm/nicstar.c
--- a/drivers/atm/nicstar.c~nicstar-fix-a-bogus-casting-warning
+++ a/drivers/atm/nicstar.c
@@ -2759,7 +2759,7 @@ static int ns_ioctl(struct atm_dev *dev,
{
ns_dev *card;
pool_levels pl;
- int btype;
+ long btype;
unsigned long flags;
card = dev-dev_data;
@@ -2859,7 +2859,7 @@ static int ns_ioctl(struct atm_dev *dev,
case NS_ADJBUFLEV:
if (!capable(CAP_NET_ADMIN))
return -EPERM;
- btype = (int) arg;/* an int is the same size as a pointer */
+ btype = (long) arg; /* a long is the same size as a pointer or
bigger */
switch (btype)
{
case NS_BUFTYPE_SMALL:
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 5/9] WAN/pc300: handle, propagate minor errors
From: Jeff Garzik [EMAIL PROTECTED]
- move definition of 'tmc' and 'br' locals closer to usage
- handle clock_rate_calc() error
- propagate errors back to upper level open routine
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
Cc: Krzysztof Halasa [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/wan/pc300_drv.c | 24 +++-
1 files changed, 19 insertions(+), 5 deletions(-)
diff -puN drivers/net/wan/pc300_drv.c~wan-pc300-handle-propagate-minor-errors
drivers/net/wan/pc300_drv.c
--- a/drivers/net/wan/pc300_drv.c~wan-pc300-handle-propagate-minor-errors
+++ a/drivers/net/wan/pc300_drv.c
@@ -2867,7 +2867,6 @@ static int ch_config(pc300dev_t * d)
uclong clktype = chan-conf.phys_settings.clock_type;
ucshort encoding = chan-conf.proto_settings.encoding;
ucshort parity = chan-conf.proto_settings.parity;
- int tmc, br;
ucchar md0, md2;
/* Reset the channel */
@@ -2940,8 +2939,12 @@ static int ch_config(pc300dev_t * d)
case PC300_RSV:
case PC300_X21:
if (clktype == CLOCK_INT || clktype == CLOCK_TXINT) {
+ int tmc, br;
+
/* Calculate the clkrate parameters */
tmc = clock_rate_calc(clkrate, card-hw.clock,
br);
+ if (tmc 0)
+ return -EIO;
cpc_writeb(scabase + M_REG(TMCT, ch), tmc);
cpc_writeb(scabase + M_REG(TXS, ch),
(TXS_DTRXC | TXS_IBRG | br));
@@ -3097,14 +3100,16 @@ static int cpc_attach(struct net_device
return 0;
}
-static void cpc_opench(pc300dev_t * d)
+static int cpc_opench(pc300dev_t * d)
{
pc300ch_t *chan = (pc300ch_t *) d-chan;
pc300_t *card = (pc300_t *) chan-card;
- int ch = chan-channel;
+ int ch = chan-channel, rc;
void __iomem *scabase = card-hw.scabase;
- ch_config(d);
+ rc = ch_config(d);
+ if (rc)
+ return rc;
rx_config(d);
@@ -3113,6 +3118,8 @@ static void cpc_opench(pc300dev_t * d)
/* Assert RTS and DTR */
cpc_writeb(scabase + M_REG(CTL, ch),
cpc_readb(scabase + M_REG(CTL, ch)) ~(CTL_RTS | CTL_DTR));
+
+ return 0;
}
static void cpc_closech(pc300dev_t * d)
@@ -3168,9 +3175,16 @@ int cpc_open(struct net_device *dev)
}
sprintf(ifr.ifr_name, %s, dev-name);
- cpc_opench(d);
+ result = cpc_opench(d);
+ if (result)
+ goto err_out;
+
netif_start_queue(dev);
return 0;
+
+err_out:
+ hdlc_close(dev);
+ return result;
}
static int cpc_close(struct net_device *dev)
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/8] Update smc91x driver with ARM Versatile board info
From: Deepak Saxena [EMAIL PROTECTED] We need to specify a Versatile-specific SMC_IRQ_FLAGS value or the new generic IRQ layer will complain thusly: No IRQF_TRIGGER set_type function for IRQ 25 (NULL) Signed-off-by: Deepak Saxena [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Cc: Russell King [EMAIL PROTECTED] Cc: Nicolas Pitre [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/smc91x.h | 18 ++ 1 files changed, 18 insertions(+) diff -puN drivers/net/smc91x.h~update-smc91x-driver-with-arm-versatile-board-info drivers/net/smc91x.h --- a/drivers/net/smc91x.h~update-smc91x-driver-with-arm-versatile-board-info +++ a/drivers/net/smc91x.h @@ -416,6 +416,24 @@ static inline void LPD7_SMC_outsw (unsig #define SMC_IRQ_FLAGS (0) +#elif defined(CONFIG_ARCH_VERSATILE) + +#define SMC_CAN_USE_8BIT 1 +#define SMC_CAN_USE_16BIT 1 +#define SMC_CAN_USE_32BIT 1 +#define SMC_NOWAIT 1 + +#define SMC_inb(a, r) readb((a) + (r)) +#define SMC_inw(a, r) readw((a) + (r)) +#define SMC_inl(a, r) readl((a) + (r)) +#define SMC_outb(v, a, r) writeb(v, (a) + (r)) +#define SMC_outw(v, a, r) writew(v, (a) + (r)) +#define SMC_outl(v, a, r) writel(v, (a) + (r)) +#define SMC_insl(a, r, p, l) readsl((a) + (r), p, l) +#define SMC_outsl(a, r, p, l) writesl((a) + (r), p, l) + +#define SMC_IRQ_FLAGS (0) + #else #define SMC_CAN_USE_8BIT 1 _ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 6/9] NET/atm: handle sysfs errors
From: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
net/atm/atm_sysfs.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff -puN net/atm/atm_sysfs.c~net-atm-handle-sysfs-errors net/atm/atm_sysfs.c
--- a/net/atm/atm_sysfs.c~net-atm-handle-sysfs-errors
+++ a/net/atm/atm_sysfs.c
@@ -141,7 +141,7 @@ static struct class atm_class = {
int atm_register_sysfs(struct atm_dev *adev)
{
struct class_device *cdev = adev-class_dev;
- int i, err;
+ int i, j, err;
cdev-class = atm_class;
class_set_devdata(cdev, adev);
@@ -151,10 +151,19 @@ int atm_register_sysfs(struct atm_dev *a
if (err 0)
return err;
- for (i = 0; atm_attrs[i]; i++)
- class_device_create_file(cdev, atm_attrs[i]);
+ for (i = 0; atm_attrs[i]; i++) {
+ err = class_device_create_file(cdev, atm_attrs[i]);
+ if (err)
+ goto err_out;
+ }
return 0;
+
+err_out:
+ for (j = 0; j i; j++)
+ class_device_remove_file(cdev, atm_attrs[j]);
+ class_device_del(cdev);
+ return err;
}
void atm_unregister_sysfs(struct atm_dev *adev)
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 6/8] subdance: correct initial and close hardware step.
From: Jesse Huang [EMAIL PROTECTED]
Correct initial and close hardware step. In some embedded system down and up
IP100A will cause DMA crash. We add some for safe down and up IP100A.
Signed-off-by: Jesse Huang [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/sundance.c |8
1 files changed, 8 insertions(+)
diff -puN
drivers/net/sundance.c~sundance-correct-initial-and-close-hardware-step
drivers/net/sundance.c
--- a/drivers/net/sundance.c~sundance-correct-initial-and-close-hardware-step
+++ a/drivers/net/sundance.c
@@ -789,6 +789,7 @@ static int netdev_open(struct net_device
{
struct netdev_private *np = netdev_priv(dev);
void __iomem *ioaddr = np-base;
+ unsigned long flags;
int i;
/* Do we need to reset the chip??? */
@@ -833,6 +834,10 @@ static int netdev_open(struct net_device
iowrite8(0x01, ioaddr + DebugCtrl1);
netif_start_queue(dev);
+ spin_lock_irqsave(np-lock, flags);
+ reset_tx(dev);
+ spin_unlock_irqrestore(np-lock, flags);
+
iowrite16 (StatsEnable | RxEnable | TxEnable, ioaddr + MACCtrl1);
if (netif_msg_ifup(np))
@@ -1652,6 +1657,9 @@ static int netdev_close(struct net_devic
/* Disable interrupts by clearing the interrupt mask. */
iowrite16(0x, ioaddr + IntrEnable);
+ /* Disable Rx and Tx DMA for safely release resource */
+ iowrite32(0x500, ioaddr + DMACtrl);
+
/* Stop the chip's Tx and Rx processes. */
iowrite16(TxDisable | RxDisable | StatsDisable, ioaddr + MACCtrl1);
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 9/9] iPhase: 64bit cleanup
From: Alan Cox [EMAIL PROTECTED]
Signed-off-by: Alan Cox [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/atm/Kconfig |2 +-
drivers/atm/iphase.c | 23 ++-
2 files changed, 11 insertions(+), 14 deletions(-)
diff -puN drivers/atm/Kconfig~resend-iphase-64bit-cleanup drivers/atm/Kconfig
--- a/drivers/atm/Kconfig~resend-iphase-64bit-cleanup
+++ a/drivers/atm/Kconfig
@@ -289,7 +289,7 @@ config ATM_HORIZON_DEBUG
config ATM_IA
tristate Interphase ATM PCI x575/x525/x531
- depends on PCI ATM !64BIT
+ depends on PCI ATM
---help---
This is a driver for the Interphase (i)ChipSAR adapter cards
which include a variety of variants in term of the size of the
diff -puN drivers/atm/iphase.c~resend-iphase-64bit-cleanup drivers/atm/iphase.c
--- a/drivers/atm/iphase.c~resend-iphase-64bit-cleanup
+++ a/drivers/atm/iphase.c
@@ -93,10 +93,6 @@ module_param(IADebugFlag, uint, 0644);
MODULE_LICENSE(GPL);
-#if BITS_PER_LONG != 32
-# error FIXME: this driver only works on 32-bit platforms
-#endif
-
/ IA_LIB **/
static void ia_init_rtn_q (IARTN_Q *que)
@@ -1408,7 +1404,6 @@ static int rx_init(struct atm_dev *dev)
struct abr_vc_table *abr_vc_table;
u16 *vc_table;
u16 *reass_table;
-u16 *ptr16;
int i,j, vcsize_sel;
u_short freeq_st_adr;
u_short *freeq_start;
@@ -1423,14 +1418,15 @@ static int rx_init(struct atm_dev *dev)
printk(KERN_ERR DEV_LABEL can't allocate DLEs\n);
goto err_out;
}
- iadev-rx_dle_q.start = (struct dle*)dle_addr;
+ iadev-rx_dle_q.start = (struct dle *)dle_addr;
iadev-rx_dle_q.read = iadev-rx_dle_q.start;
iadev-rx_dle_q.write = iadev-rx_dle_q.start;
- iadev-rx_dle_q.end = (struct dle*)((u32)dle_addr+sizeof(struct
dle)*DLE_ENTRIES);
+ iadev-rx_dle_q.end = (struct dle*)((unsigned
long)dle_addr+sizeof(struct dle)*DLE_ENTRIES);
/* the end of the dle q points to the entry after the last
DLE that can be used. */
/* write the upper 20 bits of the start address to rx list address
register */
+ /* We know this is 32bit bus addressed so the following is safe */
writel(iadev-rx_dle_dma 0xf000,
iadev-dma + IPHASE5575_RX_LIST_ADDR);
IF_INIT(printk(Tx Dle list addr: 0x%08x value: 0x%0x\n,
@@ -1584,11 +1580,12 @@ static int rx_init(struct atm_dev *dev)
Set Packet Aging Interval count register to overflow in about 4 us
*/
writew(0xF6F8, iadev-reass_reg+PKT_TM_CNT );
-ptr16 = (u16*)j;
-i = ((u32)ptr16 6) 0xff;
- ptr16 += j - 1;
- i |=(((u32)ptr16 2) 0xff00);
+
+i = (j 6) 0xFF;
+j += 2 * (j - 1);
+i |= ((j 2) 0xFF00);
writew(i, iadev-reass_reg+TMOUT_RANGE);
+
/* initiate the desc_tble */
for(i=0; iiadev-num_tx_desc;i++)
iadev-desc_tbl[i].timestamp = 0;
@@ -1911,7 +1908,7 @@ static int tx_init(struct atm_dev *dev)
iadev-tx_dle_q.start = (struct dle*)dle_addr;
iadev-tx_dle_q.read = iadev-tx_dle_q.start;
iadev-tx_dle_q.write = iadev-tx_dle_q.start;
- iadev-tx_dle_q.end = (struct dle*)((u32)dle_addr+sizeof(struct
dle)*DLE_ENTRIES);
+ iadev-tx_dle_q.end = (struct dle*)((unsigned
long)dle_addr+sizeof(struct dle)*DLE_ENTRIES);
/* write the upper 20 bits of the start address to tx list address
register */
writel(iadev-tx_dle_dma 0xf000,
@@ -2913,7 +2910,7 @@ static int ia_pkt_tx (struct atm_vcc *vc
dev_kfree_skb_any(skb);
return 0;
}
-if ((u32)skb-data 3) {
+if ((unsigned long)skb-data 3) {
printk(Misaligned SKB\n);
if (vcc-pop)
vcc-pop(vcc, skb);
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/9] bonding: lockdep annotation
From: Peter Zijlstra [EMAIL PROTECTED]
=
[ INFO: possible recursive locking detected ]
2.6.17-1.2600.fc6 #1
-
ifconfig/2411 is trying to acquire lock:
(dev-_xmit_lock){-...}, at: [80429b9f] dev_mc_add+0x45/0x15f
but task is already holding lock:
(dev-_xmit_lock){-...}, at: [80429b9f] dev_mc_add+0x45/0x15f
other info that might help us debug this:
3 locks held by ifconfig/2411:
#0: (rtnl_mutex){--..}, at: [802664af] mutex_lock+0x2a/0x2e
#1: (dev-_xmit_lock){-...}, at: [80429b9f] dev_mc_add+0x45/0x15f
#2: (bond-lock){-.-+}, at: [8831b7f7]
bond_set_multicast_list+0x2c/0x26a [bonding]
stack backtrace:
Call Trace:
[8026e97d] show_trace+0xae/0x319
[8026ebfd] dump_stack+0x15/0x17
[802a839b] __lock_acquire+0x135/0xa64
[802a926d] lock_acquire+0x4b/0x69
[80267981] _spin_lock_bh+0x2a/0x36
[80429b9f] dev_mc_add+0x45/0x15f
[8831b903] :bonding:bond_set_multicast_list+0x138/0x26a
[80429901] __dev_mc_upload+0x22/0x24
[80429c74] dev_mc_add+0x11a/0x15f
[8045d154] igmp_group_added+0x55/0x10f
[8045d4ab] ip_mc_inc_group+0x1d6/0x21a
[8045d535] ip_mc_up+0x46/0x61
[804594b8] inetdev_init+0x11c/0x136
[8045a0b7] devinet_ioctl+0x3eb/0x5e9
[8045a56c] inet_ioctl+0x71/0x8f
[8041ed74] sock_ioctl+0x1e8/0x20a
[80243ae0] do_ioctl+0x2a/0x77
[802325cc] vfs_ioctl+0x25a/0x277
[8024ea4b] sys_ioctl+0x5f/0x82
[8026060e] system_call+0x7e/0x83
The bonding driver nests other drivers, give the bonding driver its own
lock class.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Cc: Stephen Hemminger [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/bonding/bond_main.c |5 +
1 files changed, 5 insertions(+)
diff -puN drivers/net/bonding/bond_main.c~bonding-lockdep-annotation
drivers/net/bonding/bond_main.c
--- a/drivers/net/bonding/bond_main.c~bonding-lockdep-annotation
+++ a/drivers/net/bonding/bond_main.c
@@ -4692,6 +4692,8 @@ static int bond_check_params(struct bond
return 0;
}
+static struct lock_class_key bonding_netdev_xmit_lock_key;
+
/* Create a new bond based on the specified name and bonding parameters.
* Caller must NOT hold rtnl_lock; we need to release it here before we
* set up our sysfs entries.
@@ -4727,6 +4729,9 @@ int bond_create(char *name, struct bond_
if (res 0) {
goto out_bond;
}
+
+ lockdep_set_class(bond_dev-_xmit_lock, bonding_netdev_xmit_lock_key);
+
if (newbond)
*newbond = bond_dev-priv;
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/9] drivers/atm: No need to return void
From: Tobias Klauser [EMAIL PROTECTED]
The module_exit function has return-type void and pci_unregister_driver()
returns void anyway.
Signed-off-by: Tobias Klauser [EMAIL PROTECTED]
Cc: chas williams [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/atm/ambassador.c |4 ++--
drivers/atm/horizon.c|4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff -puN drivers/atm/ambassador.c~drivers-atm-no-need-to-return-void
drivers/atm/ambassador.c
--- a/drivers/atm/ambassador.c~drivers-atm-no-need-to-return-void
+++ a/drivers/atm/ambassador.c
@@ -2452,8 +2452,8 @@ static int __init amb_module_init (void)
static void __exit amb_module_exit (void)
{
PRINTD (DBG_FLOW|DBG_INIT, cleanup_module);
-
- return pci_unregister_driver(amb_driver);
+
+ pci_unregister_driver(amb_driver);
}
module_init(amb_module_init);
diff -puN drivers/atm/horizon.c~drivers-atm-no-need-to-return-void
drivers/atm/horizon.c
--- a/drivers/atm/horizon.c~drivers-atm-no-need-to-return-void
+++ a/drivers/atm/horizon.c
@@ -2932,8 +2932,8 @@ static int __init hrz_module_init (void)
static void __exit hrz_module_exit (void) {
PRINTD (DBG_FLOW, cleanup_module);
-
- return pci_unregister_driver(hrz_driver);
+
+ pci_unregister_driver(hrz_driver);
}
module_init(hrz_module_init);
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/9] IPv6/DCCP: fix memory leak in dccp_v6_do_rcv()
From: Jesper Juhl [EMAIL PROTECTED]
Coverity found what looks like a real leak in
net/dccp/ipv6.c::dccp_v6_do_rcv()
We may leave via the return inside if (sk-sk_state == DCCP_OPEN) { but
at that point we may have allocated opt_skb, but we never free it in that
path before the return.
(akpm: does opt_skb actually do anything?)
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
net/dccp/ipv6.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff -puN net/dccp/ipv6.c~ipv6-dccp-fix-memory-leak-in-dccp_v6_do_rcv
net/dccp/ipv6.c
--- a/net/dccp/ipv6.c~ipv6-dccp-fix-memory-leak-in-dccp_v6_do_rcv
+++ a/net/dccp/ipv6.c
@@ -997,7 +997,7 @@ static int dccp_v6_do_rcv(struct sock *s
if (sk-sk_state == DCCP_OPEN) { /* Fast path */
if (dccp_rcv_established(sk, skb, dccp_hdr(skb), skb-len))
goto reset;
- return 0;
+ goto out;
}
if (sk-sk_state == DCCP_LISTEN) {
@@ -1013,9 +1013,7 @@ static int dccp_v6_do_rcv(struct sock *s
if (nsk != sk) {
if (dccp_child_process(sk, nsk, skb))
goto reset;
- if (opt_skb != NULL)
- __kfree_skb(opt_skb);
- return 0;
+ goto out;
}
}
@@ -1026,9 +1024,10 @@ static int dccp_v6_do_rcv(struct sock *s
reset:
dccp_v6_ctl_send_reset(skb);
discard:
+ kfree_skb(skb);
+out:
if (opt_skb != NULL)
__kfree_skb(opt_skb);
- kfree_skb(skb);
return 0;
}
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/8] Update smc91x driver with ARM Versatile board info
On Fri, Oct 20, 2006 at 02:42:04PM -0700, [EMAIL PROTECTED] wrote: We need to specify a Versatile-specific SMC_IRQ_FLAGS value or the new generic IRQ layer will complain thusly: I don't think I heard anything back from my previous suggestion that the IRQ flags are passed through the platform device IRQ resource. Doing so would avoid adding yet another platform specific block into the file. BTW, Integrator platforms will also suffer from this, which will add another ifdef to this header. Let's do it right and arrange to pass these flags from the platform code. It's not like they're in a critical path. -- Russell King - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes
On Fri, 20 Oct 2006 16:40:20 -0500 Andy Fleming [EMAIL PROTECTED] wrote: The solution is to ignore phy_interrupt() calls if the reported device has already been halted and calling flush_scheduled_work() from phy_stop_interrupts() (but guarded with current_is_keventd() in case the function has been called through keventd from the MAC device's close call to avoid a deadlock on the netlink lock). I've been trying to figure out this problem since you posted this, and I'm not sure I understand it fully Me either, but I basically gave up. If it is deadlocky for keventd to call flush_scheduled_work() I fail to see why it is not deadlocky for other processes. If the caller of flush_scheduled_work() holds rtnl_lock, and if a queued work callback also takes rtnl_lock then the flush_scheduled_work() caller will deadlock regardless of whether or not it is keventd. Because the flush_scheduled_work() caller holds a lock which will prevent the flush from completing. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hostap_plx: fix CIS verification
hostap_plx: fix CIS verification The record length for numerical manufacturer ID should be at least 4 bytes (two 16-bit words). The code required 5 bytes, which would break for most (if not all) cards. Reported by [EMAIL PROTECTED] Signed-off-by: Pavel Roskin [EMAIL PROTECTED] --- This is an small fix with significant impact. hostap_plx is currently broken, and this patch fixes it. Please forward this patch to 2.6.x.y kernels. drivers/net/wireless/hostap/hostap_plx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/hostap/hostap_plx.c b/drivers/net/wireless/hostap/hostap_plx.c index 6dfa041..b5b72db 100644 --- a/drivers/net/wireless/hostap/hostap_plx.c +++ b/drivers/net/wireless/hostap/hostap_plx.c @@ -391,7 +391,7 @@ #define CIS_MAX_LEN 256 break; case CISTPL_MANFID: - if (cis[pos + 1] 5) + if (cis[pos + 1] 4) goto cis_error; manfid1 = cis[pos + 2] + (cis[pos + 3] 8); manfid2 = cis[pos + 4] + (cis[pos + 5] 8); -- Regards, Pavel Roskin - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
wake on LAN with sky2
Hi folks, I saw that the wake on LAN function was removed from sky2 in kernel 2.6.17. It was also mentioned that this happened because it didn't work and also couldn't be tested but that it will be put back later. Is there some progress regarding this? I have a Mac mini core duo that can do suspend to RAM so that wake on LAN can be used to wake it up again, at least with MacOS X. I would be happy to help testing this with the sky2 driver. Regards, Tino - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/1] r8169 driver: corega support
[EMAIL PROTECTED] [EMAIL PROTECTED] :
[Corega adapter support]
It's queued in the r8169 branch at:
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git r8169
I have sent Jeff a pull request for it (and I'll probably send one
more for the patch below).
Darren, can you check if the patch below fixes you link detection
issue ?
From 6c94bf2ee2c932418bfe95d18460fb503f549659 Mon Sep 17 00:00:00 2001
From: Francois Romieu [EMAIL PROTECTED]
Date: Fri, 20 Oct 2006 23:10:14 +0200
Subject: [PATCH] r8169: perform a PHY reset before any other operation at boot
time
Realtek's 8139/810x (0x8136) PCI-E comes with a touchy PHY.
A big heavy reset seems to calm it down.
Fix for http://bugzilla.kernel.org/show_bug.cgi?id=7378.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index c2c9a86..e3d0679 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1442,6 +1442,23 @@ static void rtl8169_release_board(struct
free_netdev(dev);
}
+static void rtl8169_phy_reset(struct net_device *dev,
+ struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp-mmio_addr;
+ int i;
+
+ tp-phy_reset_enable(ioaddr);
+ for (i = 0; i 100; i++) {
+ if (!tp-phy_reset_pending(ioaddr)) {
+ printk(KERN_INFO %s: PHY reset done.\n, dev-name);
+ break;
+ }
+ msleep(1);
+ }
+ printk(KERN_ERR %s: PHY reset failed.\n, dev-name);
+}
+
static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private
*tp)
{
void __iomem *ioaddr = tp-mmio_addr;
@@ -1470,6 +1487,8 @@ static void rtl8169_init_phy(struct net_
rtl8169_link_option(board_idx, autoneg, speed, duplex);
+ rtl8169_phy_reset(dev, tp);
+
rtl8169_set_speed(dev, autoneg, speed, duplex);
if ((RTL_R8(PHYstatus) TBI_Enable) netif_msg_link(tp))
--
1.4.2.3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 12:25:27 -0700 Sorry, but why should we treat out-of-tree vendor code any differently than out-of-tree other code. I think what netdump was trying to do, provide a way to requeue instead of fully drop the SKB, is quite reasonable. Don't you think? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
On Fri, 20 Oct 2006 12:52:26 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 12:25:27 -0700 Sorry, but why should we treat out-of-tree vendor code any differently than out-of-tree other code. I think what netdump was trying to do, provide a way to requeue instead of fully drop the SKB, is quite reasonable. Don't you think? Yes, but the queued vs non-queued stuff showed up out of order. The queued messages go through the wrong Tx path. ie. they end up going into to NIT etc, since the deferred send uses a work queue it wouldn't work for last-gasp messages or netdump since getting a work queue to run requires going back to scheduler and processes running... and it should use skb_buff_head instead of roll your own queueing. The other alternative would be to make the send logic non-blocking and fully push retry to the caller. I'll make a fix to netdump, if I can find it. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
On Fri, 20 Oct 2006 12:52:26 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 12:25:27 -0700 Sorry, but why should we treat out-of-tree vendor code any differently than out-of-tree other code. I think what netdump was trying to do, provide a way to requeue instead of fully drop the SKB, is quite reasonable. Don't you think? Netdump doesn't even exist in the current Fedora source rpm. I think Dave dropped it. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 20 Oct 2006 08:40:15 -0700
-static void queue_process(void *p)
+static void netpoll_run(unsigned long arg)
{
...
- spin_unlock_irqrestore(queue_lock, flags);
+ netif_tx_lock(dev);
+ if (netif_queue_stopped(dev) ||
+ dev-hard_start_xmit(skb, dev) != NETDEV_TX_OK) {
+ skb_queue_head(npinfo-tx_q, skb);
+ netif_tx_unlock(dev);
+ tasklet_schedule(npinfo-tx_task);
+ return;
+ }
We really can't handle TX stopped this way from the netpoll_send_skb()
path. All that old retry logic in netpoll_send_skb() is really
necessary.
If we are in deep IRQ context, took an OOPS, and are trying to get a
netpoll packet out for the kernel log message, we have to try as hard
as possible to get the packet out then and there, even if that means
waiting some amount of time for netif_queue_stopped() to become false.
That is what the existing code is trying to do.
If you defer to a tasklet, the kernel state from the OOPS can be so
corrupted that the tasklet will never run and we'll never get the
netconsole message needed to debug the problem.
Also, if we tasklet schedule from the tasklet, we'll just keep looping
in the tasklet and never leave softirq context, which is also bad
behavior. Even in the tasklet, we should spin and poll when possible
like the current netpoll_send_skb() code does.
So we really can't apply this patch.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
On Fri, 20 Oct 2006 13:42:09 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 20 Oct 2006 08:40:15 -0700
-static void queue_process(void *p)
+static void netpoll_run(unsigned long arg)
{
...
- spin_unlock_irqrestore(queue_lock, flags);
+ netif_tx_lock(dev);
+ if (netif_queue_stopped(dev) ||
+ dev-hard_start_xmit(skb, dev) != NETDEV_TX_OK) {
+ skb_queue_head(npinfo-tx_q, skb);
+ netif_tx_unlock(dev);
+ tasklet_schedule(npinfo-tx_task);
+ return;
+ }
We really can't handle TX stopped this way from the netpoll_send_skb()
path. All that old retry logic in netpoll_send_skb() is really
necessary.
If we are in deep IRQ context, took an OOPS, and are trying to get a
netpoll packet out for the kernel log message, we have to try as hard
as possible to get the packet out then and there, even if that means
waiting some amount of time for netif_queue_stopped() to become false.
But, it also violates the assumptions of the network devices.
It calls NAPI poll back with IRQ's disabled and potentially doesn't
obey the semantics about only running on the same CPU as the
received packet.
That is what the existing code is trying to do.
If you defer to a tasklet, the kernel state from the OOPS can be so
corrupted that the tasklet will never run and we'll never get the
netconsole message needed to debug the problem.
So we can try once and if that fails we have to defer to tasklet.
We can't call NAPI, we can't try and cleanup the device will need
an IRQ to get unblocked.
Or add another device callback that just to handle that case.
Also, if we tasklet schedule from the tasklet, we'll just keep looping
in the tasklet and never leave softirq context, which is also bad
behavior. Even in the tasklet, we should spin and poll when possible
like the current netpoll_send_skb() code does.
So we really can't apply this patch.
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e100_shutdown: netif_poll_disable hang
Daniel Walker wrote: My machine annoyingly hangs while rebooting. I tracked it down to e100-fix-reboot-f-with-netconsole-enabled.patch in 2.6.18-rc2-mm2 I review the changes and it seemed to be calling netif_poll_disable one too many time. Once in e100_down(), and again in e100_shutdown(). The second one in e100_shutdown() caused the hang. So this patch removes it. Signed-Off-By: Daniel Walker [EMAIL PROTECTED] --- drivers/net/e100.c |1 - 1 files changed, 1 deletion(-) Index: linux-2.6.18/drivers/net/e100.c === --- linux-2.6.18.orig/drivers/net/e100.c +++ linux-2.6.18/drivers/net/e100.c @@ -2709,7 +2709,6 @@ static void e100_shutdown(struct pci_dev struct net_device *netdev = pci_get_drvdata(pdev); struct nic *nic = netdev_priv(netdev); - netif_poll_disable(nic-netdev); del_timer_sync(nic-watchdog); netif_carrier_off(nic-netdev); -- this won't help netconsole shutdown/reboot -f, probably locking it up again! NAK Also missing is the NAPI conditional, which I left out. Also missing is the same code for suspend. Here's a better approach, allowing both normal shutdown code path and reboot -f to disable polling. Cheers, Auke --- e100: disable polling only when up during suspend and shutdown Signed-off-by: Auke Kok auke-jan.h.kok Cc: Daniel Walker [EMAIL PROTECTED] Cc: Andrew Morton [EMAIL PROTECTED] --- drivers/net/e100.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) --- diff --git a/drivers/net/e100.c b/drivers/net/e100.c index d4a2572..815eb29 100644 --- a/drivers/net/e100.c +++ b/drivers/net/e100.c @@ -2719,7 +2719,10 @@ static int e100_suspend(struct pci_dev * struct net_device *netdev = pci_get_drvdata(pdev); struct nic *nic = netdev_priv(netdev); - netif_poll_disable(nic-netdev); +#ifdef CONFIG_E100_NAPI + if (netif_running(netdev)) + netif_poll_disable(nic-netdev); +#endif del_timer_sync(nic-watchdog); netif_carrier_off(nic-netdev); @@ -2763,7 +2766,10 @@ static void e100_shutdown(struct pci_dev struct net_device *netdev = pci_get_drvdata(pdev); struct nic *nic = netdev_priv(netdev); - netif_poll_disable(nic-netdev); +#ifdef CONFIG_E100_NAPI + if (netif_running(netdev)) + netif_poll_disable(nic-netdev); +#endif del_timer_sync(nic-watchdog); netif_carrier_off(nic-netdev); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
But, it also violates the assumptions of the network devices. It calls NAPI poll back with IRQ's disabled and potentially doesn't obey the semantics about only running on the same CPU as the received packet. netpoll always played a little fast'n'lose with various locking rules. Also often inside the drivers are a little sloppy in the poll path. That's fine for getting an oops out, but risky for normal kernel messages when the driver must be still working afterwards. The standard console code makes this conditional on oops_in_progress - it breaks locks when true and otherwise it follows the safe approach. Perhaps it would be better to use different paths in netconsole too depending on whether oops_in_progress is true or not. e.g. if !oops_in_progress (use the standard output path) else use current path. That would avoid breaking the driver during normal operation and also have the advantage that the normal netconsole messages would go through the queueing disciplines etc. -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 13:48:26 -0700 On Fri, 20 Oct 2006 13:42:09 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: We really can't handle TX stopped this way from the netpoll_send_skb() path. All that old retry logic in netpoll_send_skb() is really necessary. If we are in deep IRQ context, took an OOPS, and are trying to get a netpoll packet out for the kernel log message, we have to try as hard as possible to get the packet out then and there, even if that means waiting some amount of time for netif_queue_stopped() to become false. But, it also violates the assumptions of the network devices. It calls NAPI poll back with IRQ's disabled and potentially doesn't obey the semantics about only running on the same CPU as the received packet. Actually, all the locking here is fine, that's why it checks poll_owner for current smp_processor_id(). Otherwise it is safe to sit and spin waiting for link up/down or TX full conditions to pass. So we can try once and if that fails we have to defer to tasklet. Not true, we should spin and retry for some reasonable amount of time. That reasonable amount of time should be the maximum of the time it takes to free up space from a TX full condition and the time it takes to bring the link up. That is what the current code is trying to do, and you've erroneously deleted all of that logic. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e100_shutdown: netif_poll_disable hang
Auke Kok wrote: Daniel Walker wrote: My machine annoyingly hangs while rebooting. I tracked it down to e100-fix-reboot-f-with-netconsole-enabled.patch in 2.6.18-rc2-mm2 I review the changes and it seemed to be calling netif_poll_disable one too many time. Once in e100_down(), and again in e100_shutdown(). The second one in e100_shutdown() caused the hang. So this patch removes it. it doesn't even do harm to netif_poll_disable() twice as far as I can see, as it merely calls test_and_set_bit(), which will instantly succeed on the first attempt if the bit was already set. did this change actually fix it for you? I'm wondering if the netif_carrier_off might not be the culprit here... Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
From: Andi Kleen [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 23:01:29 +0200 netpoll always played a little fast'n'lose with various locking rules. The current code is fine, it never reenters -poll, because it maintains a -poll_owner which it checks in netpoll_send_skb() before trying to call back into -poll. Every call to -poll first sets -poll_owner to the current cpu id. netpoll_send_skb() aborts and does a drop if -poll_owner is set to the current smp_processor_id(). I sometimes feel like I'm the only person actually reading the sources and past threads on this topic before replying. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
On Friday 20 October 2006 23:08, David Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 23:01:29 +0200 netpoll always played a little fast'n'lose with various locking rules. The current code is fine, it never reenters -poll, because it maintains a -poll_owner which it checks in netpoll_send_skb() before trying to call back into -poll. I was more thinking of reentry of the interrupt handler in the driver etc. A lot of them also do printk, but that is fortunately caught higher level. -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
On Fri, 20 Oct 2006 23:16:03 +0200 Andi Kleen [EMAIL PROTECTED] wrote: On Friday 20 October 2006 23:08, David Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 23:01:29 +0200 netpoll always played a little fast'n'lose with various locking rules. The current code is fine, it never reenters -poll, because it maintains a -poll_owner which it checks in netpoll_send_skb() before trying to call back into -poll. I was more thinking of reentry of the interrupt handler in the driver etc. A lot of them also do printk, but that is fortunately caught higher level. -Andi One problem is that with netconsole the NAPI poll routine can be called with IRQ's disabled. This means that calls to dev_kfree_skb() are incorrect in this context. The driver would have to use dev_kfree_skb_any() instead. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] netpoll: use device xmit directly
For most normal sends, the netpoll code was using the dev-hard_start_xmit
directly. If it got busy, it would process later, but this code path uses
dev_queue_xmit() and that code would send the skb through NIT and other
stuff that netpoll doesn't want.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- netpoll.orig/net/core/netpoll.c
+++ netpoll/net/core/netpoll.c
@@ -51,17 +51,28 @@ static atomic_t trapped;
static void zap_completion_queue(void);
static void arp_reply(struct sk_buff *skb);
+static void queue_process(void *);
+static DECLARE_WORK(send_queue, queue_process, NULL);
+
static void queue_process(void *p)
{
struct sk_buff *skb;
- while ((skb = skb_dequeue(netpoll_txq)))
- dev_queue_xmit(skb);
+ while ((skb = skb_dequeue(netpoll_txq))) {
+ struct net_device *dev = skb-dev;
+ netif_tx_lock_bh(dev);
+ if (netif_queue_stopped(dev) ||
+ dev-hard_start_xmit(skb, dev) != NETDEV_TX_OK) {
+ skb_queue_head(netpoll_txq, skb);
+ netif_tx_unlock_bh(dev);
+ schedule_delayed_work(send_queue, 1);
+ break;
+ }
+ netif_tx_unlock_bh(dev);
+ }
}
-static DECLARE_WORK(send_queue, queue_process, NULL);
-
void netpoll_queue(struct sk_buff *skb)
{
skb_queue_tail(netpoll_txq, skb);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] netpoll: use sk_buff_head for txq
This is similar in spirit to earlier patches with less changes.
Get rid of DIY queue for skb's used in netpoll. Add missing code to cleanup
queue on shutdown.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- netpoll.orig/net/core/netpoll.c
+++ netpoll/net/core/netpoll.c
@@ -37,10 +37,7 @@
#define MAX_RETRIES 2
static struct sk_buff_head netpoll_pool;
-
-static DEFINE_SPINLOCK(queue_lock);
-static int queue_depth;
-static struct sk_buff *queue_head, *queue_tail;
+static struct sk_buff_head netpoll_txq;
static atomic_t trapped;
@@ -56,44 +53,18 @@ static void arp_reply(struct sk_buff *sk
static void queue_process(void *p)
{
- unsigned long flags;
struct sk_buff *skb;
- while (queue_head) {
- spin_lock_irqsave(queue_lock, flags);
-
- skb = queue_head;
- queue_head = skb-next;
- if (skb == queue_tail)
- queue_head = NULL;
-
- queue_depth--;
-
- spin_unlock_irqrestore(queue_lock, flags);
-
+ while ((skb = skb_dequeue(netpoll_txq)))
dev_queue_xmit(skb);
- }
+
}
static DECLARE_WORK(send_queue, queue_process, NULL);
void netpoll_queue(struct sk_buff *skb)
{
- unsigned long flags;
-
- if (queue_depth == MAX_QUEUE_DEPTH) {
- __kfree_skb(skb);
- return;
- }
-
- spin_lock_irqsave(queue_lock, flags);
- if (!queue_head)
- queue_head = skb;
- else
- queue_tail-next = skb;
- queue_tail = skb;
- queue_depth++;
- spin_unlock_irqrestore(queue_lock, flags);
+ skb_queue_tail(netpoll_txq, skb);
schedule_work(send_queue);
}
@@ -745,6 +716,7 @@ int netpoll_setup(struct netpoll *np)
}
static int __init netpoll_init(void) {
+ skb_queue_head_init(netpoll_txq);
skb_queue_head_init(netpoll_pool);
return 0;
}
@@ -752,20 +724,30 @@ core_initcall(netpoll_init);
void netpoll_cleanup(struct netpoll *np)
{
- struct netpoll_info *npinfo;
+ struct net_device *dev = np-dev;
+ struct sk_buff *skb, *next;
unsigned long flags;
- if (np-dev) {
- npinfo = np-dev-npinfo;
+ if (dev) {
+ struct netpoll_info *npinfo = dev-npinfo;
+
if (npinfo npinfo-rx_np == np) {
spin_lock_irqsave(npinfo-rx_lock, flags);
npinfo-rx_np = NULL;
npinfo-rx_flags = ~NETPOLL_RX_ENABLED;
spin_unlock_irqrestore(npinfo-rx_lock, flags);
}
- dev_put(np-dev);
+ dev_put(dev);
+
+ spin_lock_irqsave(netpoll_txq.lock, flags);
+ for (skb = (struct sk_buff *)netpoll_txq.next;
+skb != (struct sk_buff *)netpoll_txq; skb = next) {
+ next = skb-next;
+ if (skb-dev == dev)
+ skb_unlink(skb, netpoll_txq);
+ }
+ spin_unlock_irqrestore(netpoll_txq.lock, flags);
}
-
np-dev = NULL;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] netpoll: retry logic cleanup
Change retry logic of netpoll. Always requeue if unable to send
instead of dropping. Make retry counter per send rather than causing
mass migration when tries gets less than zero. Since callers are
either netpoll_send_arp or netpoll_send_udp, we knwo that np and np-dev
can't be null.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- netpoll.orig/include/linux/netpoll.h
+++ netpoll/include/linux/netpoll.h
@@ -27,7 +27,6 @@ struct netpoll {
struct netpoll_info {
spinlock_t poll_lock;
int poll_owner;
- int tries;
int rx_flags;
spinlock_t rx_lock;
struct netpoll *rx_np; /* netpoll that registered an rx_hook */
--- netpoll.orig/net/core/netpoll.c
+++ netpoll/net/core/netpoll.c
@@ -232,50 +232,43 @@ static struct sk_buff * find_skb(struct
static void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb)
{
- int status;
- struct netpoll_info *npinfo;
-
- if (!np || !np-dev || !netif_running(np-dev))
- goto free_skb;
+ struct net_device *dev = np-dev;
+ struct netpoll_info *npinfo = dev-npinfo;
+ int status, tries;
- npinfo = np-dev-npinfo;
+ if (!netif_running(dev) || !netif_device_present(dev))
+ __kfree_skb(skb);
/* avoid recursion */
if (npinfo-poll_owner == smp_processor_id() ||
- np-dev-xmit_lock_owner == smp_processor_id()) {
- if (np-drop)
- np-drop(skb);
- else
- __kfree_skb(skb);
- return;
- }
-
- do {
- npinfo-tries--;
- netif_tx_lock(np-dev);
+ dev-xmit_lock_owner == smp_processor_id())
+ goto busy;
+ for (tries = MAX_RETRIES; tries; --tries) {
/*
* network drivers do not expect to be called if the queue is
* stopped.
*/
- status = NETDEV_TX_BUSY;
- if (!netif_queue_stopped(np-dev))
- status = np-dev-hard_start_xmit(skb, np-dev);
-
- netif_tx_unlock(np-dev);
+ if (netif_queue_stopped(dev))
+ status = NETDEV_TX_BUSY;
+ else
+ status = dev-hard_start_xmit(skb, dev);
+ netif_tx_unlock(dev);
/* success */
- if(!status) {
- npinfo-tries = MAX_RETRIES; /* reset */
+ if(status == NETDEV_TX_OK)
return;
- }
/* transmit busy */
netpoll_poll(np);
udelay(50);
- } while (npinfo-tries 0);
-free_skb:
- __kfree_skb(skb);
+ }
+
+busy:
+ if (np-drop)
+ np-drop(skb);
+ else
+ __kfree_skb(skb);
}
void netpoll_send_udp(struct netpoll *np, const char *msg, int len)
@@ -628,7 +621,7 @@ int netpoll_setup(struct netpoll *np)
npinfo-rx_np = NULL;
spin_lock_init(npinfo-poll_lock);
npinfo-poll_owner = -1;
- npinfo-tries = MAX_RETRIES;
+
spin_lock_init(npinfo-rx_lock);
skb_queue_head_init(npinfo-arp_tx);
} else
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sky2: 88E803X transmit lockup
The reason sky2 driver was locking up on transmit on the Yukon-FE chipset
is that it was misconfiguring the internal RAM buffer so the transmitter
and receiver were sharing the same space.
The code assumed there was 16K of RAM on Yukon-FE (taken from vendor driver
sk98lin which is even more f*cked up on this). Then it assigned based on that.
The giveaway was that the registers would only hold 9bits so both RX/TX
had 0..1ff for space. It is a wonder it worked at all!
This patch addresses this, and fixes an easily reproducible hang on Transmit.
Only the Yukon-FE chip is Marvell 88E803X (10/100 only) are affected.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2.orig/drivers/net/sky2.c2006-10-20 16:37:56.0 -0700
+++ sky2/drivers/net/sky2.c 2006-10-20 16:38:16.0 -0700
@@ -699,16 +699,10 @@
}
-/* Assign Ram Buffer allocation.
- * start and end are in units of 4k bytes
- * ram registers are in units of 64bit words
- */
-static void sky2_ramset(struct sky2_hw *hw, u16 q, u8 startk, u8 endk)
+/* Assign Ram Buffer allocation in units of 64bit (8 bytes) */
+static void sky2_ramset(struct sky2_hw *hw, u16 q, u32 start, u32 end)
{
- u32 start, end;
-
- start = startk * 4096/8;
- end = (endk * 4096/8) - 1;
+ pr_debug(PFX q %d %#x %#x\n, q, start, end);
sky2_write8(hw, RB_ADDR(q, RB_CTRL), RB_RST_CLR);
sky2_write32(hw, RB_ADDR(q, RB_START), start);
@@ -717,7 +711,7 @@
sky2_write32(hw, RB_ADDR(q, RB_RP), start);
if (q == Q_R1 || q == Q_R2) {
- u32 space = (endk - startk) * 4096/8;
+ u32 space = end - start + 1;
u32 tp = space - space/4;
/* On receive queue's set the thresholds
@@ -1199,19 +1193,16 @@
sky2_mac_init(hw, port);
- /* Determine available ram buffer space (in 4K blocks).
-* Note: not sure about the FE setting below yet
-*/
- if (hw-chip_id == CHIP_ID_YUKON_FE)
- ramsize = 4;
- else
- ramsize = sky2_read8(hw, B2_E_0);
+ /* Determine available ram buffer space in qwords. */
+ ramsize = sky2_read8(hw, B2_E_0) * 4096/8;
- /* Give transmitter one third (rounded up) */
- rxspace = ramsize - (ramsize + 2) / 3;
+ if (ramsize 6*1024/8)
+ rxspace = ramsize - (ramsize + 2) / 3;
+ else
+ rxspace = ramsize / 2;
- sky2_ramset(hw, rxqaddr[port], 0, rxspace);
- sky2_ramset(hw, txqaddr[port], rxspace, ramsize);
+ sky2_ramset(hw, rxqaddr[port], 0, rxspace-1);
+ sky2_ramset(hw, txqaddr[port], rxspace, ramsize-1);
/* Make sure SyncQ is disabled */
sky2_write8(hw, RB_ADDR(port == 0 ? Q_XS1 : Q_XS2, RB_CTRL),
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hostap_plx: fix CIS verification
On Fri, Oct 20, 2006 at 06:20:15PM -0400, Pavel Roskin wrote: The record length for numerical manufacturer ID should be at least 4 bytes (two 16-bit words). The code required 5 bytes, which would break for most (if not all) cards. Reported by [EMAIL PROTECTED] case CISTPL_MANFID: - if (cis[pos + 1] 5) + if (cis[pos + 1] 4) Hmm.. Interesting. I think this was changed from 4 to 5 due to a potential buffer overflow as reported by Coverity tools.. In addition, I think that I spent long time trying to understand why it could be a buffer overflow and since it was changed, likely finally figured out an example case.. Alas, I don't remember what exactly this was anymore. It looks like the comparison of the length field to be 5 was incorrect, but in order to avoid re-introducing any potential buffer overflows, that condition could be extended to verify that pos is small enough.. Something like (cis[pos + 1] 4 pos + 5 CIS_MAX_LEN) could be a better fix here. I don't have easy access to PLX cards anymore, so this is untested and I'm too lazy to copy this function into a separate program to run it against CIS dumps. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Ethernet Cheap Cryptography
Pawel Foremski writes: Consider such an example: our task is to bridge two LANs managed by a third-party ISP over a wireless link, with the highest performance possible for such medium. The ISP has its clients on one LAN and a PPPoE concentrator on the second one. Because the ISP doesn't trust us or is not aware of our bridge, it uses MPPE to secure PPP. We cannot enforce any changes to the way the ISP provides services to its end users. In ASCII art, that would be: [PPPoE server]---[Linux#1]--ccrypt--[dumb WiFi bridge] ))) \/ || [PPPoE client]---[Linux#2]--ccrypt--[dumb WiFi bridge] ((( =/ Obviously, the dumb WiFi bridge cannot speak anything other than 1500-byte, plain (not encrypted) Ethernet. Since there was no mention of bridging in the ccrypt documentation or previously in the email thread I (incorrectly) assumed that PPPoE was terminating on the Linux box. Thus the IP traffic would be visible and hence IPsec could be used. Clearly if the Linux box is bridging PPPoE as you note above then IPsec is not viable. Thus the addition of the above scenario to the ccrypt documentation help would avoid getting questions about why you can't use IPsec :-) However, in the above you note that MPPE is being used. I take this to mean that all the PPP traffic between the PPPoE client and PPPoE server is encrypted. However, if that's the case then I don't understand why there is a need to use ccrypt for the wireless link between the two Linux boxes. Thus perhaps I misunderstood where MPPE is being used? Or perhaps you meant this is only one example and in other scenarios MPPE is not used and so in that case the wireless traffic does need encrypting? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Ethernet Cheap Cryptography
David Miller writes: From: [EMAIL PROTECTED] (Stephen J. Bevan) Date: Thu, 19 Oct 2006 19:18:41 -0700 Pawel Foremski writes: Secondly, IPsec won't decrease MSS in TCP encapsulated in PPPoE traffic, for example. Various, commercial, IPsec products decrease the MSS for TCP encapsulated in PPPoE. I've not checked the Linux 2.6 IPsec code to see if it does or if it can easily be made to. Linux will for local TCP connections over IPSEC transports since it knows the path MTU, for IPSEC gateways the source system will adjust the MSS after it notes via path-MTU what the decreased MTU is. path-MTU gets interesting[1] in the context of an an IPsec gateway (i.e. tunnel mode IPsec) and there is definitely variability as to how reliably an ICMP will be returned in the case that the MTU is exceeded somewhere between the two endpoints. Throw in port/protocol based selectors[2] or IPv4(IPv6) traffic encrypted with an IPv6(IPv4) header[3] and the chances of success go down. Users ussually don't tend to care whose IPsec is at fault, they just want things to work. Thus, having tunnel mode IPsec alter the MSS (of non-local traffic) to take account of the encryption (or PPPoE, ... etc.) overhead smooths over most fragmentation issues. -- [1] as detailed in the length Appendix B of RFC 2401. [2] some IPsec implementation won't correctly match an ICMP up against port/protocol based selectors and so the ICMP is lost. [3] mapping the DF bit is left to implementations, some reset the DF bit and so just fragment. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Ethernet Cheap Cryptography
From: [EMAIL PROTECTED] (Stephen J. Bevan) Date: Fri, 20 Oct 2006 19:17:42 -0700 path-MTU gets interesting[1] in the context of an an IPsec gateway (i.e. tunnel mode IPsec) and there is definitely variability as to how reliably an ICMP will be returned in the case that the MTU is exceeded somewhere between the two endpoints. Throw in port/protocol based selectors[2] or IPv4(IPv6) traffic encrypted with an IPv6(IPv4) header[3] and the chances of success go down. Yes, this has been discussed to death here previosly. It can be made more reliable, the fact that most of the implementations suck (to some extent including Linux's) should not deter us trying to make it work as reliably as possible. I just think that this ethernet level crypto talk is a complete waste of time, there are much better things to concentrate on in my opinion. :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/9] IPv6/DCCP: fix memory leak in dccp_v6_do_rcv()
From: [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 14:43:02 -0700 (akpm: does opt_skb actually do anything?) This is a clone of similar code in net/ipv6/tcp_ipv6.c, it's just missing the bits at label ipv6_pktoptions: :-) No offence to the original patch, it's correct, but I'm going to fix this by making the dccp ipv6 logic match the code it was copied from in tcp_ipv6.c as much as possible. Thanks a lot for finding this leak Jesper. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Ethernet Cheap Cryptography
Ethernet encrypted bridging is old stuff: http://kerneltrap.org/node/167 http://www.arnor.net/encryptingbridge/ It never got accepted, mostly for the same reasons this proposal is a dead end. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 6/9] NET/atm: handle sysfs errors
From: [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 14:43:16 -0700 From: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/9] drivers/atm: No need to return void
From: [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 14:43:03 -0700 From: Tobias Klauser [EMAIL PROTECTED] The module_exit function has return-type void and pci_unregister_driver() returns void anyway. Signed-off-by: Tobias Klauser [EMAIL PROTECTED] Cc: chas williams [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/9] atm/firestream: handle thrown error
From: [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 14:43:14 -0700 From: Jeff Garzik [EMAIL PROTECTED] gcc emits the following warning: drivers/atm/firestream.c: In function $,1rx(Bfs_open$,1ry(B: drivers/atm/firestream.c:870: warning: $,1rx(Btmc0$,1ry(B may be used uninitialized in this function This indicates a real bug. We should check make_rate() return value for potential errors. Signed-off-by: Jeff Garzik [EMAIL PROTECTED] Cc: chas williams [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 8/9] nicstar: Fix a bogus casting warning
From: [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 14:43:18 -0700 From: Alan Cox [EMAIL PROTECTED] Not enough to make Nicstar 64bit friendly but got squashed in passing so might as well be applied Signed-off-by: Alan Cox [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx-softmac: add PCI-E code
On Friday 20 October 2006 20:25, Daniel Drake wrote: Michael Buesch wrote: Which kernel are you using exactly? 2.6.19-rc2 Please try 2.6.18.1 or wireless-2.6. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: Readd dropped assignment
On Wed, Oct 18, 2006 at 04:40:00PM +0200, Michael Buesch wrote: On Wednesday 18 October 2006 01:12, Daniel Drake wrote: Larry Finger pointed out a problem with my ieee80211 IV/ICV stripping patch, which I forgot about. Sorry about that. The patch readds the frame_ctl assignment which was accidently dropped. Signed-off-by: Daniel Drake [EMAIL PROTECTED] Whoops. Please merge this as fast as possible, John. That's a real bug which prevents RX from working. Is that one for -stable too? That file looks similar enough between .18.1 and .19rc that it should be the case ? Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: Readd dropped assignment
Dave Jones wrote: Is that one for -stable too? That file looks similar enough between .18.1 and .19rc that it should be the case ? No. The IV/ICV stripping change was only merged into John's tree very recently (the day I sent the fix). Daniel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] netpoll: rework skb transmit queue
On Fri, Oct 20, 2006 at 01:25:32PM -0700, Stephen Hemminger wrote: On Fri, 20 Oct 2006 12:52:26 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 12:25:27 -0700 Sorry, but why should we treat out-of-tree vendor code any differently than out-of-tree other code. I think what netdump was trying to do, provide a way to requeue instead of fully drop the SKB, is quite reasonable. Don't you think? Netdump doesn't even exist in the current Fedora source rpm. I think Dave dropped it. Indeed. Practically no-one cared about it, so it bit-rotted really fast after we shipped RHEL4. That, along with the focus shifting to making kdump work seemed to kill it off over the last 12 months. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
