* [PATCH v2] netfilter: ebtables: Use %pM conversion specifier
From: Tobias Klauser @ 2009-07-16 7:25 UTC (permalink / raw)
To: bart.de.schuymer, shemminger, kaber, davem, netfilter-devel
Cc: netdev, Tobias Klauser
In-Reply-To: <1247655306-21337-1-git-send-email-klto@zhaw.ch>
ebt_log uses its own implementation of print_mac to print MAC addresses.
This patch converts it to use the %pM conversion specifier for printk.
Signed-off-by: Tobias Klauser <klto@zhaw.ch>
---
net/bridge/netfilter/ebt_log.c | 29 +++++++----------------------
1 files changed, 7 insertions(+), 22 deletions(-)
diff --git a/net/bridge/netfilter/ebt_log.c b/net/bridge/netfilter/ebt_log.c
index a94f3cc..e4ea3fd 100644
--- a/net/bridge/netfilter/ebt_log.c
+++ b/net/bridge/netfilter/ebt_log.c
@@ -50,14 +50,6 @@ struct arppayload
unsigned char ip_dst[4];
};
-static void print_MAC(const unsigned char *p)
-{
- int i;
-
- for (i = 0; i < ETH_ALEN; i++, p++)
- printk("%02x%c", *p, i == ETH_ALEN - 1 ? ' ':':');
-}
-
static void
print_ports(const struct sk_buff *skb, uint8_t protocol, int offset)
{
@@ -88,14 +80,11 @@ ebt_log_packet(u_int8_t pf, unsigned int hooknum,
unsigned int bitmask;
spin_lock_bh(&ebt_log_lock);
- printk("<%c>%s IN=%s OUT=%s MAC source = ", '0' + loginfo->u.log.level,
- prefix, in ? in->name : "", out ? out->name : "");
-
- print_MAC(eth_hdr(skb)->h_source);
- printk("MAC dest = ");
- print_MAC(eth_hdr(skb)->h_dest);
-
- printk("proto = 0x%04x", ntohs(eth_hdr(skb)->h_proto));
+ printk("<%c>%s IN=%s OUT=%s MAC source = %pM MAC dest = %pM proto = 0x%04x",
+ '0' + loginfo->u.log.level, prefix,
+ in ? in->name : "", out ? out->name : "",
+ eth_hdr(skb)->h_source, eth_hdr(skb)->h_dest,
+ ntohs(eth_hdr(skb)->h_proto));
if (loginfo->type == NF_LOG_TYPE_LOG)
bitmask = loginfo->u.log.logflags;
@@ -171,12 +160,8 @@ ebt_log_packet(u_int8_t pf, unsigned int hooknum,
printk(" INCOMPLETE ARP payload");
goto out;
}
- printk(" ARP MAC SRC=");
- print_MAC(ap->mac_src);
- printk(" ARP IP SRC=%pI4", ap->ip_src);
- printk(" ARP MAC DST=");
- print_MAC(ap->mac_dst);
- printk(" ARP IP DST=%pI4", ap->ip_dst);
+ printk(" ARP MAC SRC=%pM ARP IP SRC=%pI4 ARP MAC DST=%pM ARP IP DST=%pI4",
+ ap->mac_src, ap->ip_src, ap->mac_dst, ap->ip_dst);
}
}
out:
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] netfilter: ebtables: Use print_mac instead of own function
From: Tobias Klauser @ 2009-07-16 7:25 UTC (permalink / raw)
To: Patrick McHardy
Cc: bart.de.schuymer, shemminger, davem, ebtables-devel,
netfilter-devel, netdev
In-Reply-To: <4A5DF1FC.3050404@trash.net>
On 07/15/2009 05:13 PM, Patrick McHardy wrote:
> Tobias Klauser wrote:
>> ebt_log uses its own implementation of print_mac to print MAC addresses.
>> This patch converts it to use print_mac from linux/if_ether.h
>
> You can do this even simpler by using %pM as format string.
Sorry, I didn't know about that one. I'll send an updated patch.
Thanks for the hint.
Tobias
^ permalink raw reply
* Re: [PATCH] USB host CDC Phonet network interface driver
From: Rémi Denis-Courmont @ 2009-07-16 7:12 UTC (permalink / raw)
To: ext Oliver Neukum; +Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <200907151620.31509.oliver@neukum.org>
On Wednesday 15 July 2009 17:20:31 ext Oliver Neukum wrote:
> Am Mittwoch, 15. Juli 2009 15:59:01 schrieb Rémi Denis-Courmont:
>
> Hello,
>
> > + netif_stop_queue(dev);
> > + if (atomic_inc_return(&pnd->tx_queue) < dev->tx_queue_len)
> > + netif_wake_queue(dev);
>
> This is unelegant.
But I cannot think of any alternative that would not involve a spin lock and
disable IRQs. There is a race between qdisc and USB TX completion here.
I'm not sure what you're trying to suggest...?
> > +static void usbpn_disconnect(struct usb_interface *intf)
> > +{
> > + struct usbpn_dev *pnd = usb_get_intfdata(intf);
> > +
>
> What happens if this happens in the unexpected order?
Right, the data interface gets released twice. This "works" since
usb_driver_release_interface() has an explicit check. I will try to clean it
up anyway.
> > + if (intf != pnd->data_intf) {
> > + usb_driver_release_interface(&usbpn_driver, pnd->data_intf);
> > + return;
> > + }
> > +
> > + unregister_netdev(pnd->dev);
> > + usb_put_dev(pnd->usb);
> > +}
Thanks for the review.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* Re: [Bugme-new] [Bug 13553] New: When NETCONSOLE is enabled inkernel, computer crashes after 120seconds (approx)
From: David Hill @ 2009-07-16 5:42 UTC (permalink / raw)
To: Neil Horman, Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20090624010501.GB27384@localhost.localdomain>
Will try that in the next few days... sorry for the delay. I was on
vacation for the last 2 weeks and thus, out of town :D
----- Original Message -----
From: "Neil Horman" <nhorman@tuxdriver.com>
To: "Andrew Morton" <akpm@linux-foundation.org>
Cc: <netdev@vger.kernel.org>; <bugzilla-daemon@bugzilla.kernel.org>;
<bugme-daemon@bugzilla.kernel.org>; <hilld@binarystorm.net>
Sent: Tuesday, June 23, 2009 9:05 PM
Subject: Re: [Bugme-new] [Bug 13553] New: When NETCONSOLE is enabled
inkernel, computer crashes after 120seconds (approx)
> On Tue, Jun 23, 2009 at 02:07:43PM -0700, Andrew Morton wrote:
>>
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Wed, 17 Jun 2009 01:55:54 GMT
>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>> > http://bugzilla.kernel.org/show_bug.cgi?id=13553
>> >
>> > Summary: When NETCONSOLE is enabled in kernel, computer
>> > crashes
>> > after 120seconds (approx)
>> > Product: Networking
>> > Version: 2.5
>> > Kernel Version: 2.6.29.4, 2.6.30
>> > Platform: All
>> > OS/Version: Linux
>> > Tree: Mainline
>> > Status: NEW
>> > Severity: high
>> > Priority: P1
>> > Component: Other
>> > AssignedTo: acme@ghostprotocols.net
>> > ReportedBy: hilld@binarystorm.net
>> > Regression: No
>> >
>> >
>>
>> > 00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge
>> > 00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge
>> > 00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
>> > 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev
>> > 01)
>> > 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev
>> > 01)
>> > 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
>> > 00:0b.0 SCSI storage controller: Adaptec AIC-7896U2/7897U2
>> > 00:0b.1 SCSI storage controller: Adaptec AIC-7896U2/7897U2
>> > 00:0d.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet
>> > Pro 100
>> > (rev 08)
>> > 00:12.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>> > RTL-8139/8139C/8139C+ (rev 10)
>> > 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RL/VR
>> > AGP
>> >
>> > ------- Comment #2 From David Hill 2009-06-17 02:55:56 (-)
>> > [reply] -------
>> >
>> > With NETCONSOLE enabled, if I type:
>> > ethtool -s eth1 speed 100 duplex full autoneg on
>> >
>> > the computer freezes with kernel 2.6.29.4 and 2.6.30...
>> >
>> > I can reproduce it anytime you want.
>> >
>>
>> Interesting. I wonder what the significance is of the 120 seconds. I
>> see no such timers in e100.c. Does the networking core have timers on
>> such intervals?
>>
> My guess is the 120 seconds has less to do with the driver, and more to do
> with
> some other periodic event in the kernel that triggers a message getting
> written
> to the console, which in turn triggers whatever deadlock it is thats
> getting hit
> here. I imagine we could diagnose it pretty quick if a stack trace or
> vmcore
> could be captured on this. David, can you enable the NMI watchdog on this
> system to trigger a panic on the system after a deadlock? Then if you
> could
> enable a second serial console, or setup kdump to capture a vmcore on this
> system, we should be able to figure out whats going on. My guess is that
> in
> the e100 driver we're taking a lock in the ethtool set path, then calling
> printk, which winds up recursing into the driver, trying to take the same
> lock
> again. A stack trace will tell us for certain.
>
> Regards
> Neil
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: Achieved 10Gbit/s bidirectional routing
From: Bill Fink @ 2009-07-16 3:22 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev@vger.kernel.org, David S. Miller, Robert Olsson,
Waskiewicz Jr, Peter P, Ronciak, John, jesse.brandeburg,
Stephen Hemminger, Linux Kernel Mailing List
In-Reply-To: <1247676631.30876.29.camel@localhost.localdomain>
On Wed, 15 Jul 2009, Jesper Dangaard Brouer wrote:
> I'm giving a talk at LinuxCon, about 10Gbit/s routing on standard
> hardware running Linux.
>
> http://linuxcon.linuxfoundation.org/meetings/1585
> https://events.linuxfoundation.org/lc09o17
>
> I'm getting some really good 10Gbit/s bidirectional routing results
> with Intels latest 82599 chip. (I got two pre-release engineering
> samples directly from Intel, thanks Peter)
>
> Using a Core i7-920, and tuning the memory according to the RAMs
> X.M.P. settings DDR3-1600MHz, notice this also increases the QPI to
> 6.4GT/s. (Motherboard P6T6 WS revolution)
>
> With big 1514 bytes packets, I can basically do 10Gbit/s wirespeed
> bidirectional routing.
>
> Notice bidirectional routing means that we actually has to move approx
> 40Gbit/s through memory and in-and-out of the interfaces.
>
> Formatted quick view using 'ifstat -b'
>
> eth31-in eth31-out eth32-in eth32-out
> 9.57 + 9.52 + 9.51 + 9.60 = 38.20 Gbit/s
> 9.60 + 9.55 + 9.52 + 9.62 = 38.29 Gbit/s
> 9.61 + 9.53 + 9.52 + 9.62 = 38.28 Gbit/s
> 9.61 + 9.53 + 9.54 + 9.62 = 38.30 Gbit/s
>
> [Adding an extra NIC]
>
> Another observation is that I'm hitting some kind of bottleneck on the
> PCI-express switch. Adding an extra NIC in a PCIe slot connected to
> the same PCIe switch, does not scale beyond 40Gbit/s collective
> throughput.
>
> But, I happened to have a special motherboard ASUS P6T6 WS revolution,
> which has an additional PCIe switch chip NVIDIA's NF200.
>
> Connecting two dual port 10GbE NICs via two different PCI-express
> switch chips, makes things scale again! I have achieved a collective
> throughput of 66.25 Gbit/s. This results is also influenced by my
> pktgen machines cannot keep up, and I'm getting closer to the memory
> bandwidth limits.
>
> FYI: I found a really good reference explaining the PCI-express
> architecture, written by Intel:
>
> http://download.intel.com/design/intarch/papers/321071.pdf
>
> I'm not sure how to explain the PCI-express chip bottleneck I'm
> seeing, but my guess is that I'm limited by the number of outstanding
> packets/DMA-transfers and the latency for the DMA operations.
>
> Does any one have datasheets on the X58 and NVIDIA's NF200 PCI-express
> chips, that can tell me the number of outstanding transfers they
> support?
We've achieved 70 Gbps aggregate unidirectional TCP performance from
one P6T6 based system to another. We figured out in our case that
we were being limited by the interconnect between the Intel X58 and
Nvidia N200 chips. The first 2 PCIe 2.0 slots are directly off the
Intel X58 and get the full 40 Gbps throughput from the dual-port
Myricom 10-GigE NICs we have installed in them. But the other
3 PCIe 2.0 slots are on the Nvidia N200 chip, and I discovered
through googling that the link between the X58 and N200 chips
only operates at PCIe x16 _1.0_ speed, which limits the possible
aggregate throughput of the last 3 PCIe 2.0 slots to only 32 Gbps.
This was clearly seen in our nuttcp testing:
[root@i7raid-1 ~]# ./nuttcp-6.2.6 -In2 -xc0/0 -p5001 192.168.1.11 & ./nuttcp-6.2.6 -In3 -xc0/0 -p5002 192.168.2.11 & ./nuttcp-6.2.6 -In4 -xc1/1 -p5003 192.168.3.11 & ./nuttcp-6.2.6 -In5 -xc1/1 -p5004 192.168.4.11 & ./nuttcp-6.2.6 -In6 -xc2/2 -p5005 192.168.5.11 & ./nuttcp-6.2.6 -In7 -xc2/2 -p5006 192.168.6.11 & ./nuttcp-6.2.6 -In8 -xc3/3 -p5007 192.168.7.11 & ./nuttcp-6.2.6 -In9 -xc3/3 -p5008 192.168.8.11
n2: 11505.2648 MB / 10.09 sec = 9566.2298 Mbps 37 %TX 55 %RX 0 retrans 0.10 msRTT
n3: 11727.4489 MB / 10.02 sec = 9815.7570 Mbps 39 %TX 44 %RX 0 retrans 0.10 msRTT
n4: 11770.1250 MB / 10.07 sec = 9803.9901 Mbps 39 %TX 51 %RX 0 retrans 0.10 msRTT
n5: 11837.9320 MB / 10.05 sec = 9876.5725 Mbps 39 %TX 47 %RX 0 retrans 0.10 msRTT
n6: 9096.8125 MB / 10.09 sec = 7559.3310 Mbps 30 %TX 32 %RX 0 retrans 0.10 msRTT
n7: 9100.1211 MB / 10.10 sec = 7559.7790 Mbps 30 %TX 44 %RX 0 retrans 0.10 msRTT
n8: 9095.6179 MB / 10.10 sec = 7557.9983 Mbps 31 %TX 33 %RX 0 retrans 0.10 msRTT
n9: 9075.5472 MB / 10.08 sec = 7551.0234 Mbps 31 %TX 33 %RX 0 retrans 0.11 msRTT
This used 4 dual-port Myricom 10-GigE NICs. We also tested with
a fifth dual-port 10-GigE NIC, but the aggregate throughput stayed
at about 70 Gbps, due to the performance bottleneck between the
X58 and N200 chips.
-Bill
^ permalink raw reply
* Re: TCP MD5 connections get stuck with IPV6 mapped listener
From: John Dykstra @ 2009-07-16 2:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Adam Langley, netdev
In-Reply-To: <20090715121119.12fc69e5@s6510>
On Wed, 2009-07-15 at 12:11 -0700, Stephen Hemminger wrote:
> While investigating some TCP MD5 issues, with BGP, broke things
> up into a simple test program found that
> if server is listening on IPV6 for TCP with MD5 key
> and client connects with IPV4 MD5 key, the connection gets stuck after
> the initial SYN-SENT, SYN-ACK.
Stephen, I put a patch out on a separate thread "[PATCH] tcp: Fix MD5
signature checking on IPv4 mapped sockets."
I tested the obvious cases using your excellent tool, but I don't have
the infrastructure for complete testing. I expect you do.
--
John Dykstra
voice: +1 651 484-1098 Yahoo IM: jdykstra72
LinkedIn: http://www.linkedin.com/in/JohnDykstra
Blog: http://johndykstra.blogspot.com/
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] virtio-net: Allow UFO feature to be set and advertised.
From: Rusty Russell @ 2009-07-16 2:28 UTC (permalink / raw)
To: Sridhar Samudrala; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <1247617262.4998.76.camel@IBM-19B5263ED41-009047018100.beaverton.ibm.com>
On Wed, 15 Jul 2009 09:51:02 am Sridhar Samudrala wrote:
> [PATCH net-next-2.6 1/2] virtio-net: Allow UFO feature to be set
>
> - Allow setting UFO on virtio-net and advertise to host.
>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Thanks!
Rusty.
^ permalink raw reply
* [PATCH] tcp: Fix MD5 signature checking on IPv4 mapped sockets
From: John Dykstra @ 2009-07-16 2:13 UTC (permalink / raw)
To: netdev, Stephen Hemminger
Fix MD5 signature checking so that an IPv4 active open
to an IPv6 socket can succeed. In particular, use the
correct address family's signature generation function
for the SYN/ACK.
Reported-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: John Dykstra <john.dykstra1@gmail.com>
---
include/net/tcp.h | 5 +++++
net/ipv4/tcp_ipv4.c | 1 +
net/ipv4/tcp_output.c | 3 ++-
net/ipv6/tcp_ipv6.c | 1 +
4 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 19f4150..88af843 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1425,6 +1425,11 @@ struct tcp_request_sock_ops {
#ifdef CONFIG_TCP_MD5SIG
struct tcp_md5sig_key *(*md5_lookup) (struct sock *sk,
struct request_sock *req);
+ int (*calc_md5_hash) (char *location,
+ struct tcp_md5sig_key *md5,
+ struct sock *sk,
+ struct request_sock *req,
+ struct sk_buff *skb);
#endif
};
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 5a1ca26..7c107eb 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1160,6 +1160,7 @@ struct request_sock_ops tcp_request_sock_ops __read_mostly = {
#ifdef CONFIG_TCP_MD5SIG
static struct tcp_request_sock_ops tcp_request_sock_ipv4_ops = {
.md5_lookup = tcp_v4_reqsk_md5_lookup,
+ .calc_md5_hash = tcp_v4_md5_hash_skb,
};
#endif
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 5bdf08d..17b049f 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2261,7 +2261,8 @@ struct sk_buff *tcp_make_synack(struct sock *sk, struct dst_entry *dst,
#ifdef CONFIG_TCP_MD5SIG
/* Okay, we have all we need - do the md5 hash if needed */
if (md5) {
- tp->af_specific->calc_md5_hash(md5_hash_location,
+ tcp_rsk(req)->af_specific->calc_md5_hash(md5_hash_location,
+
md5, NULL, req, skb);
}
#endif
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 58810c6..ae3d657 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -896,6 +896,7 @@ struct request_sock_ops tcp6_request_sock_ops __read_mostly = {
#ifdef CONFIG_TCP_MD5SIG
static struct tcp_request_sock_ops tcp_request_sock_ipv6_ops = {
.md5_lookup = tcp_v6_reqsk_md5_lookup,
+ .calc_md5_hash = tcp_v6_md5_hash_skb,
};
#endif
--
1.5.4.3
^ permalink raw reply related
* Determine veth peer device?
From: Ben Greear @ 2009-07-15 23:55 UTC (permalink / raw)
To: NetDev
Is there a way to determine the peer device for a
veth interface in user-space?
I didn't see anything obvious printed in 'ip link show'
[root@i7-1qc-1 ~]# ip link show dev veth0
7: veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 72:2e:4d:74:5b:a6 brd ff:ff:ff:ff:ff:ff
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: ixgbe: schedule while atomic bug during dev_disable_lro 2.6.31-rc3
From: Ben Greear @ 2009-07-15 23:50 UTC (permalink / raw)
To: Ben Hutchings; +Cc: NetDev
In-Reply-To: <1247700919.2788.11.camel@achroite>
On 07/15/2009 04:35 PM, Ben Hutchings wrote:
> On Wed, 2009-07-15 at 16:00 -0700, Ben Greear wrote:
>> I just got a fancy new 10G NIC and tried it out in a (patched elsewhere, but stock ixgbe driver) 2.6.31-rc3) kernel.
>
> And what exactly are those patches?
various and sundry, but so far I only see this problem with ixgbe
(the 1G NICs don't complain at least).
I'll build an un-patched kernel and see if I can reproduce them.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: ixgbe: schedule while atomic bug during dev_disable_lro 2.6.31-rc3
From: Ben Hutchings @ 2009-07-15 23:35 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4A5E5F8A.308@candelatech.com>
On Wed, 2009-07-15 at 16:00 -0700, Ben Greear wrote:
> I just got a fancy new 10G NIC and tried it out in a (patched elsewhere, but stock ixgbe driver) 2.6.31-rc3) kernel.
And what exactly are those patches?
> First of all, it runs very fast: sustained 9.5Gbps tx + rx on two ports concurrently (using modified pktgen),
> with 1500 byte pkts.
>
> I did see a warning in the boot logs though.
[...]
> BUG: scheduling while atomic: S99lanforge/2133/0x00000002
> Modules linked in: sco stp llc bnep l2cap bluetooth nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 dm_multipath uinput ixgbe i2c_i801 i2c_core dca mdio
> e1000e iTCO_wdt iTCO_vendor_support pcspkr ata_generic pata_acpi [last unloaded: bridge]
> Pid: 2133, comm: S99lanforge Not tainted 2.6.31-rc3 #2
> Call Trace:
> [<ffffffff81042456>] __schedule_bug+0x5c/0x60
> [<ffffffff813e6712>] schedule+0xc1/0x85e
> [<ffffffff8104488a>] ? check_preempt_wakeup+0x2d/0x1b7
> [<ffffffff813e880b>] ? _spin_unlock_irqrestore+0x37/0x42
> [<ffffffff813e7182>] schedule_timeout+0x97/0xbb
> [<ffffffff8105857e>] ? process_timeout+0x0/0xb
> [<ffffffff813e71bf>] schedule_timeout_uninterruptible+0x19/0x1b
> [<ffffffff81058a25>] msleep+0x16/0x1d
> [<ffffffffa005e160>] ixgbe_stop_adapter_generic+0x38/0x97 [ixgbe]
> [<ffffffffa0063e5a>] ixgbe_reset_hw_82599+0x13/0x1a4 [ixgbe]
> [<ffffffffa005cfc3>] ixgbe_init_hw_generic+0xf/0x1d [ixgbe]
> [<ffffffffa0056f04>] ixgbe_reset+0x1e/0xef [ixgbe]
> [<ffffffffa005ee71>] ixgbe_set_flags+0x5c/0x66 [ixgbe]
> [<ffffffff81343fe2>] dev_disable_lro+0x4d/0x69
> [<ffffffff81398191>] devinet_sysctl_forward+0xd7/0x1a4
> [<ffffffff81136111>] proc_sys_call_handler+0x8d/0xb7
> [<ffffffff8113614a>] proc_sys_write+0xf/0x11
> [<ffffffff810e856d>] vfs_write+0xa9/0x106
> [<ffffffff810e8680>] sys_write+0x45/0x69
> [<ffffffff81011b42>] system_call_fastpath+0x16/0x1b
I introduced dev_disable_lro() and calls to it because LRO doesn't work
in conjunction with bridging or forwarding. (GRO does not have this
problem as it allows the original packets to be regenerated.)
So far as I can see, none of the functions in this backtrace should be
entering atomic context, so I suspect that the patches "elsewhere" might
be doing something strange.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* ixgbe: schedule while atomic bug during dev_disable_lro 2.6.31-rc3
From: Ben Greear @ 2009-07-15 23:00 UTC (permalink / raw)
To: NetDev
I just got a fancy new 10G NIC and tried it out in a (patched elsewhere, but stock ixgbe driver) 2.6.31-rc3) kernel.
First of all, it runs very fast: sustained 9.5Gbps tx + rx on two ports concurrently (using modified pktgen),
with 1500 byte pkts.
I did see a warning in the boot logs though.
Here is the lspci for one of these ports:
03:00.1 Ethernet controller: Intel Corporation Device 10fb (rev 01)
Subsystem: Device 0083:000c
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at f9680000 (64-bit, prefetchable) [size=512K]
Region 2: I/O ports at e880 [size=32]
Region 4: Memory at f9778000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] MSI: Mask+ 64bit+ Count=1/1 Enable-
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [70] MSI-X: Enable+ Mask- TabSize=64
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00002000
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x8, ASPM unknown, Latency L0 <1us, L1 <8us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [100] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140] Device Serial Number 00-00-00-ff-ff-00-00-00
Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 0
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
IOVCap: Migration-, Interrupt Message Number: 000
IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
IOVSta: Migration-
Initial VFs: 64, Total VFs: 64, Number of VFs: 64, Function Dependency Link: 01
VF offset: 128, stride: 2, Device ID: 10d8
Supported Page Size: 00000553, System Page Size: 00000001
VF Migration: offset: 00000000, BIR: 0
Kernel driver in use: ixgbe
Kernel modules: ixgbe
selected dmesg output:
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 2.0.34-k2
ixgbe: Copyright (c) 1999-2009 Intel Corporation.
ixgbe 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ixgbe 0000:03:00.0: setting latency timer to 64
alloc irq_desc for 35 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 35 for MSI/MSI-X
alloc irq_desc for 36 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 36 for MSI/MSI-X
alloc irq_desc for 37 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 37 for MSI/MSI-X
alloc irq_desc for 38 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 38 for MSI/MSI-X
alloc irq_desc for 39 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 39 for MSI/MSI-X
alloc irq_desc for 40 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 40 for MSI/MSI-X
alloc irq_desc for 41 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 41 for MSI/MSI-X
alloc irq_desc for 42 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 42 for MSI/MSI-X
alloc irq_desc for 43 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 43 for MSI/MSI-X
alloc irq_desc for 44 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 44 for MSI/MSI-X
alloc irq_desc for 45 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 45 for MSI/MSI-X
alloc irq_desc for 46 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 46 for MSI/MSI-X
alloc irq_desc for 47 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 47 for MSI/MSI-X
alloc irq_desc for 48 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 48 for MSI/MSI-X
alloc irq_desc for 49 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 49 for MSI/MSI-X
alloc irq_desc for 50 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 50 for MSI/MSI-X
alloc irq_desc for 51 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.0: irq 51 for MSI/MSI-X
ixgbe: 0000:03:00.0: ixgbe_init_interrupt_scheme: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8
ixgbe 0000:03:00.0: (PCI Express:5.0Gb/s:Width x8) 00:0c:bd:00:90:1a
ixgbe 0000:03:00.0: MAC: 2, PHY: 9, SFP+: 5, PBA No: e57138-000
ixgbe 0000:03:00.0: This device is a pre-production adapter/LOM. Please be aware there may be issues associated with your hardware. If you are experiencing
problems please contact your Intel or hardware representative who provided you with this hardware.
ixgbe 0000:03:00.0: Intel(R) 10 Gigabit Network Connection
alloc irq_desc for 17 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
ixgbe 0000:03:00.1: setting latency timer to 64
alloc irq_desc for 52 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 52 for MSI/MSI-X
alloc irq_desc for 53 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 53 for MSI/MSI-X
alloc irq_desc for 54 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 54 for MSI/MSI-X
alloc irq_desc for 55 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 55 for MSI/MSI-X
alloc irq_desc for 56 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 56 for MSI/MSI-X
alloc irq_desc for 57 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 57 for MSI/MSI-X
alloc irq_desc for 58 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 58 for MSI/MSI-X
alloc irq_desc for 59 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 59 for MSI/MSI-X
alloc irq_desc for 60 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 60 for MSI/MSI-X
alloc irq_desc for 61 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 61 for MSI/MSI-X
alloc irq_desc for 62 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 62 for MSI/MSI-X
alloc irq_desc for 63 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 63 for MSI/MSI-X
alloc irq_desc for 64 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 64 for MSI/MSI-X
alloc irq_desc for 65 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 65 for MSI/MSI-X
alloc irq_desc for 66 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 66 for MSI/MSI-X
alloc irq_desc for 67 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 67 for MSI/MSI-X
alloc irq_desc for 68 on node 0
alloc kstat_irqs on node 0
ixgbe 0000:03:00.1: irq 68 for MSI/MSI-X
ixgbe: 0000:03:00.1: ixgbe_init_interrupt_scheme: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8
ixgbe 0000:03:00.1: (PCI Express:5.0Gb/s:Width x8) 00:0c:bd:00:90:1b
ixgbe 0000:03:00.1: MAC: 2, PHY: 9, SFP+: 5, PBA No: e57138-000
ixgbe 0000:03:00.1: This device is a pre-production adapter/LOM. Please be aware there may be issues associated with your hardware. If you are experiencing
problems please contact your Intel or hardware representative who provided you with this hardware.
ixgbe 0000:03:00.1: Intel(R) 10 Gigabit Network Connection
....
BUG: scheduling while atomic: S99lanforge/2133/0x00000002
Modules linked in: sco stp llc bnep l2cap bluetooth nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 dm_multipath uinput ixgbe i2c_i801 i2c_core dca mdio
e1000e iTCO_wdt iTCO_vendor_support pcspkr ata_generic pata_acpi [last unloaded: bridge]
Pid: 2133, comm: S99lanforge Not tainted 2.6.31-rc3 #2
Call Trace:
[<ffffffff81042456>] __schedule_bug+0x5c/0x60
[<ffffffff813e6712>] schedule+0xc1/0x85e
[<ffffffff8104488a>] ? check_preempt_wakeup+0x2d/0x1b7
[<ffffffff813e880b>] ? _spin_unlock_irqrestore+0x37/0x42
[<ffffffff813e7182>] schedule_timeout+0x97/0xbb
[<ffffffff8105857e>] ? process_timeout+0x0/0xb
[<ffffffff813e71bf>] schedule_timeout_uninterruptible+0x19/0x1b
[<ffffffff81058a25>] msleep+0x16/0x1d
[<ffffffffa005e160>] ixgbe_stop_adapter_generic+0x38/0x97 [ixgbe]
[<ffffffffa0063e5a>] ixgbe_reset_hw_82599+0x13/0x1a4 [ixgbe]
[<ffffffffa005cfc3>] ixgbe_init_hw_generic+0xf/0x1d [ixgbe]
[<ffffffffa0056f04>] ixgbe_reset+0x1e/0xef [ixgbe]
[<ffffffffa005ee71>] ixgbe_set_flags+0x5c/0x66 [ixgbe]
[<ffffffff81343fe2>] dev_disable_lro+0x4d/0x69
[<ffffffff81398191>] devinet_sysctl_forward+0xd7/0x1a4
[<ffffffff81136111>] proc_sys_call_handler+0x8d/0xb7
[<ffffffff8113614a>] proc_sys_write+0xf/0x11
[<ffffffff810e856d>] vfs_write+0xa9/0x106
[<ffffffff810e8680>] sys_write+0x45/0x69
[<ffffffff81011b42>] system_call_fastpath+0x16/0x1b
More info available if needed.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: weird problem
From: Jarek Poplawski @ 2009-07-15 22:43 UTC (permalink / raw)
To: Paweł Staszewski
Cc: Eric Dumazet, Eric Dumazet, Linux Network Development list
In-Reply-To: <4A5E38EE.2090405@itcare.pl>
On Wed, Jul 15, 2009 at 10:15:42PM +0200, Paweł Staszewski wrote:
...
> So is there some patch or there will be patch that turn off definitely
> route cache ?
>
You did it already with rt_cache_rebuild_count = -1 or 0 (without my
patches). You can additionally try to set a very minimal hash table
size with kernel boot param "rhash_entries" to limit timers work etc.
Regards,
Jarek P.
^ permalink raw reply
* Re: [PATCH] iproute2 flush: handle larger tables and deleted entries
From: Gautam Kachroo @ 2009-07-15 22:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Patrick McHardy, netdev
In-Reply-To: <20090715121907.04b7f5b0@s6510>
On Wed, Jul 15, 2009 at 12:19 PM, Stephen
Hemminger<shemminger@vyatta.com> wrote:
> On Wed, 15 Jul 2009 10:50:57 -0700
> Gautam Kachroo <gk@aristanetworks.com> wrote:
>
>> On Wed, Jul 15, 2009 at 8:19 AM, Patrick McHardy<kaber@trash.net> wrote:
>> > Gautam Kachroo wrote:
>> >> On Tue, Jul 14, 2009 at 2:38 AM, Patrick McHardy<kaber@trash.net> wrote:
>> >>> Gautam Kachroo wrote:
>> >>>> use a new netlink socket when sending flush messages to avoid reading
>> >>>> any pending data on the existing netlink socket.
>> >>>>
>> >>>> read all of the response from the netlink request -- this response can
>> >>>> be split over multiple recv calls, pretty much one per netlink request
>> >>>> message. ENOENT errors, which correspond to attempts to delete an
>> >>>> already deleted entry, are ignored. Other errors are not ignored.
>> >>>
>> >>> In which case would there be any pending data? From what I can see,
>> >>> this can only happen when using batching, but in that case the
>> >>> previous command should continue reading until it has received all
>> >>> responses (which the netlink functions appear to be doing properly).
>> >>
>> >> What is the "previous command"?
>> >
>> > The last command before the one executing when using batching.
>>
>> This is independent of batching (I assume you're referring to the
>> -batch option to the ip command).
>> It happens when running a command like "ip neigh flush to 0.0.0.0/0"
>> if there are many neighbor entries.
>>
>> The implementation of flush commands, e.g. ip neigh flush, sends a
>> dump request, e.g. RTM_GETNEIGH, and then sends requests, e.g.
>> RTM_DELNEIGH, *while* there can be unread data from the dump request.
>> There would be unread data if the response to the dump request was
>> split over multiple calls to recvmsg.
>>
>> >> Are you referring to rtnl_dump_filter? If rtnl_send_check comes across
>> >> a failure, rtnl_dump_filter will not continue reading.
>> >>
>> >> Here's the situation that I'm referring to:
>> >>
>> >> If rtnl_send_check detects an error, it returns -1. rtnl_send_check is
>> >> called from flush_update. The multiple implementations of flush_update
>> >> (e.g. in ipneigh.c, ipaddress.c) propagate this return value to their
>> >> caller, e.g. print_neigh or print_addrinfo.
>> >>
>> >> print_neigh, print_addrinfo, etc. are called from rtnl_dump_filter.
>> >> rtnl_dump_filter sits in a loop calling recvmsg on the netlink socket.
>> >> However, it returns the error value if the filter function (e.g.
>> >> print_neigh) returns an error. In this case, rtnl_dump_filter can
>> >> return before it's read all the responses.
>> >> The error return from rtnl_dump_filter causes the program to exit.
>> >
>> > Yes, and I agree with your patch so far. My question is why you
>> > need another socket.
>> >
>> >> use a new netlink socket when sending flush messages to avoid reading
>> >> any pending data on the existing netlink socket.
>> >
>> > Under what circumstances would there be pending data when
>> > performing a new iproute operation?
>>
>> As above, it's not that there is pending data when performing a new
>> iproute operation, it's that there can be pending data while
>> performing a single iproute operation, namely ip <object> flush.
>> The benefit of a new socket is that it won't have any data from the
>> dump request waiting for it.
>
> I posted a better fix (using MSG_PEEK).
Where did you post the fix? I didn't see it on netdev or in the iproute2 git...
I had considered using MSG_PEEK in rtnl_send_check, but I don't think
that notices errors with the requests in the "buf" argument of
rtnl_send_check if there is already pending data -- the recv will peek
the next chunk of the dump response. The error response will be
waiting in the queue after the dump response.
Of course, an error, e.g. EPERM, will eventually be noticed, just not
as early...
thanks,
-gk
^ permalink raw reply
* Re: TCP MD5 connections get stuck with IPV6 mapped listener
From: Stephen Hemminger @ 2009-07-15 20:42 UTC (permalink / raw)
To: John Dykstra; +Cc: Adam Langley, netdev
In-Reply-To: <1247686985.7129.15.camel@Maple>
On Wed, 15 Jul 2009 14:43:05 -0500
John Dykstra <john.dykstra1@gmail.com> wrote:
> On Wed, 2009-07-15 at 12:11 -0700, Stephen Hemminger wrote:
> > While investigating some TCP MD5 issues, with BGP, broke things
> > up into a simple test program found that
> > if server is listening on IPV6 for TCP with MD5 key
> > and client connects with IPV4 MD5 key, the connection gets stuck after
> > the initial SYN-SENT, SYN-ACK.
>
> Just cause I've been burned recently....
>
> Which kernel did you reproduce this on, and have you tried 2.6.31-rcx?
yes 2.6.31-rc3
^ permalink raw reply
* Re: weird problem
From: Paweł Staszewski @ 2009-07-15 20:15 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Eric Dumazet, Eric Dumazet, Linux Network Development list
In-Reply-To: <20090714162425.GA3090@ami.dom.local>
Jarek Poplawski pisze:
> On Tue, Jul 14, 2009 at 01:26:46AM +0200, Paweł Staszewski wrote:
>
>> Jarek Poplawski pisze:
>>
>>> On Fri, Jul 10, 2009 at 04:47:54PM +0200, Jarek Poplawski wrote:
>>>
>>>
>>>> On Fri, Jul 10, 2009 at 01:59:00AM +0200, Paweł Staszewski wrote:
>>>>
>>>>
>>>>> Today i make other tests with change of
>>>>> /proc/sys/net/ipv4/rt_cache_rebuild_count and kernel 2.6.30.1
>>>>>
>>>>> And when rt_cache_rebuild_count is set to "-1" i have always load
>>>>> on x86_64 machine approx 40-50% of each cpu where network card is
>>>>> binded by irq_aff
>>>>>
>>>>> when rt_cache_rebuild_count is set to more than "-1" i have 15 to
>>>>> 20 sec of 1 to 3% cpu and after 40-50% cpu
>>>>>
>>>>>
>>>> ...
>>>>
>>>> Here is one more patch for testing (with caution!). It adds possibility
>>>> to turn off cache disabling (so it should even more resemble 2.6.28)
>>>> after setting: rt_cache_rebuild_count = 0
>>>>
>>>> I'd like you to try this patch:
>>>> 1) together with the previous patch and "rt_cache_rebuild_count = 0"
>>>> to check if there is still the difference wrt. 2.6.28; Btw., let
>>>> me know which /proc/sys/net/ipv4/route/* settings do you need to
>>>> change and why
>>>>
>>>> 2) alone (without the previous patch) and "rt_cache_rebuild_count = 0"
>>>>
>>>> 3) if it's possible to try 2.6.30.1 without these patches, but with
>>>> default /proc/sys/net/ipv4/route/* settings, and higher
>>>> rt_cache_rebuild_count, e.g. 100; I'm interested if/how long it
>>>> takes to trigger higher cpu load and the warning "... rebuilds is
>>>> over limit, route caching disabled"; (Btw., I wonder why you didn't
>>>> mention about these or maybe also other route caching warnings?)
>>>>
>>>>
>>> Here is take 2 to respect setting "rt_cache_rebuild_count = 0" even
>>> after cache rebuild counter has been increased earlier. (Btw, don't
>>> forget about this setting after going back to vanilla kernel.)
>>>
>>>
>>>
>> Applied to 2.6.30.1
>> 1) With
>>
>> rt_cache_rebuild_count = 0
>> grep . /proc/sys/net/ipv4/route/*
>> /proc/sys/net/ipv4/route/error_burst:1250
>> /proc/sys/net/ipv4/route/error_cost:250
>> /proc/sys/net/ipv4/route/gc_elasticity:4
>> /proc/sys/net/ipv4/route/gc_interval:15
>> /proc/sys/net/ipv4/route/gc_min_interval:0
>> /proc/sys/net/ipv4/route/gc_min_interval_ms:0
>> /proc/sys/net/ipv4/route/gc_thresh:190536
>> /proc/sys/net/ipv4/route/gc_timeout:15
>> /proc/sys/net/ipv4/route/max_size:1524288
>> /proc/sys/net/ipv4/route/min_adv_mss:256
>> /proc/sys/net/ipv4/route/min_pmtu:552
>> /proc/sys/net/ipv4/route/mtu_expires:600
>> /proc/sys/net/ipv4/route/redirect_load:5
>> /proc/sys/net/ipv4/route/redirect_number:9
>> /proc/sys/net/ipv4/route/redirect_silence:5120
>> /proc/sys/net/ipv4/route/secret_interval:3600
>>
>> I tune this route parameters after looking of traffic/route cache to have not many entries in cache that are not needed anymore
>> so gc_timeout = 15
>> limit of max entries = 1524288
>> And make route cahce a little more "faster" for me after tune
>> gc_elasticity
>> secret_interval
>> gc_interval
>> gc_thresh
>>
>> So with this parameters 15 sec of something like this:
>> 00:41:23 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
>> 00:41:24 all 0.00 0.00 0.12 0.00 1.49 10.46 0.00 0.00 87.92
>> 00:41:24 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:41:24 1 0.00 0.00 0.00 0.00 4.00 36.00 0.00 0.00 60.00
>> 00:41:24 2 0.00 0.00 0.00 0.00 8.91 47.52 0.00 0.00 43.56
>> 00:41:24 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:41:24 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:41:24 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:41:24 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:41:24 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>>
>> and 15 sec of something like this:
>> 00:41:44 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
>> 00:41:45 all 0.00 0.00 0.00 0.00 0.00 0.42 0.00 0.00 99.58
>> 00:41:45 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:41:45 1 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 99.00
>> 00:41:45 2 0.00 0.00 0.00 0.00 0.00 2.04 0.00 0.00 97.96
>> 00:41:45 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:41:45 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:41:45 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:41:45 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:41:45 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>>
>> So i change /proc/sys/net/ipv4/route/gc_timeout to 1
>> with rt_cache_rebuild_count = 0
>> And output is like 20 sec of something like this
>> 00:48:52 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
>> 00:48:53 all 0.00 0.00 0.19 0.00 0.19 0.58 0.00 0.00 99.03
>> 00:48:53 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:53 1 0.00 0.00 0.99 0.00 0.99 0.00 0.00 0.00 98.02
>> 00:48:53 2 0.00 0.00 0.00 0.00 0.00 2.00 0.00 0.00 98.00
>> 00:48:53 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:53 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:53 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:53 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:53 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>>
>> and after this two second of something like this:
>> 00:48:49 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
>> 00:48:50 all 0.00 0.00 0.09 0.00 0.27 2.17 0.00 0.00 97.46
>> 00:48:50 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:50 1 0.00 0.00 0.00 0.00 1.96 6.86 0.00 0.00 91.18
>> 00:48:50 2 0.00 0.00 0.00 0.00 0.99 16.83 0.00 0.00 82.18
>> 00:48:50 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:50 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:50 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:50 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:50 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>>
>> 00:48:50 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
>> 00:48:51 all 0.00 0.00 0.00 0.00 1.86 10.41 0.00 0.00 87.73
>> 00:48:51 0 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 99.00
>> 00:48:51 1 0.00 0.00 0.00 0.00 4.85 26.21 0.00 0.00 68.93
>> 00:48:51 2 0.00 0.00 1.00 0.00 5.00 29.00 0.00 0.00 65.00
>> 00:48:51 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:51 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:51 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:51 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:48:51 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>>
>>
>
> Could you remind us how it differs from 2.6.28 with the same settings?
>
With the same settings and 2.6.28 there was always cpu load from 1% to 3%
with gc_timeout = 15
>
>> Another test:
>>
>> gc_timeout = 1
>> rt_cache_rebuild_count = 100
>> 10 to 14 sec of something like this:
>> 00:51:36 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
>> 00:51:37 all 0.00 0.00 0.00 0.00 0.00 0.27 0.00 0.00 99.73
>> 00:51:37 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:51:37 1 0.00 0.00 0.00 0.00 0.00 2.00 0.00 0.00 98.00
>> 00:51:37 2 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 99.00
>> 00:51:37 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:51:37 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:51:37 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:51:37 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:51:37 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>>
>> and two seconds of 10 to 30% cpu load more
>>
>>
>> 2).
>> Only last patch and almost all the time output like this
>> 00:59:49 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
>> 00:59:50 all 0.00 0.00 0.13 0.00 1.73 8.00 0.00 0.00 90.13
>> 00:59:50 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:59:50 1 0.00 0.00 0.00 0.00 4.00 24.00 0.00 0.00 72.00
>> 00:59:50 2 0.00 0.00 0.00 0.00 8.91 34.65 0.00 0.00 56.44
>> 00:59:50 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:59:50 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:59:50 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:59:50 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 00:59:50 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>>
>> sometimes after 15 to 30 sec i have 1 to 2% cpu load
>>
>
> And how long do you have this 1 to 2% load? Is it with:
> rt_cache_rebuild_count = 0
> gc_timeout = 1?
> Maybe you could describe the main difference with or without the first
> patch?
>
>
>> 3).
>>
>> with default settings and without this patch i have almost all the time output like this:
>>
>
> You mean without these two patches, right? So, there is no breaks with
> less load like above?
>
>
Yes.
>> 01:21:40 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
>> 01:21:41 all 0.00 0.00 0.00 0.00 2.14 10.97 0.00 0.00 86.89
>> 01:21:41 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 01:21:41 1 0.00 0.00 0.00 0.00 6.93 34.65 0.00 0.00 58.42
>> 01:21:41 2 0.00 0.00 0.00 0.00 7.07 42.42 0.00 0.00 50.51
>> 01:21:41 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 01:21:41 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 01:21:41 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 01:21:41 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 01:21:41 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>>
>>
>>
>> with my settings:
>> /proc/sys/net/ipv4/route/error_burst:1250
>> /proc/sys/net/ipv4/route/error_cost:250
>> /proc/sys/net/ipv4/route/gc_elasticity:4
>> /proc/sys/net/ipv4/route/gc_interval:15
>> /proc/sys/net/ipv4/route/gc_min_interval:0
>> /proc/sys/net/ipv4/route/gc_min_interval_ms:0
>> /proc/sys/net/ipv4/route/gc_thresh:190536
>> /proc/sys/net/ipv4/route/gc_timeout:15
>> /proc/sys/net/ipv4/route/max_size:1524288
>> /proc/sys/net/ipv4/route/min_adv_mss:256
>> /proc/sys/net/ipv4/route/min_pmtu:552
>> /proc/sys/net/ipv4/route/mtu_expires:600
>> /proc/sys/net/ipv4/route/redirect_load:5
>> /proc/sys/net/ipv4/route/redirect_number:9
>> /proc/sys/net/ipv4/route/redirect_silence:5120
>> /proc/sys/net/ipv4/route/secret_interval:3600
>>
>>
>> 15 sec of 30 to 50 % cpu and 15 sec 1 to 2 % cpu
>>
>> with /proc/sys/net/ipv4/route/gc_interval:1
>> almost all the time like this
>> 01:23:45 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
>> 01:23:46 all 0.00 0.00 0.00 0.00 0.00 0.12 0.00 0.00 99.88
>> 01:23:46 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 01:23:46 1 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 99.00
>> 01:23:46 2 0.00 0.00 0.00 0.00 0.00 1.02 0.00 0.00 98.98
>> 01:23:46 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 01:23:46 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 01:23:46 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 01:23:46 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>> 01:23:46 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
>>
>> with max two outputs of 20 to 30% cpu in different times from 12 to 15sec
>>
>
> Didn't you see any: "... rebuilds is over limit, route caching
> disabled" warning?
>
>
No i don't any info.
>> And i dont know but i think patch for turning off route cache is not
>> working because with this patches and rt_cache_rebuild_count = 0
>>
>
> If you mean the patch #2, it does something opposite: with
> rt_cache_rebuild_count = 0 it turns off automatic "cache disabling"
> after rt_cache_rebuild_count events signaled with the above-mentionned
> warning, which was introduced in 2.6.29. Sorry for not describing this
> enough.
>
> Thanks,
> Jarek P.
>
>
>
So is there some patch or there will be patch that turn off definitely
route cache ?
For now i use
gc_timeout = 1 in my routers and all is working fine - there is only 1
second of 20% of cpu load after every 20 sec.
Regards
Pawel Staszewski
^ permalink raw reply
* [PATCH] net: nf_conntrack_alloc() fixes
From: Eric Dumazet @ 2009-07-15 19:54 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David Miller, netdev, paulmck
In-Reply-To: <4A5DF5B4.5090809@trash.net>
Patrick McHardy a écrit :
> Eric Dumazet wrote:
>> [PATCH] net: nf_conntrack_alloc() should not use kmem_cache_zalloc()
>>
>> When a slab cache uses SLAB_DESTROY_BY_RCU, we must be careful when allocating
>> objects, since slab allocator could give a freed object still used by lockless
>> readers.
>>
>> In particular, nf_conntrack RCU lookups rely on ct->tuplehash[xxx].hnnode.next
>> being always valid (ie containing a valid 'nulls' value, or a valid pointer to next
>> object in hash chain.)
>>
>> kmem_cache_zalloc() setups object with NULL values, but a NULL value is not valid
>> for ct->tuplehash[xxx].hnnode.next.
>>
>> Fix is to call kmem_cache_alloc() and do the zeroing ourself.
>
> I think this is still racy, please see below:
Nice catch indeed !
>
>> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
>> index 7508f11..23feafa 100644
>> --- a/net/netfilter/nf_conntrack_core.c
>> +++ b/net/netfilter/nf_conntrack_core.c
>> @@ -561,17 +561,28 @@ struct nf_conn *nf_conntrack_alloc(struct net *net,
>> }
>> }
>>
>> - ct = kmem_cache_zalloc(nf_conntrack_cachep, gfp);
>> + /*
>> + * Do not use kmem_cache_zalloc(), as this cache uses
>> + * SLAB_DESTROY_BY_RCU.
>> + */
>> + ct = kmem_cache_alloc(nf_conntrack_cachep, gfp);
>> if (ct == NULL) {
>> pr_debug("nf_conntrack_alloc: Can't alloc conntrack.\n");
>> atomic_dec(&net->ct.count);
>> return ERR_PTR(-ENOMEM);
>> }
>> -
>
> __nf_conntrack_find() on another CPU finds the entry at this point.
>
>> + /*
>> + * Let ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.next
>> + * and ct->tuplehash[IP_CT_DIR_REPLY].hnnode.next unchanged.
>> + */
>> + memset(&ct->tuplehash[IP_CT_DIR_MAX], 0,
>> + sizeof(*ct) - offsetof(struct nf_conn, tuplehash[IP_CT_DIR_MAX]));
>> spin_lock_init(&ct->lock);
>> atomic_set(&ct->ct_general.use, 1);
>
> nf_conntrack_find_get() successfully tries to atomic_inc_not_zero()
> at this point, following by another tuple comparison which is also
> successful.
>
> Am I missing something? I think we need to make sure the reference
> count is not increased until the new tuples are visible.
Yes you are right, and Documentation/RCU/rculist_nulls.txt should be
updated to reflect this as well (in insert algo, must use smp_wmb()
between obj->key assignment and refcnt assigment)
We'll have to change socket allocation too, this will be addressed
by a followup patch
Thanks Patrick !
[PATCH] net: nf_conntrack_alloc() fixes
When a slab cache uses SLAB_DESTROY_BY_RCU, we must be careful when allocating
objects, since slab allocator could give a freed object still used by lockless
readers.
In particular, nf_conntrack RCU lookups rely on ct->tuplehash[xxx].hnnode.next
being always valid (ie containing a valid 'nulls' value, or a valid pointer to next
object in hash chain.)
kmem_cache_zalloc() setups object with NULL values, but a NULL value is not valid
for ct->tuplehash[xxx].hnnode.next.
Fix is to call kmem_cache_alloc() and do the zeroing ourself.
As spotted by Patrick, we also need to make sure lookup keys are committed to
memory before setting refcount to 1, or a lockless reader could get a reference
on the old version of the object. Its key re-check could then pass the barrier.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
Documentation/RCU/rculist_nulls.txt | 7 ++++++-
net/netfilter/nf_conntrack_core.c | 21 ++++++++++++++++++---
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt
index 93cb28d..18f9651 100644
--- a/Documentation/RCU/rculist_nulls.txt
+++ b/Documentation/RCU/rculist_nulls.txt
@@ -83,11 +83,12 @@ not detect it missed following items in original chain.
obj = kmem_cache_alloc(...);
lock_chain(); // typically a spin_lock()
obj->key = key;
-atomic_inc(&obj->refcnt);
/*
* we need to make sure obj->key is updated before obj->next
+ * or obj->refcnt
*/
smp_wmb();
+atomic_set(&obj->refcnt, 1);
hlist_add_head_rcu(&obj->obj_node, list);
unlock_chain(); // typically a spin_unlock()
@@ -159,6 +160,10 @@ out:
obj = kmem_cache_alloc(cachep);
lock_chain(); // typically a spin_lock()
obj->key = key;
+/*
+ * changes to obj->key must be visible before refcnt one
+ */
+smp_wmb();
atomic_set(&obj->refcnt, 1);
/*
* insert obj in RCU way (readers might be traversing chain)
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 7508f11..b5869b9 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -561,23 +561,38 @@ struct nf_conn *nf_conntrack_alloc(struct net *net,
}
}
- ct = kmem_cache_zalloc(nf_conntrack_cachep, gfp);
+ /*
+ * Do not use kmem_cache_zalloc(), as this cache uses
+ * SLAB_DESTROY_BY_RCU.
+ */
+ ct = kmem_cache_alloc(nf_conntrack_cachep, gfp);
if (ct == NULL) {
pr_debug("nf_conntrack_alloc: Can't alloc conntrack.\n");
atomic_dec(&net->ct.count);
return ERR_PTR(-ENOMEM);
}
-
+ /*
+ * Let ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.next
+ * and ct->tuplehash[IP_CT_DIR_REPLY].hnnode.next unchanged.
+ */
+ memset(&ct->tuplehash[IP_CT_DIR_MAX], 0,
+ sizeof(*ct) - offsetof(struct nf_conn, tuplehash[IP_CT_DIR_MAX]));
spin_lock_init(&ct->lock);
- atomic_set(&ct->ct_general.use, 1);
ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple = *orig;
+ ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode.pprev = NULL;
ct->tuplehash[IP_CT_DIR_REPLY].tuple = *repl;
+ ct->tuplehash[IP_CT_DIR_REPLY].hnnode.pprev = NULL;
/* Don't set timer yet: wait for confirmation */
setup_timer(&ct->timeout, death_by_timeout, (unsigned long)ct);
#ifdef CONFIG_NET_NS
ct->ct_net = net;
#endif
+ /*
+ * changes to lookup keys must be done before setting refcnt to 1
+ */
+ smp_wmb();
+ atomic_set(&ct->ct_general.use, 1);
return ct;
}
EXPORT_SYMBOL_GPL(nf_conntrack_alloc);
^ permalink raw reply related
* Re: TCP MD5 connections get stuck with IPV6 mapped listener
From: John Dykstra @ 2009-07-15 19:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Adam Langley, netdev
In-Reply-To: <20090715121119.12fc69e5@s6510>
On Wed, 2009-07-15 at 12:11 -0700, Stephen Hemminger wrote:
> While investigating some TCP MD5 issues, with BGP, broke things
> up into a simple test program found that
> if server is listening on IPV6 for TCP with MD5 key
> and client connects with IPV4 MD5 key, the connection gets stuck after
> the initial SYN-SENT, SYN-ACK.
Just cause I've been burned recently....
Which kernel did you reproduce this on, and have you tried 2.6.31-rcx?
-- John
^ permalink raw reply
* Re: [PATCH] iproute2 flush: handle larger tables and deleted entries
From: Stephen Hemminger @ 2009-07-15 19:19 UTC (permalink / raw)
To: Gautam Kachroo; +Cc: Patrick McHardy, netdev
In-Reply-To: <4e0db5bc0907151050w56529bffh9878b99cc2fdaae5@mail.gmail.com>
On Wed, 15 Jul 2009 10:50:57 -0700
Gautam Kachroo <gk@aristanetworks.com> wrote:
> On Wed, Jul 15, 2009 at 8:19 AM, Patrick McHardy<kaber@trash.net> wrote:
> > Gautam Kachroo wrote:
> >> On Tue, Jul 14, 2009 at 2:38 AM, Patrick McHardy<kaber@trash.net> wrote:
> >>> Gautam Kachroo wrote:
> >>>> use a new netlink socket when sending flush messages to avoid reading
> >>>> any pending data on the existing netlink socket.
> >>>>
> >>>> read all of the response from the netlink request -- this response can
> >>>> be split over multiple recv calls, pretty much one per netlink request
> >>>> message. ENOENT errors, which correspond to attempts to delete an
> >>>> already deleted entry, are ignored. Other errors are not ignored.
> >>>
> >>> In which case would there be any pending data? From what I can see,
> >>> this can only happen when using batching, but in that case the
> >>> previous command should continue reading until it has received all
> >>> responses (which the netlink functions appear to be doing properly).
> >>
> >> What is the "previous command"?
> >
> > The last command before the one executing when using batching.
>
> This is independent of batching (I assume you're referring to the
> -batch option to the ip command).
> It happens when running a command like "ip neigh flush to 0.0.0.0/0"
> if there are many neighbor entries.
>
> The implementation of flush commands, e.g. ip neigh flush, sends a
> dump request, e.g. RTM_GETNEIGH, and then sends requests, e.g.
> RTM_DELNEIGH, *while* there can be unread data from the dump request.
> There would be unread data if the response to the dump request was
> split over multiple calls to recvmsg.
>
> >> Are you referring to rtnl_dump_filter? If rtnl_send_check comes across
> >> a failure, rtnl_dump_filter will not continue reading.
> >>
> >> Here's the situation that I'm referring to:
> >>
> >> If rtnl_send_check detects an error, it returns -1. rtnl_send_check is
> >> called from flush_update. The multiple implementations of flush_update
> >> (e.g. in ipneigh.c, ipaddress.c) propagate this return value to their
> >> caller, e.g. print_neigh or print_addrinfo.
> >>
> >> print_neigh, print_addrinfo, etc. are called from rtnl_dump_filter.
> >> rtnl_dump_filter sits in a loop calling recvmsg on the netlink socket.
> >> However, it returns the error value if the filter function (e.g.
> >> print_neigh) returns an error. In this case, rtnl_dump_filter can
> >> return before it's read all the responses.
> >> The error return from rtnl_dump_filter causes the program to exit.
> >
> > Yes, and I agree with your patch so far. My question is why you
> > need another socket.
> >
> >> use a new netlink socket when sending flush messages to avoid reading
> >> any pending data on the existing netlink socket.
> >
> > Under what circumstances would there be pending data when
> > performing a new iproute operation?
>
> As above, it's not that there is pending data when performing a new
> iproute operation, it's that there can be pending data while
> performing a single iproute operation, namely ip <object> flush.
> The benefit of a new socket is that it won't have any data from the
> dump request waiting for it.
I posted a better fix (using MSG_PEEK).
^ permalink raw reply
* TCP MD5 connections get stuck with IPV6 mapped listener
From: Stephen Hemminger @ 2009-07-15 19:11 UTC (permalink / raw)
To: Adam Langley; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]
While investigating some TCP MD5 issues, with BGP, broke things
up into a simple test program found that
if server is listening on IPV6 for TCP with MD5 key
and client connects with IPV4 MD5 key, the connection gets stuck after
the initial SYN-SENT, SYN-ACK.
The computed value on the SYN-ACK for MD5 is incorrect, so looks like
some issue in tcp_v6_syn_recv_sock path
Note: key with IPV4mapped
IPV6 address (ie. expects incoming IPV4 client).
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
18:40:04.030651 IP localhost.2030 > localhost.2020: S 1832536952:1832536952(0) win 32792 <nop,nop,md5:can't check - c32795a5d779fd628bbb64da9e859338,mss 16396,nop,nop,sackOK,nop,wscale 6>
18:40:04.030701 IP localhost.2020 > localhost.2030: S 1841519788:1841519788(0) ack 1832536953 win 32792 <nop,nop,md5:can't check - bc0f025d8fa81bf45afe656b21fef9ca,mss 16396,nop,nop,sackOK,nop,wscale 6>
18:40:07.026693 IP localhost.2030 > localhost.2020: S 1832536952:1832536952(0) win 32792 <nop,nop,md5:can't check - c32795a5d779fd628bbb64da9e859338,mss 16396,nop,nop,sackOK,nop,wscale 6>
18:40:07.026739 IP localhost.2020 > localhost.2030: S 1841519788:1841519788(0) ack 1832536953 win 32792 <nop,nop,md5:can't check - bc0f025d8fa81bf45afe656b21fef9ca,mss 16396,nop,nop,sackOK,nop,wscale 6>
18:40:08.226682 IP localhost.2020 > localhost.2030: S 1841519788:1841519788(0) ack 1832536953 win 32792 <nop,nop,md5:can't check - bc0f025d8fa81bf45afe656b21fef9ca,mss 16396,nop,nop,sackOK,nop,wscale 6>
To reproduce:
$ server -6 2020 127.0.0.1 2030 testkey &
$ client -4 localhost 2020 127.0.0.1 2030 testkey
...
[-- Attachment #2: client.c --]
[-- Type: text/x-c++src, Size: 3526 bytes --]
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <arpa/inet.h>
#define BUF_SIZE 500
static int local_bind(int sock, int family, const char *host,
unsigned short port)
{
int s;
if (family == AF_INET) {
struct sockaddr_in sin = {
.sin_family = AF_INET,
.sin_port = htons(port),
};
s = inet_pton(AF_INET, host, &sin.sin_addr);
if (s <= 0) {
if (s == 0)
fprintf(stderr,
"%s: not in valid ipv4 format\n", host);
else
perror("inet_pton");
exit(EXIT_FAILURE);
}
return bind(sock, (struct sockaddr *)&sin, sizeof(sin));
} else if (family == AF_INET6) {
struct sockaddr_in6 sin6 = {
.sin6_family = AF_INET6,
.sin6_port = htons(port),
};
s = inet_pton(AF_INET6, host, &sin6.sin6_addr);
if (s <= 0) {
if (s == 0)
fprintf(stderr,
"%s: not in valid ipv6 format\n", host);
else
perror("inet_pton");
exit(EXIT_FAILURE);
}
return bind(sock, (struct sockaddr *)&sin6, sizeof(sin6));
} else {
fprintf(stderr, "Unknown family: %d\n", family);
}
return 0;
}
static void md5set(int sock, struct sockaddr *sa, socklen_t salen,
const char *password)
{
struct tcp_md5sig md5sig;
memset(&md5sig, 0, sizeof(md5sig));
memcpy(&md5sig.tcpm_addr, sa, salen);
memcpy(md5sig.tcpm_key, password, md5sig.tcpm_keylen =
strlen(password));
if (setsockopt(sock, IPPROTO_TCP, TCP_MD5SIG, &md5sig, sizeof md5sig) <
0)
perror("setsockopt (TCP_MD5SIG)");
}
static void usage(void)
{
fprintf(stderr,
"Usage: client [-6|-4] host port [lhost lport passwd]\n");
exit(EXIT_FAILURE);
}
int main(int argc, char *argv[])
{
struct addrinfo *result, *rp;
int sfd, s;
ssize_t nread;
char buf[BUF_SIZE];
struct addrinfo hints = {
.ai_socktype = SOCK_STREAM,
};
if (argc > 1 && argv[1][0] == '-') {
if (strcmp(argv[1], "-4") == 0) {
hints.ai_family = AF_INET;
} else if (strcmp(argv[1], "-6") == 0) {
hints.ai_family = AF_INET6;
} else
usage();
--argc, ++argv;
}
if (argc < 3)
usage();
/* Obtain address(es) matching host/port */
s = getaddrinfo(argv[1], argv[2], &hints, &result);
if (s != 0) {
fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(s));
exit(EXIT_FAILURE);
}
/* getaddrinfo() returns a list of address structures.
Try each address until we successfully connect(2).
If socket(2) (or connect(2)) fails, we (close the socket
and) try the next address. */
for (rp = result; rp != NULL; rp = rp->ai_next) {
sfd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
if (sfd == -1) {
perror("socket");
continue;
}
if (argc > 3) {
local_bind(sfd, rp->ai_family, argv[3], atoi(argv[4]));
md5set(sfd, rp->ai_addr, rp->ai_addrlen, argv[5]);
}
printf("connecting to %s..",
inet_ntop(rp->ai_family, rp->ai_addr, buf, sizeof(buf)));
fflush(stdout);
if (connect(sfd, rp->ai_addr, rp->ai_addrlen) != -1)
break; /* Success */
perror("connect");
close(sfd);
}
if (rp == NULL) { /* No address succeeded */
fprintf(stderr, "Could not connect\n");
exit(EXIT_FAILURE);
}
freeaddrinfo(result); /* No longer needed */
printf("connected\n");
while ((nread = read(0, buf, sizeof(buf))) > 0) {
if (write(sfd, buf, nread) < 0)
break;
nread = read(sfd, buf, sizeof(buf));
if (nread <= 0)
break;
if (write(1, buf, nread) != nread)
break;
}
exit(EXIT_SUCCESS);
}
[-- Attachment #3: server.c --]
[-- Type: text/x-c++src, Size: 3544 bytes --]
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <arpa/inet.h>
void md5_set(int sock, int family,
const char *host, unsigned short port, const char *password)
{
struct tcp_md5sig md5sig;
int s;
memset(&md5sig, 0, sizeof(md5sig));
if (family == AF_INET6) {
struct sockaddr_in6 sin6 = {
.sin6_family = family,
.sin6_port = htons(port),
};
if (strchr(host, ':') == NULL) {
/* convert V4 address to mapped */
sin6.sin6_addr.s6_addr32[2] = htonl(0xffff);
s = inet_pton(AF_INET, host,
&sin6.sin6_addr.s6_addr32[3]);
if (s == 0)
fprintf(stderr, "%s: not in IPV4 format\n",
host);
} else {
s = inet_pton(AF_INET6, host, &sin6.sin6_addr);
if (s == 0)
fprintf(stderr, "%s: not in IPV6 format\n",
host);
}
memcpy(&md5sig.tcpm_addr, &sin6, sizeof(sin6));
} else {
struct sockaddr_in sin = {
.sin_family = family,
.sin_port = htons(port),
};
s = inet_pton(AF_INET, host, &sin.sin_addr);
if (s == 0)
fprintf(stderr, "%s: not in IPV4 format\n", host);
memcpy(&md5sig.tcpm_addr, &sin, sizeof(sin));
}
if (s <= 0)
exit(EXIT_FAILURE);
memcpy(md5sig.tcpm_key, password, md5sig.tcpm_keylen =
strlen(password));
if (setsockopt(sock, IPPROTO_TCP, TCP_MD5SIG, &md5sig, sizeof(md5sig)) <
0)
perror("setsockopt (TCP_MD5SIG)");
}
static void usage(void)
{
fprintf(stderr, "Usage: server port [host port passwd]\n");
exit(EXIT_FAILURE);
}
int main(int argc, char *argv[])
{
struct addrinfo *result, *rp;
int sfd, s, cc;
static struct addrinfo hints = {
.ai_family = AF_UNSPEC,
.ai_flags = AI_PASSIVE,
.ai_socktype = SOCK_STREAM,
};
char buf[BUFSIZ];
if (argc > 1 && argv[1][0] == '-') {
if (strcmp(argv[1], "-4") == 0) {
hints.ai_family = AF_INET;
} else if (strcmp(argv[1], "-6") == 0) {
hints.ai_family = AF_INET6;
} else
usage();
--argc, ++argv;
}
if (argc < 2)
usage();
s = getaddrinfo(NULL, argv[1], &hints, &result);
if (s != 0) {
fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(s));
exit(EXIT_FAILURE);
}
for (rp = result; rp != NULL; rp = rp->ai_next) {
sfd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
if (sfd == -1) {
perror("socket");
continue;
}
if (bind(sfd, rp->ai_addr, rp->ai_addrlen) == 0)
break; /* Success */
perror("bind");
close(sfd);
}
if (rp == NULL) { /* No address succeeded */
fprintf(stderr, "Could not bind\n");
exit(EXIT_FAILURE);
}
if (listen(sfd, 5) < 0)
perror("listen");
if (argc > 2)
md5_set(sfd, rp->ai_family, argv[2], atoi(argv[3]), argv[4]);
freeaddrinfo(result); /* No longer needed */
for (;;) {
struct sockaddr_storage peer_addr;
socklen_t peer_addr_len = sizeof(peer_addr);
char host[NI_MAXHOST], service[NI_MAXSERV];
int afd =
accept(sfd, (struct sockaddr *)&peer_addr, &peer_addr_len);
if (afd < 0) {
perror("accept");
return 1;
}
s = getnameinfo((struct sockaddr *)&peer_addr,
peer_addr_len, host, NI_MAXHOST,
service, NI_MAXSERV, NI_NUMERICSERV);
if (s == 0)
printf("Connect from %s:%s\n", host, service);
else
fprintf(stderr, "getnameinfo: %s\n", gai_strerror(s));
if (fork() == 0) {
close(sfd);
while ((cc = read(afd, buf, sizeof(buf))) > 0)
if (write(afd, buf, cc) != cc)
break;
if (cc < 0)
perror("read");
else
printf("eof\n");
exit(0);
}
close(afd);
}
}
^ permalink raw reply
* Re: [PATCH] net: deprecate print_mac
From: David Miller @ 2009-07-15 18:40 UTC (permalink / raw)
To: johannes; +Cc: netdev
In-Reply-To: <1247682926.10754.28.camel@johannes.local>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 15 Jul 2009 20:35:26 +0200
> There was one more user in fcoe where I've sent the
> conversion to the scsi folks, here:
> http://marc.info/?l=linux-scsi&m=124767208229782&w=2
Yep, I noticed that.
^ permalink raw reply
* Re: [PATCH] net: deprecate print_mac
From: Johannes Berg @ 2009-07-15 18:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090715.113156.120453022.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]
On Wed, 2009-07-15 at 11:31 -0700, David Miller wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Wed, 15 Jul 2009 17:23:23 +0200
>
> > We've had %pM for long enough now, time to deprecate
> > print_mac() and remove the __maybe_unused attribute
> > from DECLARE_MAC_BUF so that variables declared with
> > that can be found and removed. Otherwise people are
> > putting in new users of print_mac().
> I think I'm going to apply this after John's next
> wireless merge to me for net-next-2.6
Sounds good. There was one more user in fcoe where I've sent the
conversion to the scsi folks, here:
http://marc.info/?l=linux-scsi&m=124767208229782&w=2
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] net: deprecate print_mac
From: David Miller @ 2009-07-15 18:31 UTC (permalink / raw)
To: johannes; +Cc: netdev
In-Reply-To: <1247671403.10754.8.camel@johannes.local>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 15 Jul 2009 17:23:23 +0200
> We've had %pM for long enough now, time to deprecate
> print_mac() and remove the __maybe_unused attribute
> from DECLARE_MAC_BUF so that variables declared with
> that can be found and removed. Otherwise people are
> putting in new users of print_mac().
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> On my tree, with three other patches I have submitted
> to gianfar, fcoe and wireless, there's now no user of
> DECLARE_MAC_BUF() left. I'm open to just killing it
> right away, but that seems like a pain to coordinate
> and would likely get merge conflicts, so this is much
> simpler and then killing it next cycle.
I think I'm going to apply this after John's next
wireless merge to me for net-next-2.6
^ permalink raw reply
* Re: [PATCH] gianfar: remove unused DECLARE_MAC_BUF
From: David Miller @ 2009-07-15 18:31 UTC (permalink / raw)
To: johannes; +Cc: netdev, galak
In-Reply-To: <1247671139.10754.3.camel@johannes.local>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 15 Jul 2009 17:18:59 +0200
> The use of it was converted to %pM, but the variable
> stuck -- remove it now to not cause spurious warnings.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] net/can: add module alias to can protocol drivers
From: David Miller @ 2009-07-15 18:21 UTC (permalink / raw)
To: LW; +Cc: netdev, oliver, herbert, wg, urs.thuermann, urs
In-Reply-To: <19037.40313.827769.602243@ipc1.ka-ro>
From: Lothar Waßmann <LW@KARO-electronics.de>
Date: Wed, 15 Jul 2009 11:12:25 +0200
> Add appropriate MODULE_ALIAS() to facilitate autoloading of can protocol drivers
>
> Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de>
> Acked-by: Oliver Hartkopp <oliver@hartkopp.net>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox