Re: TCP send/ack lockstep problem
Matthias Urlichs [EMAIL PROTECTED] wrote:
The stuff I see in there doesn't look stupid to me.
accept(...) = 216
setsockopt(216, SOL_IP, IP_TOS, [8], 4) = 0
setsockopt(216, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(216, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
followed by a bunch of interactive read() and write() calls, and then
a rather long sequence of 16384-byte writes (all of which end up being
partial because the send buffer size is 12k).
Please send the actual strace with the options -ttT. If you can also
send the tcpdumps that occur at the same time then we can match them up
and figure out what's going on.
So far the only thing I can see from your original tcpdump is that every
other ack is followed by a noticeable delay before a packet is sent.
This is a typical symptom when the appliation has nothing in the buffer.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
VGER BF report: U 0.499395
-
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: TCP send/ack lockstep problem
Matthias Urlichs wrote: Hi, Herbert Xu: Matthias Urlichs [EMAIL PROTECTED] wrote: Any ideas? Is the sending program doing something stupid? If so, what? Probably. Since you're on the sender's side (192.109.x.x I presume) why don't you do a strace on the sending process and tell us? The stuff I see in there doesn't look stupid to me. accept(...) = 216 setsockopt(216, SOL_IP, IP_TOS, [8], 4) = 0 setsockopt(216, SOL_TCP, TCP_NODELAY, [1], 4) = 0 setsockopt(216, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 followed by a bunch of interactive read() and write() calls, and then a rather long sequence of 16384-byte writes (all of which end up being partial because the send buffer size is 12k). so if one of these is the cause for the observed lockstep behavior when the send buffer is *full*, I'd consider that to be a bug. Interestingly, the *sender* advertizes window that's (a bit more than) one MTU: 07:47:03.204939 IP (tos 0x38, ttl 64, id 41217, offset 0, flags [DF], proto: TCP (6), length: 1468) 192.109.102.42.3306 62.193.238.120.53138: . 167089:168505 (1416) ack 0 win 1424 nop,nop,timestamp 218027038 834794727 but that's the other direction -- is something in the kernel confused about which window variable to use ?? You could try turning off window scaling: sysctl -w net.ipv4.tcp_window_scaling=0 If that fixes it, you have a corrupting middlebox in the path or bad implementation on the other end. Also try turning off tcp_abc (on the sender). sysctl -w net.ipv4.tcp_abc=0 -- VGER BF report: H 0.050318 - 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: Linux UDP Implementation
Dear Rick, Thank you for your reply. I am sorry that I don't quite understand your point. As far as I know, the function call udp_flush_pending_frames() in net/ipv4/udp.c is invoked regardless of whether the socket is set to either a blocking mode or a non-blocking mode. Do you mean that the implementation in the function sendto() handles the packet drop at the interface queue by caching data at the socket level ? If so, could you please advise me the Linux Kernel source file which contains the exact implementation of sendto() API function call in Linux ? I tried to locate this souce file using a bottom-up approach starting at the function call udp_sendmsg(), - inet_sendmsg() in net/ipv4/af_inet.c - sock_sendmsg() in net/socket.c- sys_sendto() in net/socket.c ... but I finally got lost in sys_sendto(). Thank you for your help. Regards, Gary - Original Message - From: Rick Jones [EMAIL PROTECTED] To: Gary Chan [EMAIL PROTECTED] Sent: Friday, September 01, 2006 1:00 AM Subject: Re: Linux UDP Implementation Gary Chan wrote: According to the function call udp_sendmsg() in the source file net/ipv4/udp.c (Linux Kernel 2.6.17.11), when an error value is returned from the function ip_append_data() due to local device congestion, say interface queue overflow, pending packets in the queue sk-sk_write_queue are simply flushed (udp_flush_pending_frames() is invoked) without caching for future retransmission. I called a network API function sendto() to transmit UDP packets in a blocking I/O mode at a rate of 100Mbps over the 802.11b wireless ad hoc network, the network was overloaded as the maximum transfer rate for 802.11b was just 11Mbps. Therefore, the outgoing interface queue must be full and UDP packets will be dropped eventually. However, I checked that there was no packet loss at the receiver side, i.e. the number of packets sent from the sender is equal to that received. It seems that the implementation (at code level) does not match with the actual behaviour. I would like to seek expertise on clarifying my understanding in UDP implementation so that this phenomenon can be explained. Perhaps you are seeing a difference in the behaviour of blocking vs non-blocking sockets? rick jones -- VGER BF report: U 0.5 - 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] tcp: turn ABC off
On Fri, Sep 01, 2006 at 01:55:15PM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 111ff39..159fa3f 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -89,7 +89,7 @@ int sysctl_tcp_frto; int sysctl_tcp_nometrics_save; int sysctl_tcp_moderate_rcvbuf = 1; -int sysctl_tcp_abc = 1; +int sysctl_tcp_abc; Since it is not static are you sure it will be zero? -- Evgeniy Polyakov -- VGER BF report: H 8.21099e-10 - 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] tcp: turn ABC off
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Fri, Sep 01, 2006 at 01:55:15PM -0700, Stephen Hemminger ([EMAIL
PROTECTED]) wrote:
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 111ff39..159fa3f 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -89,7 +89,7 @@ int sysctl_tcp_frto;
int sysctl_tcp_nometrics_save;
int sysctl_tcp_moderate_rcvbuf = 1;
-int sysctl_tcp_abc = 1;
+int sysctl_tcp_abc;
Since it is not static are you sure it will be zero?
Outside a function the static modifier merely modifies whether the
symbol is visible externally. It does not control whether it gets
zeroed. And yes this will get zeroed.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
VGER BF report: U 0.49998
-
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: TCP send/ack lockstep problem
Hi, found it. This is the tcpdump, for your edification. Note that many packets have push set for no good reason, which generally indicates dropped packets if we're doing a bulk transfer. But all packets that are visible in the dump reached their destination..! The culprit turns out to be the traffic shaper, which had a subtly-broken configuration and thus shaped that particular traffic with a scythe instead of a razor. A way to attach tcpdump so that those dropped packets get reported (with an appropriate indication) would probably be helpful. Anyway, this is not a packet that was dropped on the wire. So why set the Push flag? TCP *knows* it couldn' send the thing. 09:16:40.652962 IP (tos 0x0, ttl 53, id 16206, offset 0, flags [DF], proto: TCP (6), length: 60) 62.193.238.120.58818 192.109.102.42.3306: S, cksum 0x4ef3 (correct), 692009621:692009621(0) win 5840 mss 1460,sackOK,timestamp 840173019 0,nop,wscale 2 09:16:40.653030 IP (tos 0x34, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 192.109.102.42.3306 62.193.238.120.58818: S, cksum 0xf277 (correct), 3232139371:3232139371(0) ack 692009622 win 5696 mss 1100,sackOK,timestamp 218564681 840173019,nop,wscale 2 09:16:40.705214 IP (tos 0x0, ttl 53, id 16207, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.58818 192.109.102.42.3306: ., cksum 0x302f (correct), 1:1(0) ack 1 win 1460 nop,nop,timestamp 840173071 218564681 09:16:40.716501 IP (tos 0x38, ttl 64, id 32802, offset 0, flags [DF], proto: TCP (6), length: 127) 192.109.102.42.3306 62.193.238.120.58818: P 1:76(75) ack 1 win 1424 nop,nop,timestamp 218564687 840173071 09:16:40.754853 IP (tos 0x0, ttl 53, id 16208, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.58818 192.109.102.42.3306: ., cksum 0x2fac (correct), 1:1(0) ack 76 win 1460 nop,nop,timestamp 840173121 218564687 09:16:40.758899 IP (tos 0x0, ttl 53, id 16209, offset 0, flags [DF], proto: TCP (6), length: 116) 62.193.238.120.58818 192.109.102.42.3306: P 1:65(64) ack 76 win 1460 nop,nop,timestamp 840173124 218564687 09:16:40.759877 IP (tos 0x34, ttl 64, id 32803, offset 0, flags [DF], proto: TCP (6), length: 52) 192.109.102.42.3306 62.193.238.120.58818: ., cksum 0x2f88 (correct), 76:76(0) ack 65 win 1424 nop,nop,timestamp 218564692 840173124 09:16:40.768414 IP (tos 0x34, ttl 64, id 32804, offset 0, flags [DF], proto: TCP (6), length: 63) 192.109.102.42.3306 62.193.238.120.58818: P, cksum 0x2870 (correct), 76:87(11) ack 65 win 1424 nop,nop,timestamp 218564693 840173124 09:16:40.805883 IP (tos 0x0, ttl 53, id 16210, offset 0, flags [DF], proto: TCP (6), length: 73) 62.193.238.120.58818 192.109.102.42.3306: P, cksum 0xd2f7 (correct), 65:86(21) ack 87 win 1460 nop,nop,timestamp 840173172 218564693 09:16:40.808077 IP (tos 0x38, ttl 64, id 32805, offset 0, flags [DF], proto: TCP (6), length: 140) 192.109.102.42.3306 62.193.238.120.58818: P 87:175(88) ack 86 win 1424 nop,nop,timestamp 218564697 840173172 09:16:40.847493 IP (tos 0x0, ttl 53, id 16211, offset 0, flags [DF], proto: TCP (6), length: 83) 62.193.238.120.58818 192.109.102.42.3306: P 86:117(31) ack 175 win 1460 nop,nop,timestamp 840173213 218564697 09:16:40.855500 IP (tos 0x38, ttl 64, id 32806, offset 0, flags [DF], proto: TCP (6), length: 124) 192.109.102.42.3306 62.193.238.120.58818: P 175:247(72) ack 117 win 1424 nop,nop,timestamp 218564701 840173213 09:16:40.855701 IP (tos 0x34, ttl 64, id 32807, offset 0, flags [DF], proto: TCP (6), length: 52) 192.109.102.42.3306 62.193.238.120.58818: F, cksum 0x2e46 (correct), 247:247(0) ack 117 win 1424 nop,nop,timestamp 218564701 840173213 09:16:40.896780 IP (tos 0x0, ttl 53, id 16212, offset 0, flags [DF], proto: TCP (6), length: 57) 62.193.238.120.58818 192.109.102.42.3306: P, cksum 0x2be4 (correct), 117:122(5) ack 247 win 1460 nop,nop,timestamp 840173263 218564701 09:16:40.896811 IP (tos 0x34, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 192.109.102.42.3306 62.193.238.120.58818: R, cksum 0x1f59 (correct), 3232139618:3232139618(0) win 0 09:16:40.897032 IP (tos 0x0, ttl 53, id 16213, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.58818 192.109.102.42.3306: F, cksum 0x2deb (correct), 122:122(0) ack 247 win 1460 nop,nop,timestamp 840173263 218564701 09:16:40.897058 IP (tos 0x34, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 192.109.102.42.3306 62.193.238.120.58818: R, cksum 0x1f59 (correct), 3232139618:3232139618(0) win 0 09:16:40.898497 IP (tos 0x0, ttl 53, id 16214, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.58818 192.109.102.42.3306: ., cksum 0x2de8 (correct), 123:123(0) ack 248 win 1460 nop,nop,timestamp 840173265 218564701 09:16:40.898517 IP (tos 0x34, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 192.109.102.42.3306 62.193.238.120.58818: R, cksum 0x1f58 (correct), 3232139619:3232139619(0) win 0 09:16:48.515549 IP
Re: Linux UDP Implementation
It seems that the implementation (at code level) does not match with the actual behaviour. I would like to seek expertise on clarifying my understanding in UDP implementation so that this phenomenon can be explained. How about you just add some printks or use a tool like systemtap to instrument the code path? That should give some insights what is actually going on. -Andi -- VGER BF report: U 0.473534 - 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] change netfilter tunables to __read_mostly
Brian Haley wrote: Sorry, next time I'll send them to you, or [EMAIL PROTECTED] netfilter-devel is better, that way other people working on netfilter get a chance to see it as well. I think only a handful of people on netfilter-devel also follow netdev. I'll cook-up another patch for the others you mentioned and send it out. Thanks. -- VGER BF report: H 1.86495e-12 - 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
[IPSEC]: searching SAD without assumming L3 details
Against net-2.6.19
signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
cheers,
jamal
Allow for searching the SAD from external data path points without
assumming L3 details. The only customer of this exposure currently
is pktgen.
---
commit 33d3060784e6aa55e30ae7d5efc491180e7f955d
tree 707017ff673d1161f46d69fd818035b6bc50bbdb
parent 0169ac1c2a64f04deeff3dae704f34e22ae59cb7
author Jamal Hadi Salim [EMAIL PROTECTED] Sat, 02 Sep 2006 09:38:12 -0400
committer Jamal Hadi Salim [EMAIL PROTECTED](none) Sat, 02 Sep 2006 09:38:12
-0400
include/net/xfrm.h|4
net/xfrm/xfrm_state.c | 33 +
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index bf8e2df..7b0ea47 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -895,6 +895,10 @@ extern struct xfrm_state *xfrm_state_fin
struct flowi *fl, struct xfrm_tmpl
*tmpl,
struct xfrm_policy *pol, int *err,
unsigned short family);
+extern struct xfrm_state * xfrm_stateonly_find(xfrm_address_t *daddr,
+xfrm_address_t *saddr,
+unsigned short family,
+u32 reqid, u8 mode, u8 proto);
extern int xfrm_state_check_expire(struct xfrm_state *x);
extern void xfrm_state_insert(struct xfrm_state *x);
extern int xfrm_state_add(struct xfrm_state *x);
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 9f63edd..2bfc04e 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -501,6 +501,39 @@ __xfrm_state_locate(struct xfrm_state *x
}
struct xfrm_state *
+xfrm_stateonly_find(xfrm_address_t *daddr, xfrm_address_t *saddr,
+ unsigned short family, u32 reqid, u8 mode, u8 proto)
+{
+ unsigned int h = xfrm_dst_hash(daddr, saddr, 0, family);
+ struct xfrm_state *rx = NULL, *x = NULL;
+ struct hlist_node *entry;
+
+ spin_lock(xfrm_state_lock);
+ hlist_for_each_entry(x, entry, xfrm_state_bydst+h, bydst) {
+ if (x-props.family == family
+ x-props.reqid == reqid
+ xfrm_state_addr_check(x, daddr, saddr, family)
+ mode == x-props.mode
+ proto == x-id.proto) {
+
+ if (x-km.state != XFRM_STATE_VALID)
+ continue;
+ else {
+ rx = x;
+ break;
+ }
+ }
+ }
+ spin_unlock(xfrm_state_lock);
+
+ if (rx)
+ xfrm_state_hold(rx);
+
+ return rx;
+}
+EXPORT_SYMBOL(xfrm_stateonly_find);
+
+struct xfrm_state *
xfrm_state_find(xfrm_address_t *daddr, xfrm_address_t *saddr,
struct flowi *fl, struct xfrm_tmpl *tmpl,
struct xfrm_policy *pol, int *err,
e1000 Detected Tx Unit Hang
I am getting e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang using stock 2.6.17.11, 2.6.17.5 or 2.6.17.4 kernels on centos 4.3. The server is a Tyan GS12 ( 82541GI/PI and 82547GI) and is connected to a Netgear GS724T Gig switch. I can easily reproduce the problem by trying to do a large ftp transfer to the server. It does not happen if the server is connected to a dummy 100 Mb switch, only when is connected to the Gig switch. I have also tried the options line below disabling tso, tx and rx in the modprobe.conf without any luck. options e1000 XsumRX=0 Speed=1000 Duplex=2 InterruptThrottleRate=0 FlowControl=3 RxDescriptors=4096 TxDescriptors=4096 RxIntDelay=0 TxIntDelay=0 in /var/log/kernel I get the following... Sep 1 23:53:01 www kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Sep 1 23:53:01 www kernel: Tx Queue 0 Sep 1 23:53:01 www kernel: TDH 4c4 Sep 1 23:53:01 www kernel: TDT 4c9 Sep 1 23:53:01 www kernel: next_to_use 4c9 Sep 1 23:53:01 www kernel: next_to_clean4c4 Sep 1 23:53:01 www kernel: buffer_info[next_to_clean] Sep 1 23:53:01 www kernel: time_stamp 9c60 Sep 1 23:53:01 www kernel: next_to_watch4c4 Sep 1 23:53:01 www kernel: jiffies 9d96 Sep 1 23:53:01 www kernel: next_to_watch.status 0 . repeats the same as above a few times . Sep 1 23:53:10 www kernel: NETDEV WATCHDOG: eth0: transmit timed out Sep 1 23:53:13 www kernel: e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex then the server locks up, no response from the keyboard at all and must be forced down with a power kill. The suggested tips on how to deal with this issue are not working so if I can help troubleshoot this let me know. Here is my system info, driver: e1000 version: 7.0.33-k2-NAPI firmware-version: N/A bus-info: :02:01.0 lspci -vv output below.. 00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub (rev 02) Subsystem: Intel Corporation 82875P/E7210 Memory Controller Hub Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Region 0: Memory at 9000 (32-bit, prefetchable) [size=128M] Capabilities: [e4] Vendor Specific Information Capabilities: [a0] AGP version 3.0 Status: RQ=32 Iso- ArqSz=2 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=none 00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller (rev 02) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Secondary status: 66Mhz+ FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- 00:03.0 PCI bridge: Intel Corporation 82875P/E7210 Processor to PCI to CSA Bridge (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 2000-2fff Memory behind bridge: fc10-fc1f Secondary status: 66Mhz+ FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation: Unknown device 24c0 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to IRQ 18 Region 4: I/O ports at 1400 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation: Unknown device 24c0 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin B routed to IRQ 19 Region 4: I/O ports at 1420 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev
[XFRM]: Fix wildcard as tunnel source
[XFRM]: Fix wildcard as tunnel source
Hashing SAs by source address breaks templates with wildcards as tunnel
source. Remove saddr from the hash key.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 19f7b6f33c0e9fbdf23a33506c2dfc0706b0c731
tree bca60eb94c50fcd66673bd87823fd38364b45b55
parent 6ddbd02eb61532f9af4f28912a09717ab8c71d8a
author Patrick McHardy [EMAIL PROTECTED] Sat, 02 Sep 2006 16:43:39 +0200
committer Patrick McHardy [EMAIL PROTECTED] Sat, 02 Sep 2006 16:43:39 +0200
net/xfrm/xfrm_hash.h |8
net/xfrm/xfrm_state.c | 17 +++--
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/net/xfrm/xfrm_hash.h b/net/xfrm/xfrm_hash.h
index d3abb0b..deb18ce 100644
--- a/net/xfrm/xfrm_hash.h
+++ b/net/xfrm/xfrm_hash.h
@@ -25,17 +25,17 @@ static inline unsigned int __xfrm6_daddr
saddr-a6[2] ^ saddr-a6[3]);
}
-static inline unsigned int __xfrm_dst_hash(xfrm_address_t *daddr,
xfrm_address_t *saddr,
- u32 reqid, unsigned short family,
+static inline unsigned int __xfrm_dst_hash(xfrm_address_t *daddr, u32 reqid,
+ unsigned short family,
unsigned int hmask)
{
unsigned int h = family ^ reqid;
switch (family) {
case AF_INET:
- h ^= __xfrm4_daddr_saddr_hash(daddr, saddr);
+ h ^= __xfrm4_addr_hash(daddr);
break;
case AF_INET6:
- h ^= __xfrm6_daddr_saddr_hash(daddr, saddr);
+ h ^= __xfrm6_addr_hash(daddr);
break;
}
return (h ^ (h 16)) hmask;
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 9f63edd..0c26a1f 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -56,11 +56,10 @@ static unsigned int xfrm_state_num;
static unsigned int xfrm_state_genid;
static inline unsigned int xfrm_dst_hash(xfrm_address_t *daddr,
-xfrm_address_t *saddr,
u32 reqid,
unsigned short family)
{
- return __xfrm_dst_hash(daddr, saddr, reqid, family, xfrm_state_hmask);
+ return __xfrm_dst_hash(daddr, reqid, family, xfrm_state_hmask);
}
static inline unsigned int xfrm_src_hash(xfrm_address_t *addr,
@@ -87,9 +86,8 @@ static void xfrm_hash_transfer(struct hl
hlist_for_each_entry_safe(x, entry, tmp, list, bydst) {
unsigned int h;
- h = __xfrm_dst_hash(x-id.daddr, x-props.saddr,
- x-props.reqid, x-props.family,
- nhashmask);
+ h = __xfrm_dst_hash(x-id.daddr, x-props.reqid,
+ x-props.family, nhashmask);
hlist_add_head(x-bydst, ndsttable+h);
h = __xfrm_src_hash(x-props.saddr, x-props.family,
@@ -506,7 +504,7 @@ xfrm_state_find(xfrm_address_t *daddr, x
struct xfrm_policy *pol, int *err,
unsigned short family)
{
- unsigned int h = xfrm_dst_hash(daddr, saddr, tmpl-reqid, family);
+ unsigned int h = xfrm_dst_hash(daddr, tmpl-reqid, family);
struct hlist_node *entry;
struct xfrm_state *x, *x0;
int acquire_in_progress = 0;
@@ -615,8 +613,7 @@ static void __xfrm_state_insert(struct x
x-genid = ++xfrm_state_genid;
- h = xfrm_dst_hash(x-id.daddr, x-props.saddr,
- x-props.reqid, x-props.family);
+ h = xfrm_dst_hash(x-id.daddr, x-props.reqid, x-props.family);
hlist_add_head(x-bydst, xfrm_state_bydst+h);
h = xfrm_src_hash(x-props.saddr, x-props.family);
@@ -652,7 +649,7 @@ static void __xfrm_state_bump_genids(str
struct hlist_node *entry;
unsigned int h;
- h = xfrm_dst_hash(xnew-id.daddr, xnew-props.saddr, reqid, family);
+ h = xfrm_dst_hash(xnew-id.daddr, reqid, family);
hlist_for_each_entry(x, entry, xfrm_state_bydst+h, bydst) {
if (x-props.family == family
x-props.reqid == reqid
@@ -674,7 +671,7 @@ EXPORT_SYMBOL(xfrm_state_insert);
/* xfrm_state_lock is held */
static struct xfrm_state *__find_acq_core(unsigned short family, u8 mode, u32
reqid, u8 proto, xfrm_address_t *daddr, xfrm_address_t *saddr, int create)
{
- unsigned int h = xfrm_dst_hash(daddr, saddr, reqid, family);
+ unsigned int h = xfrm_dst_hash(daddr, reqid, family);
struct hlist_node *entry;
struct xfrm_state *x;
Re: [IPSEC]: searching SAD without assumming L3 details
On Sat, 2 Sep 2006, jamal wrote:
Against net-2.6.19
signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
+xfrm_stateonly_find(xfrm_address_t *daddr, xfrm_address_t *saddr,
+ unsigned short family, u32 reqid, u8 mode, u8 proto)
+{
+ unsigned int h = xfrm_dst_hash(daddr, saddr, 0, family);
+ struct xfrm_state *rx = NULL, *x = NULL;
+ struct hlist_node *entry;
+
+ spin_lock(xfrm_state_lock);
Shouldn't this be spin_lock_bh()?
+ spin_unlock(xfrm_state_lock);
+
+ if (rx)
+ xfrm_state_hold(rx);
I think you need to grab the reference before letting go of the lock.
Can you please include patches inline, or tell me how to get pine to
quote attachments? :-)
--
James Morris
[EMAIL PROTECTED]
--
VGER BF report: U 0.5
-
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: [IPSEC]: searching SAD without assumming L3 details
On Sat, 2006-02-09 at 11:04 -0400, James Morris wrote:
On Sat, 2 Sep 2006, jamal wrote:
+
+ spin_lock(xfrm_state_lock);
Shouldn't this be spin_lock_bh()?
+ spin_unlock(xfrm_state_lock);
+
the call is made at the moment only by pktgen (kernel threads on
dev_queue_xmit level contending with softirqs essentially). I think
(although havent tried) the spin_{un}lock_bh() wont work. Thoughts?
Obviously the easy thing for me to do is change it and see what
happens;-
+ if (rx)
+ xfrm_state_hold(rx);
I think you need to grab the reference before letting go of the lock.
I believe you are right. I will make the change, retest and repost.
Can you please include patches inline, or tell me how to get pine to
quote attachments? :-)
I could get evolution to inline attachments although last time i tried
it made Dave unhappy with not being to use git am or some such
reason ;- I think some white spaces get added or some other mangling
happens.
I could try it on the repost.
Thanks for the comments James.
cheers,
jamal
--
VGER BF report: U 0.55
-
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: ProxyARP and IPSec
Stephen J. Bevan wrote: H. Peter Anvin writes: Fair enough. However, that does beg a question: is there any sane way to create the pseudo-device model on top of the current model, as a convenience layer? That way you could get the best of both. I assume you were using tunnel-mode IPsec and depending on exactly what you want to do you may be able to replace it with transport mode IPsec (or stay with tunnel if the extra 20 bytes of IP is not a problem) to handle host-host IPsec and use gre or ipip for overlay network. That way you get a virtual device (gre or ipip) you can route to, run OSPF on, ... etc. sarcasm What I great idea. Now I just have to get every host I want to interoperate with to support a nonstandard configuration. The scary part is that if I motivate it with Linux is too stupid to handle standard tunnel-mode IPsec I might actually get away with it. /sarcasm Really... if saying our configuration is so screwed up that we have to run a different over-wire protocol isn't an admission of failure I don't know what is. I suspect this contributes to the growth in OpenVPN as well. -hpa -- VGER BF report: U 0.53 - 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: [IPSEC]: searching SAD without assumming L3 details
On Sat, 2006-02-09 at 13:16 -0400, jamal wrote:
the call is made at the moment only by pktgen (kernel threads on
dev_queue_xmit level contending with softirqs essentially). I think
(although havent tried) the spin_{un}lock_bh() wont work. Thoughts?
Obviously the easy thing for me to do is change it and see what
happens;-
Both your suggestions work. Should i instead just use read_{un}lock_bh?
All i am doing is scanning to find the state.
cheers,
jamal
--
VGER BF report: U 0.502731
-
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: [IPSEC]: searching SAD without assumming L3 details
On Sat, 2 Sep 2006, jamal wrote:
On Sat, 2006-02-09 at 11:04 -0400, James Morris wrote:
On Sat, 2 Sep 2006, jamal wrote:
+
+ spin_lock(xfrm_state_lock);
Shouldn't this be spin_lock_bh()?
+ spin_unlock(xfrm_state_lock);
+
the call is made at the moment only by pktgen (kernel threads on
dev_queue_xmit level contending with softirqs essentially). I think
(although havent tried) the spin_{un}lock_bh() wont work. Thoughts?
If bh's are already disabled when you call this, it'll be ok, but as this
will be a generally exported function, I'd suggest using bh locking. I
guess you could also make a xfrm_stateonly_find_bh() to be called only
with bh's disabled, if needed.
- James
--
James Morris
[EMAIL PROTECTED]
--
VGER BF report: U 0.523211
-
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
2.6.18-rc5 + pata-drivers on MSI K9N Ultra report, AMD64
Hi, Keywords: nForce PCIe, forcedeth, nForce PATA, Radeon DRM, ALC883 HDA sound FYI: running 2.6.18-rc5 + pata-drivers on MSI mb K9N Ultra (NVidia MCP55, PCIe, Athlon64, x86_64, no SMP, no preempt) gives the following (all details available on request, of course): Nvidia board detected. Ignoring ACPI timer override. I don't know if it should be ignored or not, anymore. It's probably ok. PCI: Setting latency timer of device :00:0b.0 to 64 pcie_portdrv_probe-Dev[0374:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[:00:0b.0:pcie00] PCI: Setting latency timer of device :00:0c.0 to 64 pcie_portdrv_probe-Dev[0374:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[:00:0c.0:pcie00] PCI: Setting latency timer of device :00:0d.0 to 64 pcie_portdrv_probe-Dev[0378:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[:00:0d.0:pcie00] PCI: Setting latency timer of device :00:0e.0 to 64 pcie_portdrv_probe-Dev[0375:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[:00:0e.0:pcie00] PCI: Setting latency timer of device :00:0f.0 to 64 pcie_portdrv_probe-Dev[0377:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[:00:0f.0:pcie00] The above seem to be some PCIe bridges. ata1 and ata2 are SATA. ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14 ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 There is no secondary IDE connector on this motherboard, I think it's just disabled by BIOS. scsi3 : pata_amd ata4: port is slow to respond, please be patient ata4: port failed to respond (30 secs) ata4: SRST failed (status 0xFF) ata4: SRST failed (err_mask=0x100) ata4: softreset failed, retrying in 5 secs ata4: SRST failed (status 0xFF) ata4: SRST failed (err_mask=0x100) ata4: softreset failed, retrying in 5 secs ata4: SRST failed (status 0xFF) ata4: SRST failed (err_mask=0x100) ata4: reset failed, giving up While not a big problem, the above sequence takes 40 seconds while booting. hda_codec: Unknown model for ALC883, trying auto-probe from BIOS... ALSA device list: #0: HDA NVidia at 0xfeaf4000 irq 233 eth0: forcedeth.c: subsystem: 01462:7250 bound to :00:08.0 eth1: forcedeth.c: subsystem: 01462:7250 bound to :00:09.0 BUG: warning at /usr/src/linux-2.6/kernel/lockdep.c:1803/trace_hardirqs_on() Call Trace: IRQ [80298395] trace_hardirqs_on+0xc5/0x150 [8026522b] _spin_unlock_irq+0x2b/0x40 [8800186e] :forcedeth:nv_nic_irq_tx+0x7e/0x130 [8020fb6c] handle_IRQ_event+0x2c/0x70 [802a4154] __do_IRQ+0xc4/0x140 [8026aedd] do_IRQ+0xfd/0x110 [8025fdba] ret_from_intr+0x0/0xf EOI [8026522b] _spin_unlock_irq+0x2b/0x40 [80265230] _spin_unlock_irq+0x30/0x40 [80234fc9] do_setitimer+0x159/0x480 [8026489f] trace_hardirqs_on_thunk+0x35/0x37 [80284955] alarm_setitimer+0x35/0x60 [802896c9] sys_alarm+0x9/0x10 [80261100] cstar_do_call+0x1b/0x6f [drm] Initialized radeon 1.25.0 20060524 on minor 0 [drm:radeon_do_init_cp] *ERROR* Cannot initialise DRM on this card This card requires a new X.org DDX Apparently IA32 emulation doesn't work for radeon_cp_setparam(DRM_IOCTL_ARGS) - RADEON_SETPARAM_NEW_MEMMAP (32-bit kernel doesn't have this problem). $ /sbin/lspci 00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2) 00:01.2 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2) 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:06.0 PCI bridge: nVidia Corporation Unknown device 0370 (rev a2) 00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) 00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) 00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) 00:0b.0 PCI bridge: nVidia Corporation Unknown device 0374 (rev a2) 00:0c.0 PCI bridge: nVidia Corporation Unknown device 0374 (rev a2) 00:0d.0 PCI bridge: nVidia Corporation Unknown device 0378 (rev a2) 00:0e.0 PCI bridge: nVidia Corporation Unknown device 0375 (rev a2) 00:0f.0 PCI bridge: nVidia Corporation Unknown device 0377 (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:02.0 Multimedia audio controller: Creative Labs SB
2.6.18-rc5 with GRE, iptables and Speedtouch ADSL, PPP over ATM
Hi,
FYI: Just enabled kernel lock testers on my old laptop machine
doing internet services. 2.6.18-rc5, i686. All details available
on request, of course.
There is IP GRE tunnel here running over ADSL connection (USB
Thomson/Alcatel Speedtouch 330, PPP over ATM, in-kernel drivers).
Ethernet is DLink Tulip-based (PC Card 32-bit), probably not
relevant here. Iptables doing mostly ACCEPTs, REJECT and DROPs in
INPUT and FORWARD, there is also MASQUERADE but it probably doesn't
matter. Few ip rules directing some traffic to the GRE tunnel as well.
===
[ INFO: possible circular locking dependency detected ]
---
swapper/0 is trying to acquire lock:
(dev-queue_lock){-+..}, at: [c02c8c46] dev_queue_xmit+0x56/0x290
but task is already holding lock:
(dev-_xmit_lock){-+..}, at: [c02c8e14] dev_queue_xmit+0x224/0x290
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #1 (dev-_xmit_lock){-+..}:
[c012e7b6] lock_acquire+0x76/0xa0
[c0336241] _spin_lock_bh+0x31/0x40
[c02d25a9] dev_activate+0x69/0x120
[c02c8149] dev_open+0x59/0x70
[c02c6921] dev_change_flags+0x51/0x110
[c0302464] devinet_ioctl+0x484/0x670
[c030295b] inet_ioctl+0x6b/0x80
[c02bc6e8] sock_ioctl+0x118/0x200
[c01698b0] do_ioctl+0x20/0x70
[c0169957] vfs_ioctl+0x57/0x290
[c0169bc9] sys_ioctl+0x39/0x60
[c0102c8d] sysenter_past_esp+0x56/0x8d
- #0 (dev-queue_lock){-+..}:
[c012e7b6] lock_acquire+0x76/0xa0
[c03361fc] _spin_lock+0x2c/0x40
[c02c8c46] dev_queue_xmit+0x56/0x290
[c02e2cfd] ip_output+0x1ad/0x250
[c883dea2] ipgre_tunnel_xmit+0x412/0x740 [ip_gre]
[c02c73db] dev_hard_start_xmit+0x1bb/0x220
[c02c8e2b] dev_queue_xmit+0x23b/0x290
[c02e2cfd] ip_output+0x1ad/0x250
[c03142bc] reject+0x37c/0x6d0
[c0313688] ipt_do_table+0x2b8/0x330
[c03137b7] ipt_hook+0x27/0x30
[c02d6529] nf_iterate+0x59/0x80
[c02d667a] nf_hook_slow+0x4a/0xc0
[c02ddb55] ip_local_deliver+0x175/0x1c0
[c02dd7bc] ip_rcv+0x25c/0x480
[c02c705e] netif_receive_skb+0x15e/0x1e0
[c02c8922] process_backlog+0x82/0x110
[c02c8a22] net_rx_action+0x72/0x120
[c01194b5] __do_softirq+0x55/0xc0
[c0104b13] do_softirq+0x63/0xd0
other info that might help us debug this:
2 locks held by swapper/0:
#0: (table-lock){-.-+}, at: [c0313421] ipt_do_table+0x51/0x330
#1: (dev-_xmit_lock){-+..}, at: [c02c8e14] dev_queue_xmit+0x224/0x290
stack backtrace:
[c0103522] show_trace+0x12/0x20
[c0103b79] dump_stack+0x19/0x20
[c012d6c1] print_circular_bug_tail+0x61/0x70
[c012e196] __lock_acquire+0xac6/0xd70
[c012e7b6] lock_acquire+0x76/0xa0
[c03361fc] _spin_lock+0x2c/0x40
[c02c8c46] dev_queue_xmit+0x56/0x290
[c02e2cfd] ip_output+0x1ad/0x250
[c883dea2] ipgre_tunnel_xmit+0x412/0x740 [ip_gre]
[c02c73db] dev_hard_start_xmit+0x1bb/0x220
[c02c8e2b] dev_queue_xmit+0x23b/0x290
[c02e2cfd] ip_output+0x1ad/0x250
[c03142bc] reject+0x37c/0x6d0
[c0313688] ipt_do_table+0x2b8/0x330
[c03137b7] ipt_hook+0x27/0x30
[c02d6529] nf_iterate+0x59/0x80
[c02d667a] nf_hook_slow+0x4a/0xc0
[c02ddb55] ip_local_deliver+0x175/0x1c0
[c02dd7bc] ip_rcv+0x25c/0x480
[c02c705e] netif_receive_skb+0x15e/0x1e0
[c02c8922] process_backlog+0x82/0x110
[c02c8a22] net_rx_action+0x72/0x120
[c01194b5] __do_softirq+0x55/0xc0
[c0104b13] do_softirq+0x63/0xd0
===
[c0119395] irq_exit+0x35/0x40
[c0104c0f] do_IRQ+0x8f/0xf0
[c0102ef9] common_interrupt+0x25/0x2c
[c01018e9] cpu_idle+0x39/0x50
[c010052e] rest_init+0x1e/0x30
[c041f76e] start_kernel+0x25e/0x2c0
[c0100199] 0xc0100199
--
Krzysztof Halasa
--
VGER BF report: U 0.5
-
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: ProxyARP and IPSec
sarcasm What I great idea. Now I just have to get every host I want to interoperate with to support a nonstandard configuration. The scary part is that if I motivate it with Linux is too stupid to handle standard tunnel-mode IPsec I might actually get away with it. /sarcasm Linux handles tunnel-mode IPsec in the same way that most IPsec vendors did and many still do. For example, Cisco IOS has pages and pages of documentation about how to combine IPsec with GRE in order to support securely running OSPF between sites, precisely because its IPsec didn't offer a virtual interface. However, Cisco (along with Netscreen/Juniper and Fortinet) now additionally support IPsec that uses a virtual interface and so you have a choice of using an interface or not as you see fit. I would be useful if Linux offered the option but code talks and I'm not offering a patch so I'm not in a position to complain about what Linux currently supports. Really... if saying our configuration is so screwed up that we have to run a different over-wire protocol isn't an admission of failure I don't If you use ipip the over-wire protocol is identical, see RFC 3884 section 3.1 or you can test it right now using manual keying (remote side uses tunnel mode, your side uses transport + ipip). To use IKE pluto would need to be hacked a bit, though most of the changes could be handled via a updown script. know what is. I suspect this contributes to the growth in OpenVPN as well. Haven't you heard, SSL based VPNs are the future :-) -- VGER BF report: U 0.947229 - 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: 2.6.18-rc5 + pata-drivers on MSI K9N Ultra report, AMD64
Ar Sad, 2006-09-02 am 22:14 +0200, ysgrifennodd Krzysztof Halasa: ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14 ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 There is no secondary IDE connector on this motherboard, I think it's just disabled by BIOS. Its there if it got that far. May not be wired. scsi3 : pata_amd ata4: port is slow to respond, please be patient ata4: port failed to respond (30 secs) Please send me an lspci -vxxx. This might be BIOS or might be us misparsing disable/enable bits. -- VGER BF report: U 0.5 - 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: 2.6.18-rc5 with GRE, iptables and Speedtouch ADSL, PPP over ATM
Krzysztof Halasa [EMAIL PROTECTED] :
[...]
===
[ INFO: possible circular locking dependency detected ]
---
swapper/0 is trying to acquire lock:
(dev-queue_lock){-+..}, at: [c02c8c46] dev_queue_xmit+0x56/0x290
but task is already holding lock:
(dev-_xmit_lock){-+..}, at: [c02c8e14] dev_queue_xmit+0x224/0x290
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #1 (dev-_xmit_lock){-+..}:
[c012e7b6] lock_acquire+0x76/0xa0
[c0336241] _spin_lock_bh+0x31/0x40
[c02d25a9] dev_activate+0x69/0x120
[...]
[c0169957] vfs_ioctl+0x57/0x290
[c0169bc9] sys_ioctl+0x39/0x60
[c0102c8d] sysenter_past_esp+0x56/0x8d
- #0 (dev-queue_lock){-+..}:
[c012e7b6] lock_acquire+0x76/0xa0
[c03361fc] _spin_lock+0x2c/0x40
[c02c8c46] dev_queue_xmit+0x56/0x290
[...]
[c01194b5] __do_softirq+0x55/0xc0
[c0104b13] do_softirq+0x63/0xd0
dev_activate takes BH disabling locks only. How could a softirq happen
on the same cpu and trigger a deadlock ?
--
Ueimor
--
VGER BF report: U 0.500151
-
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
neigh_lookup lockdep warning
Seen during boot of a 2.6.18rc5-git1 based kernel.
Dave
===
[ INFO: possible circular locking dependency detected ]
2.6.17-1.2608.fc6 #1
---
swapper/0 is trying to acquire lock:
(tbl-lock){-+-+}, at: [c05bdf97] neigh_lookup+0x50/0xaf
but task is already holding lock:
(list-lock#3){-+..}, at: [c05bf677] neigh_proxy_process+0x20/0xc2
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #2 (list-lock#3){-+..}:
[c043c09a] lock_acquire+0x4b/0x6d
[c061411f] _spin_lock_irqsave+0x22/0x32
[c05b451f] skb_dequeue+0x12/0x43
[c05b523a] skb_queue_purge+0x14/0x1b
[c05be990] neigh_update+0x34a/0x3a6
[c05f0f6e] arp_process+0x4ad/0x4e7
[c05f107c] arp_rcv+0xd4/0xf1
[c05b942c] netif_receive_skb+0x205/0x274
[c7bb0566] rhine_napipoll+0x28d/0x449 [via_rhine]
[c05baf73] net_rx_action+0x9d/0x196
[c04293a7] __do_softirq+0x78/0xf2
[c0406673] do_softirq+0x5a/0xbe
- #1 (n-lock){-+..}:
[c043c09a] lock_acquire+0x4b/0x6d
[c0613e48] _write_lock+0x19/0x28
[c05bfc69] neigh_periodic_timer+0x98/0x13c
[c042dc58] run_timer_softirq+0x108/0x167
[c04293a7] __do_softirq+0x78/0xf2
[c0406673] do_softirq+0x5a/0xbe
- #0 (tbl-lock){-+-+}:
[c043c09a] lock_acquire+0x4b/0x6d
[c0613f02] _read_lock_bh+0x1e/0x2d
[c05bdf97] neigh_lookup+0x50/0xaf
[c05bf0b9] neigh_event_ns+0x2c/0x77
[c05f0e2a] arp_process+0x369/0x4e7
[c05f10a1] parp_redo+0x8/0xa
[c05bf6bd] neigh_proxy_process+0x66/0xc2
[c042dc58] run_timer_softirq+0x108/0x167
[c04293a7] __do_softirq+0x78/0xf2
[c0406673] do_softirq+0x5a/0xbe
other info that might help us debug this:
1 lock held by swapper/0:
#0: (list-lock#3){-+..}, at: [c05bf677] neigh_proxy_process+0x20/0xc2
stack backtrace:
[c04051ee] show_trace_log_lvl+0x58/0x159
[c04057ea] show_trace+0xd/0x10
[c0405903] dump_stack+0x19/0x1b
[c043b182] print_circular_bug_tail+0x59/0x64
[c043b99a] __lock_acquire+0x80d/0x99c
[c043c09a] lock_acquire+0x4b/0x6d
[c0613f02] _read_lock_bh+0x1e/0x2d
[c05bdf97] neigh_lookup+0x50/0xaf
[c05bf0b9] neigh_event_ns+0x2c/0x77
[c05f0e2a] arp_process+0x369/0x4e7
[c05f10a1] parp_redo+0x8/0xa
[c05bf6bd] neigh_proxy_process+0x66/0xc2
[c042dc58] run_timer_softirq+0x108/0x167
[c04293a7] __do_softirq+0x78/0xf2
[c0406673] do_softirq+0x5a/0xbe
[c0429250] irq_exit+0x3d/0x3f
[c0417cbf] smp_apic_timer_interrupt+0x79/0x7e
[c0404b0a] apic_timer_interrupt+0x2a/0x30
DWARF2 unwinder stuck at apic_timer_interrupt+0x2a/0x30
Leftover inexact backtrace:
--
http://www.codemonkey.org.uk
--
VGER BF report: U 0.489161
-
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
BUG in bcm32xx-d80211: sleeping function called with irq's disabled
The latest git pull from wireless-dev (g7844a579) is calling a sleeping function with irq's disabled. The kernel is a UP version with preemption disabled. The dump is as follows: kernel: bcm43xx_d80211: Virtual interface added (type: 0x0002, ID: 4, MAC: 00:06:25:40:6f:03) kernel: bcm43xx_d80211: PHY connected kernel: BUG: sleeping function called from invalid context at kernel/mutex.c:86 kernel: in_atomic():0, irqs_disabled():1 kernel: [c0103b67] show_trace_log_lvl+0x197/0x1c0 kernel: [c0104f7b] show_trace+0x1b/0x20 kernel: [c0104fa6] dump_stack+0x26/0x30 kernel: [c0113382] __might_sleep+0xa2/0xc0 kernel: [c031347d] mutex_lock+0x1d/0x30 kernel: [e791c72a] ssb_core_is_enabled+0x1a/0x50 [ssb] kernel: [e7b2797d] bcm43xx_wireless_core_reset+0x1d/0xc0 [bcm43xx_d80211] kernel: [e7b3bd74] bcm43xx_phy_calibrate+0x74/0xe0 [bcm43xx_d80211] kernel: [e7b2bbdb] wireless_core_up+0x5b/0x700 [bcm43xx_d80211] kernel: [e7b2c98a] bcm43xx_select_wireless_core+0x22a/0x8c0 [bcm43xx_d80211] kernel: [e7b2d0a4] bcm43xx_init_board+0x84/0xb0 [bcm43xx_d80211] kernel: [e7b2d1a6] bcm43xx_net_open+0x16/0x20 [bcm43xx_d80211] kernel: [e79481c5] ieee80211_open+0x175/0x360 [80211] kernel: [c02c2233] dev_open+0x43/0x90 kernel: [c02c11c5] dev_change_flags+0x55/0x130 kernel: [c03006af] devinet_ioctl+0x65f/0x6d0 kernel: [c0300a18] inet_ioctl+0x88/0xb0 kernel: [c02b64cb] sock_ioctl+0xbb/0x260 kernel: [c01718db] do_ioctl+0x2b/0x80 kernel: [c0171981] vfs_ioctl+0x51/0x290 kernel: [c0171c01] sys_ioctl+0x41/0x60 kernel: [c0103005] sysenter_past_esp+0x56/0x8d kernel: [b7f35410] 0xb7f35410 kernel: [c0104f7b] show_trace+0x1b/0x20 kernel: [c0104fa6] dump_stack+0x26/0x30 kernel: [c0113382] __might_sleep+0xa2/0xc0 kernel: [c031347d] mutex_lock+0x1d/0x30 kernel: [e791c72a] ssb_core_is_enabled+0x1a/0x50 [ssb] kernel: [e7b2797d] bcm43xx_wireless_core_reset+0x1d/0xc0 [bcm43xx_d80211] kernel: [e7b3bd74] bcm43xx_phy_calibrate+0x74/0xe0 [bcm43xx_d80211] kernel: [e7b2bbdb] wireless_core_up+0x5b/0x700 [bcm43xx_d80211] kernel: [e7b2c98a] bcm43xx_select_wireless_core+0x22a/0x8c0 [bcm43xx_d80211] kernel: [e7b2d0a4] bcm43xx_init_board+0x84/0xb0 [bcm43xx_d80211] kernel: [e7b2d1a6] bcm43xx_net_open+0x16/0x20 [bcm43xx_d80211] kernel: [e79481c5] ieee80211_open+0x175/0x360 [80211] kernel: [c02c2233] dev_open+0x43/0x90 kernel: [c02c11c5] dev_change_flags+0x55/0x130 kernel: [c03006af] devinet_ioctl+0x65f/0x6d0 kernel: [c0300a18] inet_ioctl+0x88/0xb0 kernel: [c02b64cb] sock_ioctl+0xbb/0x260 kernel: [c01718db] do_ioctl+0x2b/0x80 kernel: [c0171981] vfs_ioctl+0x51/0x290 kernel: [c0171c01] sys_ioctl+0x41/0x60 kernel: [c0103005] sysenter_past_esp+0x56/0x8d kernel: bcm43xx_d80211: PHY disconnected -- VGER BF report: U 0.500028 - 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
