* R: Re: mtu issue with ipsec tunnel and netfilter snat
From: pupilla @ 2013-01-09 9:55 UTC (permalink / raw)
To: jengelh; +Cc: netdev
jengelh@inai.de wrote:
>On Wednesday 2013-01-09 10:01, pupilla@libero.it wrote:
>
>>As you can see there are incoming 1500 bytes packets (these are the
>>decrypted ipsec packets) with DF bit set. These packets are never
>>delivered to the final client 10.81.128.176 (the destination address
>>is 172.16.128.1 which is the ip used for SNATing the original ip
>>10.81.128.176).
>>
>>IMHO this is a mtu issue: 1500 bytes packets cannot be routed inside
>>the ipsec tunnel.
>>
>>But why linux_gw_snat is not sending icmp need to frag packets to
>>10.148.12.23?
>
>Perhaps because ICMP was blocked erroneously?
No, I have opened the firewall
rules with something like:
iptables -I OUTPUT --proto icmp -j ACCEPT
iptables -I INPUT --proto icmp -j ACCEPT
^ permalink raw reply
* Re: r8169 rx_missed increasing in bursts (regression)
From: Timo Teras @ 2013-01-09 9:58 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20130108225833.GA4193@electric-eye.fr.zoreil.com>
On Tue, 8 Jan 2013 23:58:33 +0100 Francois Romieu
<romieu@fr.zoreil.com> wrote:
> Timo Teras <timo.teras@iki.fi> :
> [...]
> > My current hypothesis is that due to high softirq and recent(ish)
> > commit da78dbf "r8169: remove work from irq handler" moving more
> > work to softirq makes the receive path now suffer from latency from
> > getting irq to reading packets from the NIC on these boxes. And
> > that at times the rx fifo can get full causing a missed packet or
> > so.
>
> This hypothesis won't explain the regression in 3.3.8 since 3.3.x does
> not include commit da78dbf.
>
> Do you notice any netdev watchdog message in dmesg ?
In production boxes. No.
The lab environment where we tried to reproduce this, we received:
NOHZ: local_softirq_pending 08
Which is likely related, but separate issue. And fixed by commit
da78dbf. So seems that just got upgraded to "regression fix".
> 'perf top' may exhibit something unusual too.
Will try this.
I did notice that:
/proc/net/softnet_stat's 3rd field aka. softnet_data.time_squeeze keeps
incrementing when ever rx_missed increases. Sometiems time_squeeze
increments on it own. But rx_missed never increases without time_squeeze
bumping up seriously too.
> > This might be further escalated by the bug fixed in commit 7dbb491
> > "r8169: avoid NAPI scheduling delay" (which is not present in
> > -stable trees).
>
> Right, it would had been worth adding to -stable.
>
> However it only 1) is a problem for 3.4.x (fixed in 3.5) and 2)
> triggers when returning from the slow work thread - which should not
> be used much.
Ok. Didn't realize 3.3.x did not include it. So something else is broke
too.
The slow thread handles the RxOverflow, and in rx_missed case is taken
relatively often. Maybe add a printk there.
> [...]
> > So would it be sensible to do something like:
> > -#define NUM_RX_DESC 256 /* Number of Rx descriptor
> > registers */ +#define NUM_RX_DESC 512 /* Number of Rx
> > descriptor registers */
>
> You can try it but it may actually increase the amount of heavy work
> done in softirq.
Ok. Will try this and some other things along with added debug logging.
^ permalink raw reply
* [PATCH net-next] igbvf: fix setting addr_assign_type if PF is up
From: Stefan Assmann @ 2013-01-09 9:59 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, sassmann
When the PF is up and igbvf is loaded the MAC address is not generated using
eth_hw_addr_random(). This results in addr_assign_type not to be set.
Make sure it gets set.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/ethernet/intel/igbvf/netdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 53281ff..6a698c5 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2746,6 +2746,7 @@ static int igbvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
dev_err(&pdev->dev, "Error reading MAC address\n");
goto err_hw_init;
}
+ netdev->addr_assign_type = NET_ADDR_RANDOM;
memcpy(netdev->dev_addr, adapter->hw.mac.addr,
netdev->addr_len);
}
--
1.8.0.2
------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: [Xen-devel] xen-netback notify DomU to send ARP.
From: Jan Beulich @ 2013-01-09 10:06 UTC (permalink / raw)
To: jianhai luan; +Cc: Ian Campbell, xen-devel, Konrad Rzeszutek Wilk, netdev
In-Reply-To: <50ED1EB3.3080605@oracle.com>
>>> On 09.01.13 at 08:39, jianhai luan <jianhai.luan@oracle.com> wrote:
>@@ -34,11 +35,42 @@ static void connect(struct backend_info *);
> static void backend_create_xenvif(struct backend_info *be);
> static void unregister_hotplug_status_watch(struct backend_info *be);
>
>+#define nb_to_backend(nb) container_of(nb, struct backend_info, vif_notifier)
>+/**
>+ * When network condition of vif change, notify the frontend.
>+ */
>+static int netback_netdev_event(struct notifier_block *this,
>+ unsigned long event, void *ptr)
>+{
>+ struct net_device *event_dev = (struct net_device *)ptr;
Pointless cast.
>+ struct backend_info *be = nb_to_backend(this);
>+
>+ pr_debug("event_dev: %s, event: %lx\n",
>+ event_dev ? event_dev->name : "None", event);
>+
>+ if (!be->vif)
>+ goto out;
>+
>+ switch (event) {
>+ case NETDEV_NOTIFY_PEERS:
>+ /* Notify frontend to Send gratuitous ARP */
>+ xenbus_switch_state(be->dev, XenbusStateInitialised);
>+ xenbus_switch_state(be->dev, XenbusStateConnected);
This is the sort of change that clearly isn't acceptable, as I don't
think you have ways to check _all_ existing frontends for their
compatibility with this. A connected -> connected transition
might be acceptable (that was done in the block frontend too, for
implementing dynamic resize), but will likely need to be
accompanied by a frontend side patch to handle that (which so
far should be a no-op).
>+ break;
>+ default:
>+ break;
Pointless default case.
>+ }
>+
>+out:
I don't think you really need the label (and the goto above) - just
put a return there.
>+ return NOTIFY_DONE;
>+}
>+
> static int netback_remove(struct xenbus_device *dev)
> {
> struct backend_info *be = dev_get_drvdata(&dev->dev);
>
> unregister_hotplug_status_watch(be);
>+ unregister_netdevice_notifier(&be->vif_notifier);
> if (be->vif) {
> kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE);
> xenbus_rm(XBT_NIL, dev->nodename, "hotplug-status");
>@@ -129,6 +161,10 @@ static int netback_probe(struct xenbus_device *dev,
> /* This kicks hotplug scripts, so do it immediately. */
> backend_create_xenvif(be);
>
>+ /* Register Frontend Event Notify */
>+ (be->vif_notifier).notifier_call = netback_netdev_event;
Pointless parentheses.
Jan
>+ register_netdevice_notifier(&be->vif_notifier);
>+
> return 0;
>
> abort_transaction:
^ permalink raw reply
* Re: [Xen-devel] xen-netback notify DomU to send ARP.
From: Ian Campbell @ 2013-01-09 12:03 UTC (permalink / raw)
To: Jason Luan
Cc: xen-devel@lists.xensource.com, netdev@vger.kernel.org,
konrad.wilk@oracle.com
In-Reply-To: <50ECC2C4.5060501@163.com>
On Wed, 2013-01-09 at 01:07 +0000, Jason Luan wrote:
> 于 2013年01月09日 00:00, Ian Campbell 写道:
> > On Tue, 2013-01-08 at 15:40 +0000, jianhai luan wrote:
> >> On 2013-1-8 21:42, Ian Campbell wrote:
> >>> On Tue, 2013-01-08 at 13:13 +0000, Jan Beulich wrote:
> >>>>>>> On 08.01.13 at 12:57, jianhai luan <jianhai.luan@oracle.com>
> >>>>>>> wrote:
> >>>>> When Xen Dom0's network circumstance changed, DomU
> >>>>> should be notified in some special condition. For
> >>>>> example the below circumstance:
> >>>>> ping from Guest A to DomU:
> >>>>> Guest A --> eth0 - bond0 - xenbr0 --VIF(DOMU)
> >>>>> eth1 /
> >>>>> when eth0 inactive, and eth1 active.
> >>> How is eth0 failing? Are you unplugging it, un-enslaving it or
> >>> taking
> >>> some other sort of administrative action?
> >> In my emulation environment, i unplug it or ifdown the interface,
> > I expect these would behave rather different, since the affect of ifdown
> > looks rather different to an unplug from the PoV of the switch.
> >
> > Is the ifdown case something which you are trying to solve or just what
> > appeared to be a convenient test case? I'd be less inclined to worry
> > about explict admin actions such as that.
> >
> > Unplugging the cable should cause:
> >
> I do above listed thing to let switch active slave only.
> I think that we should put attention on the thing which bond switch
> active slave interface in active-backup mode. In network circumstance,
> many thing will cause the switch, what do Vif when the event happen?
Sorry, I'm having a bit of trouble parsing the above, but are you asking
what the VIF should do when the active slave in the bond changes without
the previously active slave actually failing?
The issue is that traffic will continue to arrive on the now inactive
slave, but will be discarded (the expected behaviour for
Active/Passive)?
Is this something which happens in practice? Does the active slave
change even while it remains a viable path?
Ian.
^ permalink raw reply
* Re: [Xen-devel] xen-netback notify DomU to send ARP.
From: jianhai luan @ 2013-01-09 12:28 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, netdev, Jan Beulich, Konrad Rzeszutek Wilk
In-Reply-To: <50ED4F1D02000078000B3F87@nat28.tlf.novell.com>
[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]
On 2013-1-9 18:06, Jan Beulich wrote:
>>>> On 09.01.13 at 08:39, jianhai luan <jianhai.luan@oracle.com> wrote:
>> @@ -34,11 +35,42 @@ static void connect(struct backend_info *);
>> static void backend_create_xenvif(struct backend_info *be);
>> static void unregister_hotplug_status_watch(struct backend_info *be);
>>
>> +#define nb_to_backend(nb) container_of(nb, struct backend_info, vif_notifier)
>> +/**
>> + * When network condition of vif change, notify the frontend.
>> + */
>> +static int netback_netdev_event(struct notifier_block *this,
>> + unsigned long event, void *ptr)
>> +{
>> + struct net_device *event_dev = (struct net_device *)ptr;
> Pointless cast.
>
>> + struct backend_info *be = nb_to_backend(this);
>> +
>> + pr_debug("event_dev: %s, event: %lx\n",
>> + event_dev ? event_dev->name : "None", event);
>> +
>> + if (!be->vif)
>> + goto out;
>> +
>> + switch (event) {
>> + case NETDEV_NOTIFY_PEERS:
>> + /* Notify frontend to Send gratuitous ARP */
>> + xenbus_switch_state(be->dev, XenbusStateInitialised);
>> + xenbus_switch_state(be->dev, );
> This is the sort of change that clearly isn't acceptable, as I don't
> think you have ways to check _all_ existing frontends for their
> compatibility with this. A connected -> connected transition
> might be acceptable (that was done in the block frontend too, for
> implementing dynamic resize), but will likely need to be
> accompanied by a frontend side patch to handle that (which so
> far should be a no-op).
The latest xen net-frontent driver have handled the condition. State
XenbusStateInitialised will do nothing,
but change to XenbusStateConnected will trigger
netdev_notify_peers(netdev) to send ARP.
>
>> + break;
>> + default:
>> + break;
> Pointless default case.
>
>> + }
>> +
>> +out:
> I don't think you really need the label (and the goto above) - just
> put a return there.
>
>> + return NOTIFY_DONE;
>> +}
>> +
>> static int netback_remove(struct xenbus_device *dev)
>> {
>> struct backend_info *be = dev_get_drvdata(&dev->dev);
>>
>> unregister_hotplug_status_watch(be);
>> + unregister_netdevice_notifier(&be->vif_notifier);
>> if (be->vif) {
>> kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE);
>> xenbus_rm(XBT_NIL, dev->nodename, "hotplug-status");
>> @@ -129,6 +161,10 @@ static int netback_probe(struct xenbus_device *dev,
>> /* This kicks hotplug scripts, so do it immediately. */
>> backend_create_xenvif(be);
>>
>> + /* Event Notify */
>> + (be->vif_notifier).notifier_call = netback_netdev_event;
> Pointless parentheses.
>
> Jan
>
>> + register_netdevice_notifier(&be->vif_notifier);
>> +
>> return 0;
>>
>> abort_transaction:
>
[-- Attachment #2: 0001-xen-netback-notify-DomU-to-send-ARP.patch --]
[-- Type: text/plain, Size: 3126 bytes --]
>From a64d80cc0c780bee7a8d6e842126cb5f7d17f0d2 Mon Sep 17 00:00:00 2001
From: Jason Luan <jianhai.luan@oracle.com>
Date: Fri, 28 Dec 2012 15:43:06 +0800
Subject: [PATCH] xen-netback notify DomU to send ARP.
When Xen Dom0's network circumstance changed, DomU
should be notified in some special condition. For
example the below circumstance:
ping from Guest A to DomU:
Guest A --> eth0 - bond0 - xenbr0 --VIF(DOMU)
eth1 /
when eth0 inactive, and eth1 active.
Guest A --> eth0 bond0 - xenbr0 --VIF(DOMU)
eth1 /
Guest A will don't reach to DomU. After Guest A
send ARP request and DomU respond, Guest A will
reach DomU. But some more second will be elapsed.
eth0 bond0 - xenbr0 --VIF(DOMU)
Guest A --> eth1/
If Xen netback watch the network change, will notify
DomU by change it own status. So netfront will watch
netback's change, and DomU send ARP initiative.
Signed-off-by: Jason Luan <jianhai.luan@oracle.com>
---
drivers/net/xen-netback/xenbus.c | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..17a3990 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -26,6 +26,7 @@ struct backend_info {
struct xenvif *vif;
enum xenbus_state frontend_state;
struct xenbus_watch hotplug_status_watch;
+ struct notifier_block vif_notifier;
u8 have_hotplug_status_watch:1;
};
@@ -34,11 +35,39 @@ static void connect(struct backend_info *);
static void backend_create_xenvif(struct backend_info *be);
static void unregister_hotplug_status_watch(struct backend_info *be);
+#define nb_to_backend(nb) container_of(nb, struct backend_info, vif_notifier)
+/**
+ * When network condition of vif change, notify the frontend.
+ */
+static int netback_netdev_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ struct net_device *event_dev = ptr;
+ struct backend_info *be = nb_to_backend(this);
+
+ pr_debug("event_dev: %s, event: %lx\n",
+ event_dev ? event_dev->name : "None", event);
+
+ if (!be->vif)
+ return NOTIFY_DONE;
+
+ switch (event) {
+ case NETDEV_NOTIFY_PEERS:
+ /* Notify frontend to Send gratuitous ARP */
+ xenbus_switch_state(be->dev, XenbusStateInitialised);
+ xenbus_switch_state(be->dev, XenbusStateConnected);
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
static int netback_remove(struct xenbus_device *dev)
{
struct backend_info *be = dev_get_drvdata(&dev->dev);
unregister_hotplug_status_watch(be);
+ unregister_netdevice_notifier(&be->vif_notifier);
if (be->vif) {
kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE);
xenbus_rm(XBT_NIL, dev->nodename, "hotplug-status");
@@ -129,6 +158,10 @@ static int netback_probe(struct xenbus_device *dev,
/* This kicks hotplug scripts, so do it immediately. */
backend_create_xenvif(be);
+ /* Register Frontend Event Notify */
+ be->vif_notifier.notifier_call = netback_netdev_event;
+ register_netdevice_notifier(&be->vif_notifier);
+
return 0;
abort_transaction:
--
1.7.6.5
^ permalink raw reply related
* tainted warnings with tcp splicing in 3.7.1
From: Christian Becker @ 2013-01-09 13:01 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi,
we´ve installed 3.7.1 yesterday on one of our loadbalancer nodes in order to get TFO.
Unfortunately the kernel started to print warnings every couple of minutes when using tcp splicing in haproxy.
We´ve built the kernel yesterday from the 3.7.1 sources without any modifications.
The System contains two Intel Xeon X6550, 64 GB RAM and there are two kinds of NICs:
Broadcom Corporation NetXtreme II BCM5709 (Driver bnx2)
Emulex Corporation OneConnect 10Gb NIC (Driver be2net)
The bnx2 adapters are not in use and disconnected and the be2net handle about 1 GBit/s of traffic.
We´ve downgraded again to our old kernel version, but i guess you should take a look at this.
There are two kinds of messages:
an 9 11:34:28 srv11 kernel: [ 1081.334970] ------------[ cut here ]------------
Jan 9 11:34:28 srv11 kernel: [ 1081.353685] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:34:28 srv11 kernel: [ 1081.371956] Hardware name: System x3690 X5 -[7148Z68]-
Jan 9 11:34:28 srv11 kernel: [ 1081.391820] cleanup rbuf bug: copied AD3BCF1 seq AD370AF rcvnxt AD3CF13
Jan 9 11:34:28 srv11 kernel: [ 1081.408971] Modules linked in: 8021q garp stp llc nls_utf8 nls_cp437 vfat fat kvm_intel coretemp kvm joydev acpi_cpufreq mperf crc32c_intel hid_generic shpchp snd_pcm snd_timer snd lpc_ich mfd_core cdc_ether usb
net mii evdev serio_raw ioatdma processor i2c_i801 tpm_tis dca soundcore snd_page_alloc pcspkr tpm microcode i2c_core tpm_bios thermal_sys button pci_hotplug ext4 mbcache jbd2 crc16 dm_mod sg sr_mod cdrom sd_mod crc_t10dif usbhid ata_generic hi
d uhci_hcd ata_piix libata megaraid_sas bnx2 ehci_hcd usbcore scsi_mod usb_common be2net
Jan 9 11:34:28 srv11 kernel: [ 1081.532314] Pid: 13763, comm: haproxy Not tainted 3.7.1 #1
Jan 9 11:34:28 srv11 kernel: [ 1081.554349] Call Trace:
Jan 9 11:34:28 srv11 kernel: [ 1081.573762] [<ffffffff8103ef70>] ? warn_slowpath_common+0x78/0x8c
Jan 9 11:34:28 srv11 kernel: [ 1081.596750] [<ffffffff8103f023>] ? warn_slowpath_fmt+0x45/0x4a
Jan 9 11:34:28 srv11 kernel: [ 1081.617853] [<ffffffff81297d06>] ? sock_pipe_buf_release+0xe/0xe
Jan 9 11:34:28 srv11 kernel: [ 1081.639111] [<ffffffff812d37c2>] ? tcp_cleanup_rbuf+0x4d/0xfc
Jan 9 11:34:28 srv11 kernel: [ 1081.661541] [<ffffffff812d39f4>] ? tcp_read_sock+0x183/0x194
Jan 9 11:34:28 srv11 kernel: [ 1081.681164] [<ffffffff812d423d>] ? tcp_sendpage+0x45b/0x45b
Jan 9 11:34:28 srv11 kernel: [ 1081.703355] [<ffffffff812d3ad8>] ? tcp_splice_read+0xd3/0x223
Jan 9 11:34:28 srv11 kernel: [ 1081.724912] [<ffffffff8112d9b9>] ? sys_splice+0x345/0x3c0
Jan 9 11:34:28 srv11 kernel: [ 1081.744525] [<ffffffff81364b69>] ? system_call_fastpath+0x16/0x1b
Jan 9 11:34:28 srv11 kernel: [ 1081.766683] ---[ end trace fb4ffd749d51e56f ]---
Jan 9 11:52:42 srv11 kernel: [ 2174.882971] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:42 srv11 kernel: [ 2174.901182] Hardware name: System x3690 X5 -[7148Z68]-
Jan 9 11:52:42 srv11 kernel: [ 2174.921229] recvmsg bug 2: copied 4B9C4CE6 seq 4B9BE950 rcvnxt 4B9C4CE6 fl 0
Jan 9 11:52:42 srv11 kernel: [ 2174.941681] Modules linked in: 8021q garp stp llc nls_utf8 nls_cp437 vfat fat kvm_intel coretemp kvm joydev acpi_cpufreq mperf crc32c_intel hid_generic shpchp snd_pcm snd_timer snd lpc_ich mfd_core cdc_ether usb
net mii evdev serio_raw ioatdma processor i2c_i801 tpm_tis dca soundcore snd_page_alloc pcspkr tpm microcode i2c_core tpm_bios thermal_sys button pci_hotplug ext4 mbcache jbd2 crc16 dm_mod sg sr_mod cdrom sd_mod crc_t10dif usbhid ata_generic hi
d uhci_hcd ata_piix libata megaraid_sas bnx2 ehci_hcd usbcore scsi_mod usb_common be2net
Jan 9 11:52:42 srv11 kernel: [ 2175.075389] Pid: 13250, comm: haproxy Tainted: G W 3.7.1 #1
Jan 9 11:52:42 srv11 kernel: [ 2175.099391] Call Trace:
Jan 9 11:52:42 srv11 kernel: [ 2175.122727] [<ffffffff8103ef70>] ? warn_slowpath_common+0x78/0x8c
Jan 9 11:52:42 srv11 kernel: [ 2175.147250] [<ffffffff8103f023>] ? warn_slowpath_fmt+0x45/0x4a
Jan 9 11:52:42 srv11 kernel: [ 2175.170289] [<ffffffff81295f64>] ? release_sock+0xe6/0x11c
Jan 9 11:52:43 srv11 kernel: [ 2175.192639] [<ffffffff812d45d2>] ? tcp_recvmsg+0x2ca/0x9de
Jan 9 11:52:43 srv11 kernel: [ 2175.215020] [<ffffffff812e0b71>] ? tcp_write_xmit+0x849/0x946
Jan 9 11:52:43 srv11 kernel: [ 2175.237682] [<ffffffff812f2720>] ? inet_recvmsg+0x64/0x75
Jan 9 11:52:43 srv11 kernel: [ 2175.259727] [<ffffffff8129052d>] ? sock_recvmsg+0x56/0x6e
Jan 9 11:52:43 srv11 kernel: [ 2175.281111] [<ffffffff8128fedf>] ? sockfd_lookup_light+0x1a/0x50
Jan 9 11:52:43 srv11 kernel: [ 2175.300573] [<ffffffff812923f4>] ? sys_recvfrom+0xbf/0x120
Jan 9 11:52:43 srv11 kernel: [ 2175.320073] [<ffffffff8135d9f7>] ? __schedule+0x4c9/0x4f6
Jan 9 11:52:43 srv11 kernel: [ 2175.341151] [<ffffffff81364b69>] ? system_call_fastpath+0x16/0x1b
Jan 9 11:52:43 srv11 kernel: [ 2175.360859] ---[ end trace fb4ffd749d51e5a7 ]---
As you can see here, the messages are appearing every couple of minutes:
Jan 9 11:34:28 srv11 kernel: [ 1081.353685] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:34:29 srv11 kernel: [ 1081.809446] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:34:29 srv11 kernel: [ 1082.235052] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:34:29 srv11 kernel: [ 1082.692732] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:34:30 srv11 kernel: [ 1083.177807] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:34:30 srv11 kernel: [ 1083.698475] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:34:31 srv11 kernel: [ 1084.221899] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:34:31 srv11 kernel: [ 1084.746992] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:34:32 srv11 kernel: [ 1085.267199] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:37:16 srv11 kernel: [ 1249.252200] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:37:17 srv11 kernel: [ 1249.782915] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:37:17 srv11 kernel: [ 1250.315653] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:37:18 srv11 kernel: [ 1250.867306] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:37:18 srv11 kernel: [ 1251.383968] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:37:19 srv11 kernel: [ 1251.897631] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:37:19 srv11 kernel: [ 1252.412535] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:37:20 srv11 kernel: [ 1252.921313] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:40:13 srv11 kernel: [ 1425.644620] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:40:13 srv11 kernel: [ 1426.314292] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:40:14 srv11 kernel: [ 1426.749374] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:40:14 srv11 kernel: [ 1427.198672] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:40:15 srv11 kernel: [ 1427.711731] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:40:15 srv11 kernel: [ 1428.189284] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:40:16 srv11 kernel: [ 1428.701230] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:09 srv11 kernel: [ 1781.780019] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:09 srv11 kernel: [ 1782.350094] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:10 srv11 kernel: [ 1782.853933] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:10 srv11 kernel: [ 1783.303487] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:11 srv11 kernel: [ 1783.757022] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:11 srv11 kernel: [ 1784.260932] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:46:12 srv11 kernel: [ 1784.874611] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:46:13 srv11 kernel: [ 1785.457209] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:46:13 srv11 kernel: [ 1785.933210] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:46:14 srv11 kernel: [ 1786.400550] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:14 srv11 kernel: [ 1786.941620] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:46:15 srv11 kernel: [ 1787.510305] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:46:15 srv11 kernel: [ 1788.077590] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:54 srv11 kernel: [ 1827.316572] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:55 srv11 kernel: [ 1827.721460] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:55 srv11 kernel: [ 1828.150593] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:56 srv11 kernel: [ 1828.620180] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:56 srv11 kernel: [ 1829.120693] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:46:57 srv11 kernel: [ 1829.597494] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:46:57 srv11 kernel: [ 1830.189551] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:46:58 srv11 kernel: [ 1830.745157] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:46:58 srv11 kernel: [ 1831.299635] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:46:59 srv11 kernel: [ 1831.852929] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:47:00 srv11 kernel: [ 1832.408950] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:52:38 srv11 kernel: [ 2170.882305] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:52:39 srv11 kernel: [ 2171.342827] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:39 srv11 kernel: [ 2171.853599] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:40 srv11 kernel: [ 2172.355757] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:40 srv11 kernel: [ 2172.856194] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:41 srv11 kernel: [ 2173.357738] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:41 srv11 kernel: [ 2173.857774] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:42 srv11 kernel: [ 2174.361131] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
Jan 9 11:52:42 srv11 kernel: [ 2174.882971] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:43 srv11 kernel: [ 2175.397627] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:43 srv11 kernel: [ 2175.911679] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:44 srv11 kernel: [ 2176.424397] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:44 srv11 kernel: [ 2176.940545] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:45 srv11 kernel: [ 2177.456173] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
Jan 9 11:52:45 srv11 kernel: [ 2177.971222] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
^ permalink raw reply
* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Mel Gorman @ 2013-01-09 13:37 UTC (permalink / raw)
To: Eric Wong
Cc: linux-mm, netdev, linux-kernel, Rik van Riel, Minchan Kim,
Eric Dumazet, Andrew Morton, Linus Torvalds
In-Reply-To: <20130108232325.GA5948@dcvr.yhbt.net>
On Tue, Jan 08, 2013 at 11:23:25PM +0000, Eric Wong wrote:
> Mel Gorman <mgorman@suse.de> wrote:
> > Please try the following patch. However, even if it works the benefit of
> > capture may be so marginal that partially reverting it and simplifying
> > compaction.c is the better decision.
>
> I already got my VM stuck on this one. I had two twosleepy instances,
> 2774 was the one that got stuck (also confirmed by watching top).
>
page->pfmemalloc can be left set for captured pages so try this but as
capture is rarely used I'm strongly favouring a partial revert even if
this works for you. I haven't reproduced this using your workload yet
but I have found that high-order allocation stress tests for 3.8-rc2 are
completely screwed. 71% success rates at rest in 3.7 and 6% in 3.8-rc2 so
I have to chase that down too.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9d20c13..c242d21 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2180,8 +2180,10 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
current->flags &= ~PF_MEMALLOC;
/* If compaction captured a page, prep and use it */
- if (page && !prep_new_page(page, order, gfp_mask))
+ if (page && !prep_new_page(page, order, gfp_mask)) {
+ page->pfmemalloc = false;
goto got_page;
+ }
if (*did_some_progress != COMPACT_SKIPPED) {
/* Page migration frees to the PCP lists but we want merging */
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Mel Gorman @ 2013-01-09 13:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Wong, linux-mm, netdev, linux-kernel, Rik van Riel,
Minchan Kim, Andrew Morton, Linus Torvalds
In-Reply-To: <1357698749.27446.6.camel@edumazet-glaptop>
On Tue, Jan 08, 2013 at 06:32:29PM -0800, Eric Dumazet wrote:
> On Tue, 2013-01-08 at 18:14 -0800, Eric Dumazet wrote:
> > On Tue, 2013-01-08 at 23:23 +0000, Eric Wong wrote:
> > > Mel Gorman <mgorman@suse.de> wrote:
> > > > Please try the following patch. However, even if it works the benefit of
> > > > capture may be so marginal that partially reverting it and simplifying
> > > > compaction.c is the better decision.
> > >
> > > I already got my VM stuck on this one. I had two twosleepy instances,
> > > 2774 was the one that got stuck (also confirmed by watching top).
> > >
> > > Btw, have you been able to reproduce this on your end?
> > >
> > > I think the easiest reproduction on my 2-core VM is by running 2
> > > twosleepy processes and doing the following to dirty a lot of pages:
> >
> > Given the persistent sk_stream_wait_memory() traces I suspect a plain
> > TCP bug, triggered by some extra wait somewhere.
> >
> > Please mm guys don't spend too much time right now, I'll try to
> > reproduce the problem.
> >
> > Don't be confused by sk_stream_wait_memory() name.
> > A thread is stuck here because TCP stack is failing to wake it.
> >
>
> Hmm, it seems sk_filter() can return -ENOMEM because skb has the
> pfmemalloc() set.
>
The skb should not have pfmemalloc set in most cases, particularly after
cfd19c5a (mm: only set page->pfmemalloc when ALLOC_NO_WATERMARKS was used)
but the capture patch also failed to clear pfmemalloc properly so it could
be set in error.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [Xen-devel] xen-netback notify DomU to send ARP.
From: Jan Beulich @ 2013-01-09 13:44 UTC (permalink / raw)
To: jianhai luan; +Cc: xen-devel, Konrad Rzeszutek Wilk, netdev
In-Reply-To: <50ED6255.7020006@oracle.com>
>>> On 09.01.13 at 13:28, jianhai luan <jianhai.luan@oracle.com> wrote:
>>> + switch (event) {
>>> + case NETDEV_NOTIFY_PEERS:
>>> + /* Notify frontend to Send gratuitous ARP */
>>> + xenbus_switch_state(be->dev, XenbusStateInitialised);
>>> + xenbus_switch_state(be->dev, );
>> This is the sort of change that clearly isn't acceptable, as I don't
>> think you have ways to check _all_ existing frontends for their
>> compatibility with this. A connected -> connected transition
>> might be acceptable (that was done in the block frontend too, for
>> implementing dynamic resize), but will likely need to be
>> accompanied by a frontend side patch to handle that (which so
>> far should be a no-op).
> The latest xen net-frontent driver have handled the condition. State
> XenbusStateInitialised will do nothing,
> but change to XenbusStateConnected will trigger
> netdev_notify_peers(netdev) to send ARP.
Did you read my earlier reply carefully? You still only talk about
(upstream) Linux netfront, but this is not the only (possible)
frontend. You should not invoke state transitions that can -
even if only theoretically - blow up frontends. And afaict the
only thing you can safely assume frontends ought to tolerate
are transitions from Connected to Connected (or more
generally from one state to the same one, but the other
states aren't useful here, except maybe the Reconfigur* ones).
Jan
^ permalink raw reply
* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Mel Gorman @ 2013-01-09 13:50 UTC (permalink / raw)
To: Eric Wong
Cc: linux-mm, netdev, linux-kernel, Rik van Riel, Minchan Kim,
Eric Dumazet, Andrew Morton, Linus Torvalds
In-Reply-To: <20130109133746.GD13304@suse.de>
On Wed, Jan 09, 2013 at 01:37:46PM +0000, Mel Gorman wrote:
> On Tue, Jan 08, 2013 at 11:23:25PM +0000, Eric Wong wrote:
> > Mel Gorman <mgorman@suse.de> wrote:
> > > Please try the following patch. However, even if it works the benefit of
> > > capture may be so marginal that partially reverting it and simplifying
> > > compaction.c is the better decision.
> >
> > I already got my VM stuck on this one. I had two twosleepy instances,
> > 2774 was the one that got stuck (also confirmed by watching top).
> >
>
> page->pfmemalloc can be left set for captured pages so try this but as
> capture is rarely used I'm strongly favouring a partial revert even if
> this works for you.
Partial revert looks like this
---8<---
---
include/linux/compaction.h | 4 +-
include/linux/mm.h | 1 -
mm/compaction.c | 91 ++++++--------------------------------------
mm/internal.h | 1 -
mm/page_alloc.c | 38 +++++-------------
5 files changed, 23 insertions(+), 112 deletions(-)
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index 6ecb6dc..cc7bdde 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -22,7 +22,7 @@ extern int sysctl_extfrag_handler(struct ctl_table *table, int write,
extern int fragmentation_index(struct zone *zone, unsigned int order);
extern unsigned long try_to_compact_pages(struct zonelist *zonelist,
int order, gfp_t gfp_mask, nodemask_t *mask,
- bool sync, bool *contended, struct page **page);
+ bool sync, bool *contended);
extern int compact_pgdat(pg_data_t *pgdat, int order);
extern void reset_isolation_suitable(pg_data_t *pgdat);
extern unsigned long compaction_suitable(struct zone *zone, int order);
@@ -75,7 +75,7 @@ static inline bool compaction_restarting(struct zone *zone, int order)
#else
static inline unsigned long try_to_compact_pages(struct zonelist *zonelist,
int order, gfp_t gfp_mask, nodemask_t *nodemask,
- bool sync, bool *contended, struct page **page)
+ bool sync, bool *contended)
{
return COMPACT_CONTINUE;
}
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 6320407..66e2f7c 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -455,7 +455,6 @@ void put_pages_list(struct list_head *pages);
void split_page(struct page *page, unsigned int order);
int split_free_page(struct page *page);
-int capture_free_page(struct page *page, int alloc_order, int migratetype);
/*
* Compound pages have a destructor function. Provide a
diff --git a/mm/compaction.c b/mm/compaction.c
index 6b807e4..8bc3066 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -816,6 +816,7 @@ static isolate_migrate_t isolate_migratepages(struct zone *zone,
static int compact_finished(struct zone *zone,
struct compact_control *cc)
{
+ unsigned int order;
unsigned long watermark;
if (fatal_signal_pending(current))
@@ -850,22 +851,15 @@ static int compact_finished(struct zone *zone,
return COMPACT_CONTINUE;
/* Direct compactor: Is a suitable page free? */
- if (cc->page) {
- /* Was a suitable page captured? */
- if (*cc->page)
+ for (order = cc->order; order < MAX_ORDER; order++) {
+ struct free_area *area = &zone->free_area[cc->order];
+ /* Job done if page is free of the right migratetype */
+ if (!list_empty(&area->free_list[cc->migratetype]))
+ return COMPACT_PARTIAL;
+
+ /* Job done if allocation would set block type */
+ if (cc->order >= pageblock_order && area->nr_free)
return COMPACT_PARTIAL;
- } else {
- unsigned int order;
- for (order = cc->order; order < MAX_ORDER; order++) {
- struct free_area *area = &zone->free_area[cc->order];
- /* Job done if page is free of the right migratetype */
- if (!list_empty(&area->free_list[cc->migratetype]))
- return COMPACT_PARTIAL;
-
- /* Job done if allocation would set block type */
- if (cc->order >= pageblock_order && area->nr_free)
- return COMPACT_PARTIAL;
- }
}
return COMPACT_CONTINUE;
@@ -921,60 +915,6 @@ unsigned long compaction_suitable(struct zone *zone, int order)
return COMPACT_CONTINUE;
}
-static void compact_capture_page(struct compact_control *cc)
-{
- unsigned long flags;
- int mtype, mtype_low, mtype_high;
-
- if (!cc->page || *cc->page)
- return;
-
- /*
- * For MIGRATE_MOVABLE allocations we capture a suitable page ASAP
- * regardless of the migratetype of the freelist is is captured from.
- * This is fine because the order for a high-order MIGRATE_MOVABLE
- * allocation is typically at least a pageblock size and overall
- * fragmentation is not impaired. Other allocation types must
- * capture pages from their own migratelist because otherwise they
- * could pollute other pageblocks like MIGRATE_MOVABLE with
- * difficult to move pages and making fragmentation worse overall.
- */
- if (cc->migratetype == MIGRATE_MOVABLE) {
- mtype_low = 0;
- mtype_high = MIGRATE_PCPTYPES;
- } else {
- mtype_low = cc->migratetype;
- mtype_high = cc->migratetype + 1;
- }
-
- /* Speculatively examine the free lists without zone lock */
- for (mtype = mtype_low; mtype < mtype_high; mtype++) {
- int order;
- for (order = cc->order; order < MAX_ORDER; order++) {
- struct page *page;
- struct free_area *area;
- area = &(cc->zone->free_area[order]);
- if (list_empty(&area->free_list[mtype]))
- continue;
-
- /* Take the lock and attempt capture of the page */
- if (!compact_trylock_irqsave(&cc->zone->lock, &flags, cc))
- return;
- if (!list_empty(&area->free_list[mtype])) {
- page = list_entry(area->free_list[mtype].next,
- struct page, lru);
- if (capture_free_page(page, cc->order, mtype)) {
- spin_unlock_irqrestore(&cc->zone->lock,
- flags);
- *cc->page = page;
- return;
- }
- }
- spin_unlock_irqrestore(&cc->zone->lock, flags);
- }
- }
-}
-
static int compact_zone(struct zone *zone, struct compact_control *cc)
{
int ret;
@@ -1054,9 +994,6 @@ static int compact_zone(struct zone *zone, struct compact_control *cc)
goto out;
}
}
-
- /* Capture a page now if it is a suitable size */
- compact_capture_page(cc);
}
out:
@@ -1069,8 +1006,7 @@ out:
static unsigned long compact_zone_order(struct zone *zone,
int order, gfp_t gfp_mask,
- bool sync, bool *contended,
- struct page **page)
+ bool sync, bool *contended)
{
unsigned long ret;
struct compact_control cc = {
@@ -1080,7 +1016,6 @@ static unsigned long compact_zone_order(struct zone *zone,
.migratetype = allocflags_to_migratetype(gfp_mask),
.zone = zone,
.sync = sync,
- .page = page,
};
INIT_LIST_HEAD(&cc.freepages);
INIT_LIST_HEAD(&cc.migratepages);
@@ -1110,7 +1045,7 @@ int sysctl_extfrag_threshold = 500;
*/
unsigned long try_to_compact_pages(struct zonelist *zonelist,
int order, gfp_t gfp_mask, nodemask_t *nodemask,
- bool sync, bool *contended, struct page **page)
+ bool sync, bool *contended)
{
enum zone_type high_zoneidx = gfp_zone(gfp_mask);
int may_enter_fs = gfp_mask & __GFP_FS;
@@ -1136,7 +1071,7 @@ unsigned long try_to_compact_pages(struct zonelist *zonelist,
int status;
status = compact_zone_order(zone, order, gfp_mask, sync,
- contended, page);
+ contended);
rc = max(status, rc);
/* If a normal allocation would succeed, stop compacting */
@@ -1192,7 +1127,6 @@ int compact_pgdat(pg_data_t *pgdat, int order)
struct compact_control cc = {
.order = order,
.sync = false,
- .page = NULL,
};
return __compact_pgdat(pgdat, &cc);
@@ -1203,7 +1137,6 @@ static int compact_node(int nid)
struct compact_control cc = {
.order = -1,
.sync = true,
- .page = NULL,
};
return __compact_pgdat(NODE_DATA(nid), &cc);
diff --git a/mm/internal.h b/mm/internal.h
index d597f94..9ba2110 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -135,7 +135,6 @@ struct compact_control {
int migratetype; /* MOVABLE, RECLAIMABLE etc */
struct zone *zone;
bool contended; /* True if a lock was contended */
- struct page **page; /* Page captured of requested size */
};
unsigned long
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4ba5e37..ebf7fd8 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1389,22 +1389,14 @@ void split_page(struct page *page, unsigned int order)
set_page_refcounted(page + i);
}
-/*
- * Similar to the split_page family of functions except that the page
- * required at the given order and being isolated now to prevent races
- * with parallel allocators
- */
-int capture_free_page(struct page *page, int alloc_order, int migratetype)
+static int __isolate_free_page(struct page *page, unsigned int order)
{
- unsigned int order;
unsigned long watermark;
struct zone *zone;
int mt;
BUG_ON(!PageBuddy(page));
-
zone = page_zone(page);
- order = page_order(page);
mt = get_pageblock_migratetype(page);
if (mt != MIGRATE_ISOLATE) {
@@ -1413,7 +1405,7 @@ int capture_free_page(struct page *page, int alloc_order, int migratetype)
if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
return 0;
- __mod_zone_freepage_state(zone, -(1UL << alloc_order), mt);
+ __mod_zone_freepage_state(zone, -(1UL << order), mt);
}
/* Remove page from free list */
@@ -1421,11 +1413,7 @@ int capture_free_page(struct page *page, int alloc_order, int migratetype)
zone->free_area[order].nr_free--;
rmv_page_order(page);
- if (alloc_order != order)
- expand(zone, page, alloc_order, order,
- &zone->free_area[order], migratetype);
-
- /* Set the pageblock if the captured page is at least a pageblock */
+ /* Set the pageblock if the isolated page is at least a pageblock */
if (order >= pageblock_order - 1) {
struct page *endpage = page + (1 << order) - 1;
for (; page < endpage; page += pageblock_nr_pages) {
@@ -1436,7 +1424,7 @@ int capture_free_page(struct page *page, int alloc_order, int migratetype)
}
}
- return 1UL << alloc_order;
+ return 1UL << order;
}
/*
@@ -1451,13 +1439,12 @@ int capture_free_page(struct page *page, int alloc_order, int migratetype)
*/
int split_free_page(struct page *page)
{
- unsigned int order;
+ unsigned int order = page_order(page);
int nr_pages;
- BUG_ON(!PageBuddy(page));
order = page_order(page);
- nr_pages = capture_free_page(page, order, 0);
+ nr_pages = __isolate_free_page(page, order);
if (!nr_pages)
return 0;
@@ -2163,8 +2150,6 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
bool *contended_compaction, bool *deferred_compaction,
unsigned long *did_some_progress)
{
- struct page *page = NULL;
-
if (!order)
return NULL;
@@ -2176,16 +2161,12 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
current->flags |= PF_MEMALLOC;
*did_some_progress = try_to_compact_pages(zonelist, order, gfp_mask,
nodemask, sync_migration,
- contended_compaction, &page);
+ contended_compaction);
current->flags &= ~PF_MEMALLOC;
- /* If compaction captured a page, prep and use it */
- if (page) {
- prep_new_page(page, order, gfp_mask);
- goto got_page;
- }
-
if (*did_some_progress != COMPACT_SKIPPED) {
+ struct page *page;
+
/* Page migration frees to the PCP lists but we want merging */
drain_pages(get_cpu());
put_cpu();
@@ -2195,7 +2176,6 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
alloc_flags & ~ALLOC_NO_WATERMARKS,
preferred_zone, migratetype);
if (page) {
-got_page:
preferred_zone->compact_blockskip_flush = false;
preferred_zone->compact_considered = 0;
preferred_zone->compact_defer_shift = 0;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route
From: Romain KUNTZ @ 2013-01-09 14:36 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: YOSHIFUJI Hideaki, davem@davemloft.net, linux-kernel,
Andreas Hofmeister, Romain KUNTZ
>From e7ece201c35615c44a3cfdc10ee28ad5a5878f41 Mon Sep 17 00:00:00 2001
From: Romain Kuntz <r.kuntz@ipflavors.com>
Date: Wed, 9 Jan 2013 15:02:26 +0100
Subject: [PATCH 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route
The tests on the flags in addrconf_get_prefix_route() does no make
much sense: the 'noflags' parameter contains the set of flags that
must not match with the route flags, so the test must be done
against 'noflags', and not against 'flags'.
Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
---
net/ipv6/addrconf.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 408cac4a..29ba4ff 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1877,7 +1877,7 @@ static struct rt6_info *addrconf_get_prefix_route(const struct in6_addr *pfx,
continue;
if ((rt->rt6i_flags & flags) != flags)
continue;
- if ((noflags != 0) && ((rt->rt6i_flags & flags) != 0))
+ if ((rt->rt6i_flags & noflags) != 0)
continue;
dst_hold(&rt->dst);
break;
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH 1/2] ipv6: avoid blackhole and prohibited entries upon prefix purge [v3]
From: Romain KUNTZ @ 2013-01-09 14:37 UTC (permalink / raw)
To: nicolas.dichtel@6wind.com, YOSHIFUJI Hideaki
Cc: netdev@vger.kernel.org, Eric Dumazet, davem
In-Reply-To: <50EC54E3.9080606@linux-ipv6.org>
On Jan 8, 2013, at 18:18 , YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> wrote:
> Nicolas Dichtel wrote:
>> Le 08/01/2013 12:38, Romain KUNTZ a écrit :
>>> On Jan 7, 2013, at 16:43 , Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>>>> Le 07/01/2013 12:30, Romain KUNTZ a écrit :
>>>>> Hello Nicolas,
>>>>>
>>>>> On Jan 7, 2013, at 11:25 , Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>>>>>
>>>>>> Le 05/01/2013 22:44, Romain KUNTZ a écrit :
>>>>>>> Mobile IPv6 provokes a kernel Oops since commit 64c6d08e (ipv6:
>>>>>>> del unreachable route when an addr is deleted on lo), because
>>>>>>> ip6_route_lookup() may also return blackhole and prohibited
>>>>>>> entry. However, these entries have a NULL rt6i_table argument,
>>>>>>> which provokes an Oops in __ip6_del_rt() when trying to lock
>>>>>>> rt6i_table->tb6_lock.
>>>>>>>
>>>>>>> Beside, when purging a prefix, blakhole and prohibited entries
>>>>>>> should not be selected because they are not what we are looking
>>>>>>> for.
>>>>>>>
>>>>>>> We fix this by adding two new lookup flags (RT6_LOOKUP_F_NO_BLK_HOLE
>>>>>>> and RT6_LOOKUP_F_NO_PROHIBIT) in order to ensure that such entries
>>>>>>> are skipped during lookup and that the correct entry is returned.
>>>>>>>
>>>>>>> [v2]: use 'goto out;' instead of 'goto again;' to avoid unnecessary
>>>>>>> oprations on rt (as suggested by Eric Dumazet).
>>>>>>>
>>>>>>> Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
>>>>>>> ---
>>>>>>> include/net/ip6_route.h | 2 ++
>>>>>>> net/ipv6/addrconf.c | 4 +++-
>>>>>>> net/ipv6/fib6_rules.c | 4 ++++
>>>>>>> 3 files changed, 9 insertions(+), 1 deletions(-)
>>>>>>>
>>>>>>> diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
>>>>>>> index 27d8318..3c93743 100644
>>>>>>> --- a/include/net/ip6_route.h
>>>>>>> +++ b/include/net/ip6_route.h
>>>>>>> @@ -30,6 +30,8 @@ struct route_info {
>>>>>>> #define RT6_LOOKUP_F_SRCPREF_TMP 0x00000008
>>>>>>> #define RT6_LOOKUP_F_SRCPREF_PUBLIC 0x00000010
>>>>>>> #define RT6_LOOKUP_F_SRCPREF_COA 0x00000020
>>>>>>> +#define RT6_LOOKUP_F_NO_BLK_HOLE 0x00000040
>>>>>>> +#define RT6_LOOKUP_F_NO_PROHIBIT 0x00000080
>>>>>>>
>>>>>>> /*
>>>>>>> * rt6_srcprefs2flags() and rt6_flags2srcprefs() translate
>>>>>>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>>>>>>> index 408cac4a..1891e23 100644
>>>>>>> --- a/net/ipv6/addrconf.c
>>>>>>> +++ b/net/ipv6/addrconf.c
>>>>>>> @@ -948,7 +948,9 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
>>>>>>> fl6.flowi6_oif = ifp->idev->dev->ifindex;
>>>>>>> fl6.daddr = prefix;
>>>>>>> rt = (struct rt6_info *)ip6_route_lookup(net, &fl6,
>>>>>>> - RT6_LOOKUP_F_IFACE);
>>>>>>> + RT6_LOOKUP_F_IFACE |
>>>>>>> + RT6_LOOKUP_F_NO_BLK_HOLE |
>>>>>>> + RT6_LOOKUP_F_NO_PROHIBIT);
>>>>>>>
>>>>>>> if (rt != net->ipv6.ip6_null_entry &&
>>>>>> Is it not simpler to test the result here (net->ipv6.ip6_blk_hole_entry and
>>>>>> net->ipv6.ip6_prohibit_entry) like for the null_entry?
>>>>>> It will also avoid adding more flags.
>>>>>
>>>>> Your proposal would only solve part of the problem (the Oops in __ip6_del_rt()). Another problem here is that blackhole and prohibited rules should not be selected when trying to purge a prefix (correct me if I'm wrong) because they are not what we are looking for. This can prevent the targeted prefix from being purged.
>>>> In fact, I'm not sure to get the scenario. This part of the code just tries
>>>> to remove the connected prefix, added by the kernel when the address was added.
>>>> Can you describe your scenario?
>>>
>>>
>>> I should have given more details from the beginning, my mistake. The scenario where this happens is quite simple:
>>>
>>> - install a blackhole rule (e.g. "from 2001:db8::1000 blackhole" - the source address does not matter at all) with the FIB_RULE_FIND_SADDR flag set (setting this flag is not possible with iproute2, but for test purpose you can use the enclosed patch against the latest iproute2 tree and then use "./ip -6 rule add from 2001:db8::1000/128 blackhole prio 1000").
>>>
>>> - try to delete an address from one of your interface (any address, it can be different from the one you used for the blackhole rule): "ip -6 addr del <v6-addr>/64 dev eth<x>"
>>>
>>> and you get an Oops. When trying to remove the connected prefix, the fib6_rule_match() function will match the blackhole rule because RT6_LOOKUP_F_HAS_SADDR is not set and FIB_RULE_FIND_SADDR is set.
>>>
>>> With your proposal, the Oops is fixed but the connected prefix route is not deleted. With my initial patch, the Oops is fixed and the connected prefix route is also deleted.
>> Ok, I get it. I thin,there is two bugs: the oops and the wrong lookup.
>>
>> Your proposal fix only a particular case. Try this (with your ip route2 patch):
>> ip -6 addr add 2002::1/64 dev eth0
>> ip -6 route add 2002::/64 table 257 dev eth0
(you also need to add a rule such as this one:)
ip -6 rule to 2002::/64 table 257
>> ip -6 addr del 2002::1/64 dev eth0
>>
>> The route deleted is not the connected prefix, but the route added in table 257.
You are right.
>> The connected prefix is still here in the main table. It's not what we want.
>> Maybe the lookup should be done directly into the right table, ie table RT6_TABLE_PREFIX. What do you think?
>
> I agree. I think we can use addrconf_get_prefix_route() here.
Right, thanks for the hint! What about the below patch?
Note that addrconf_get_prefix_route() also requires a fix (I believe it does not handle the 'noflags' parameter correctly), I have sent a patch in a separate mail (subject "ipv6: fix the noflags test in addrconf_get_prefix_route").
Thanks,
Romain
From 2a79f191042ee8d48119b095b2ef7527a89817fc Mon Sep 17 00:00:00 2001
From: Romain Kuntz <r.kuntz@ipflavors.com>
Date: Wed, 9 Jan 2013 15:11:08 +0100
Subject: [PATCH 1/1] ipv6: use addrconf_get_prefix_route for prefix route lookup
Replace ip6_route_lookup() with addrconf_get_prefix_route() when
looking up for a prefix route. This ensures that the connected prefix
is looked up in the main table, and avoids the selection of other
matching route located in different tables.
As a consequence, the function addrconf_is_prefix_route() is not
used anymore and is removed.
Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
---
net/ipv6/addrconf.c | 24 ++++++++++--------------
1 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 29ba4ff..409dd47 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -154,6 +154,10 @@ static void addrconf_type_change(struct net_device *dev,
unsigned long event);
static int addrconf_ifdown(struct net_device *dev, int how);
+static struct rt6_info *addrconf_get_prefix_route(const struct in6_addr *pfx,
+ int plen, const struct net_device *dev,
+ u32 flags, u32 noflags);
+
static void addrconf_dad_start(struct inet6_ifaddr *ifp);
static void addrconf_dad_timer(unsigned long data);
static void addrconf_dad_completed(struct inet6_ifaddr *ifp);
@@ -250,12 +254,6 @@ static inline bool addrconf_qdisc_ok(const struct net_device *dev)
return !qdisc_tx_is_noop(dev);
}
-/* Check if a route is valid prefix route */
-static inline int addrconf_is_prefix_route(const struct rt6_info *rt)
-{
- return (rt->rt6i_flags & (RTF_GATEWAY | RTF_DEFAULT)) == 0;
-}
-
static void addrconf_del_timer(struct inet6_ifaddr *ifp)
{
if (del_timer(&ifp->timer))
@@ -941,17 +939,15 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
if ((ifp->flags & IFA_F_PERMANENT) && onlink < 1) {
struct in6_addr prefix;
struct rt6_info *rt;
- struct net *net = dev_net(ifp->idev->dev);
- struct flowi6 fl6 = {};
ipv6_addr_prefix(&prefix, &ifp->addr, ifp->prefix_len);
- fl6.flowi6_oif = ifp->idev->dev->ifindex;
- fl6.daddr = prefix;
- rt = (struct rt6_info *)ip6_route_lookup(net, &fl6,
- RT6_LOOKUP_F_IFACE);
- if (rt != net->ipv6.ip6_null_entry &&
- addrconf_is_prefix_route(rt)) {
+ rt = addrconf_get_prefix_route(&prefix,
+ ifp->prefix_len,
+ ifp->idev->dev,
+ 0, RTF_GATEWAY | RTF_DEFAULT);
+
+ if (rt) {
if (onlink == 0) {
ip6_del_rt(rt);
rt = NULL;
--
1.7.2.5
^ permalink raw reply related
* RE: tainted warnings with tcp splicing in 3.7.1
From: Lukas Tribus @ 2013-01-09 14:50 UTC (permalink / raw)
To: netdev
In-Reply-To: <F476A81A60AA6B458C3DA58B993EA70A1B8F394A@MUCR10053060111.muc.traviangames.lan>
For the record:
Another user reported similar warnings in a 3.5.0 kernel back in September [1] on the haproxy mailing list with the following kernel warnings:
[142654.793193] ------------[ cut here ]------------
[142654.793395] WARNING: at net/ipv4/tcp.c:1301 tcp_cleanup_rbuf+0x54/0x150()
[142654.793972] Hardware name: System Product Name
[142654.794573] cleanup rbuf bug: copied 68D1EF11 seq 68CFF65F rcvnxt 68D3565D
[142654.795165] Modules linked in: ixgbe(O) binfmt_misc 8021q fcoe
garp stp llc libfcoe libfc scsi_transport_fc scsi_tgt ip6t_REJECT nf
_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter
ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel
snd_hda_codec nouveau snd_hwdep igb snd_seq snd_seq_device snd_pcm
eeepc_wmi asus_wmi ttm drm_kms_helper sparse_keymap snd_timer snd drm
coretemp rfkill i2c_algo_bit mxm_wmi wmi video lpc_ich mfd_core
crc32c_intel r8169 i2c_i801 i2c_core soundcore snd_page_alloc mii mdio
pcspkr serio_raw ghash_clmulni_intel microcode uinput [last unloaded:
ixgbe]
[142654.798215] Pid: 18374, comm: haproxy Tainted: G W O 3.5.0 #1
[142654.798838] Call Trace:
[142654.799440] [<ffffffff810422cf>] warn_slowpath_common+0x7f/0xc0
[142654.800031] [<ffffffff810423c6>] warn_slowpath_fmt+0x46/0x50
[142654.800653] [<ffffffff8147c270>] ? sock_pipe_buf_release+0x20/0x20
[142654.801237] [<ffffffff814cf294>] tcp_cleanup_rbuf+0x54/0x150
[142654.801847] [<ffffffff814d0ae1>] tcp_read_sock+0x1b1/0x200
[142654.802440] [<ffffffff81472777>] ? sock_sendpage+0x27/0x30
[142654.803037] [<ffffffff814ccd60>] ? tcp_done+0x90/0x90
[142654.803644] [<ffffffff814d0bf0>] tcp_splice_read+0xc0/0x250
[142654.804239] [<ffffffff814726b2>] sock_splice_read+0x62/0x80
[142654.804843] [<ffffffff8118c73b>] do_splice_to+0x7b/0xa0
[142654.805457] [<ffffffff8118e850>] sys_splice+0x540/0x560
[142654.806040] [<ffffffff8159aed2>] system_call_fastpath+0x16/0x1b
[142654.806646] ---[ end trace 46d7fb693af33fde ]---
[1] http://permalink.gmane.org/gmane.comp.web.haproxy/9559 -
^ permalink raw reply
* Re: xen-netback notify DomU to send ARP.
From: Jason Luan @ 2013-01-09 15:07 UTC (permalink / raw)
To: Ian Campbell; +Cc: netdev, xen-devel, JBeulich, konrad.wilk
[-- Attachment #1.1: Type: text/plain, Size: 2907 bytes --]
于 2013年01月09日 20:03, Ian Campbell 写道:
> On Wed, 2013-01-09 at 01:07 +0000, Jason Luan wrote:
>> 于 2013年01月09日 00:00, Ian Campbell 写道:
>>> On Tue, 2013-01-08 at 15:40 +0000, jianhai luan wrote:
>>>> On 2013-1-8 21:42, Ian Campbell wrote:
>>>>> On Tue, 2013-01-08 at 13:13 +0000, Jan Beulich wrote:
>>>>>>>>> On 08.01.13 at 12:57, jianhai luan <jianhai.luan@oracle.com>
>>>>>>>>> wrote:
>>>>>>> When Xen Dom0's network circumstance changed, DomU
>>>>>>> should be notified in some special condition. For
>>>>>>> example the below circumstance:
>>>>>>> ping from Guest A to DomU:
>>>>>>> Guest A --> eth0 - bond0 - xenbr0 --VIF(DOMU)
>>>>>>> eth1 /
>>>>>>> when eth0 inactive, and eth1 active.
>>>>> How is eth0 failing? Are you unplugging it, un-enslaving it or
>>>>> taking
>>>>> some other sort of administrative action?
>>>> In my emulation environment, i unplug it or ifdown the interface,
>>> I expect these would behave rather different, since the affect of
>>> ifdown
>>> looks rather different to an unplug from the PoV of the switch.
>>>
>>> Is the ifdown case something which you are trying to solve or just what
>>> appeared to be a convenient test case? I'd be less inclined to worry
>>> about explict admin actions such as that.
>>>
>>> Unplugging the cable should cause:
>>>
>> I do above listed thing to let switch active slave only.
>> I think that we should put attention on the thing which bond switch
>> active slave interface in active-backup mode. In network circumstance,
>> many thing will cause the switch, what do Vif when the event happen?
> Sorry, I'm having a bit of trouble parsing the above, but are you asking
> what the VIF should do when the active slave in the bond changes without
> the previously active slave actually failing?
sorry for your misunderstanding.
>
> The issue is that traffic will continue to arrive on the now inactive
> slave, but will be discarded (the expected behaviour for
> Active/Passive)?
Yes. the traffic will continue to arrive on the switcher's port which
connected the inactive
slave before, and the switcher's port don't connect (or don't reach) the
inactive slave now,
so the link will be disconnected before DomU send ARP. After DomU send
ARP, the traffic will
know how to reach the correct switcher's port which connected with the
active slave.
>
> Is this something which happens in practice? Does the active slave
> change even while it remains a viable path?
Yes, please think the below the scene.
PC -- switcher
port A -- eth0 --bond0 --xenbr0 -DomU
port B -- eth1/
or
PC -- switcher A -- eth0 -- bond0 -- xenbr0 -- DomU
\- switcher B -- eth1 /
If Port A or switcher A wrong, the traffic from PC to DomU will be
disconnected before found
correct path (port B or Switcher B ).
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 6594 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH 1/2] ipv6: avoid blackhole and prohibited entries upon prefix purge [v3]
From: Nicolas Dichtel @ 2013-01-09 15:11 UTC (permalink / raw)
To: Romain KUNTZ
Cc: YOSHIFUJI Hideaki, netdev@vger.kernel.org, Eric Dumazet, davem
In-Reply-To: <6A08EDC1-08A0-411D-90CF-6DB1CB7FA3A0@ipflavors.com>
Le 09/01/2013 15:37, Romain KUNTZ a écrit :
> On Jan 8, 2013, at 18:18 , YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> wrote:
>> Nicolas Dichtel wrote:
>>> Le 08/01/2013 12:38, Romain KUNTZ a écrit :
>>>> On Jan 7, 2013, at 16:43 , Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>>>>> Le 07/01/2013 12:30, Romain KUNTZ a écrit :
>>>>>> Hello Nicolas,
>>>>>>
>>>>>> On Jan 7, 2013, at 11:25 , Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>>>>>>
>>>>>>> Le 05/01/2013 22:44, Romain KUNTZ a écrit :
>>>>>>>> Mobile IPv6 provokes a kernel Oops since commit 64c6d08e (ipv6:
>>>>>>>> del unreachable route when an addr is deleted on lo), because
>>>>>>>> ip6_route_lookup() may also return blackhole and prohibited
>>>>>>>> entry. However, these entries have a NULL rt6i_table argument,
>>>>>>>> which provokes an Oops in __ip6_del_rt() when trying to lock
>>>>>>>> rt6i_table->tb6_lock.
>>>>>>>>
>>>>>>>> Beside, when purging a prefix, blakhole and prohibited entries
>>>>>>>> should not be selected because they are not what we are looking
>>>>>>>> for.
>>>>>>>>
>>>>>>>> We fix this by adding two new lookup flags (RT6_LOOKUP_F_NO_BLK_HOLE
>>>>>>>> and RT6_LOOKUP_F_NO_PROHIBIT) in order to ensure that such entries
>>>>>>>> are skipped during lookup and that the correct entry is returned.
>>>>>>>>
>>>>>>>> [v2]: use 'goto out;' instead of 'goto again;' to avoid unnecessary
>>>>>>>> oprations on rt (as suggested by Eric Dumazet).
>>>>>>>>
>>>>>>>> Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
>>>>>>>> ---
>>>>>>>> include/net/ip6_route.h | 2 ++
>>>>>>>> net/ipv6/addrconf.c | 4 +++-
>>>>>>>> net/ipv6/fib6_rules.c | 4 ++++
>>>>>>>> 3 files changed, 9 insertions(+), 1 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
>>>>>>>> index 27d8318..3c93743 100644
>>>>>>>> --- a/include/net/ip6_route.h
>>>>>>>> +++ b/include/net/ip6_route.h
>>>>>>>> @@ -30,6 +30,8 @@ struct route_info {
>>>>>>>> #define RT6_LOOKUP_F_SRCPREF_TMP 0x00000008
>>>>>>>> #define RT6_LOOKUP_F_SRCPREF_PUBLIC 0x00000010
>>>>>>>> #define RT6_LOOKUP_F_SRCPREF_COA 0x00000020
>>>>>>>> +#define RT6_LOOKUP_F_NO_BLK_HOLE 0x00000040
>>>>>>>> +#define RT6_LOOKUP_F_NO_PROHIBIT 0x00000080
>>>>>>>>
>>>>>>>> /*
>>>>>>>> * rt6_srcprefs2flags() and rt6_flags2srcprefs() translate
>>>>>>>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>>>>>>>> index 408cac4a..1891e23 100644
>>>>>>>> --- a/net/ipv6/addrconf.c
>>>>>>>> +++ b/net/ipv6/addrconf.c
>>>>>>>> @@ -948,7 +948,9 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
>>>>>>>> fl6.flowi6_oif = ifp->idev->dev->ifindex;
>>>>>>>> fl6.daddr = prefix;
>>>>>>>> rt = (struct rt6_info *)ip6_route_lookup(net, &fl6,
>>>>>>>> - RT6_LOOKUP_F_IFACE);
>>>>>>>> + RT6_LOOKUP_F_IFACE |
>>>>>>>> + RT6_LOOKUP_F_NO_BLK_HOLE |
>>>>>>>> + RT6_LOOKUP_F_NO_PROHIBIT);
>>>>>>>>
>>>>>>>> if (rt != net->ipv6.ip6_null_entry &&
>>>>>>> Is it not simpler to test the result here (net->ipv6.ip6_blk_hole_entry and
>>>>>>> net->ipv6.ip6_prohibit_entry) like for the null_entry?
>>>>>>> It will also avoid adding more flags.
>>>>>>
>>>>>> Your proposal would only solve part of the problem (the Oops in __ip6_del_rt()). Another problem here is that blackhole and prohibited rules should not be selected when trying to purge a prefix (correct me if I'm wrong) because they are not what we are looking for. This can prevent the targeted prefix from being purged.
>>>>> In fact, I'm not sure to get the scenario. This part of the code just tries
>>>>> to remove the connected prefix, added by the kernel when the address was added.
>>>>> Can you describe your scenario?
>>>>
>>>>
>>>> I should have given more details from the beginning, my mistake. The scenario where this happens is quite simple:
>>>>
>>>> - install a blackhole rule (e.g. "from 2001:db8::1000 blackhole" - the source address does not matter at all) with the FIB_RULE_FIND_SADDR flag set (setting this flag is not possible with iproute2, but for test purpose you can use the enclosed patch against the latest iproute2 tree and then use "./ip -6 rule add from 2001:db8::1000/128 blackhole prio 1000").
>>>>
>>>> - try to delete an address from one of your interface (any address, it can be different from the one you used for the blackhole rule): "ip -6 addr del <v6-addr>/64 dev eth<x>"
>>>>
>>>> and you get an Oops. When trying to remove the connected prefix, the fib6_rule_match() function will match the blackhole rule because RT6_LOOKUP_F_HAS_SADDR is not set and FIB_RULE_FIND_SADDR is set.
>>>>
>>>> With your proposal, the Oops is fixed but the connected prefix route is not deleted. With my initial patch, the Oops is fixed and the connected prefix route is also deleted.
>>> Ok, I get it. I thin,there is two bugs: the oops and the wrong lookup.
>>>
>>> Your proposal fix only a particular case. Try this (with your ip route2 patch):
>>> ip -6 addr add 2002::1/64 dev eth0
>>> ip -6 route add 2002::/64 table 257 dev eth0
>
> (you also need to add a rule such as this one:)
> ip -6 rule to 2002::/64 table 257
>
>>> ip -6 addr del 2002::1/64 dev eth0
>>>
>>> The route deleted is not the connected prefix, but the route added in table 257.
>
> You are right.
>
>>> The connected prefix is still here in the main table. It's not what we want.
>>> Maybe the lookup should be done directly into the right table, ie table RT6_TABLE_PREFIX. What do you think?
>>
>> I agree. I think we can use addrconf_get_prefix_route() here.
>
> Right, thanks for the hint! What about the below patch?
>
> Note that addrconf_get_prefix_route() also requires a fix (I believe it does not handle the 'noflags' parameter correctly), I have sent a patch in a separate mail (subject "ipv6: fix the noflags test in addrconf_get_prefix_route").
>
> Thanks,
> Romain
>
>
>
> From 2a79f191042ee8d48119b095b2ef7527a89817fc Mon Sep 17 00:00:00 2001
> From: Romain Kuntz <r.kuntz@ipflavors.com>
> Date: Wed, 9 Jan 2013 15:11:08 +0100
> Subject: [PATCH 1/1] ipv6: use addrconf_get_prefix_route for prefix route lookup
>
> Replace ip6_route_lookup() with addrconf_get_prefix_route() when
> looking up for a prefix route. This ensures that the connected prefix
> is looked up in the main table, and avoids the selection of other
> matching route located in different tables.
>
> As a consequence, the function addrconf_is_prefix_route() is not
> used anymore and is removed.
Because this patch also fix an oops, I think it's interesting to tell it in the
commit log and point the commit that introduce this oops.
>
> Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
> ---
> net/ipv6/addrconf.c | 24 ++++++++++--------------
> 1 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 29ba4ff..409dd47 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -154,6 +154,10 @@ static void addrconf_type_change(struct net_device *dev,
> unsigned long event);
> static int addrconf_ifdown(struct net_device *dev, int how);
>
> +static struct rt6_info *addrconf_get_prefix_route(const struct in6_addr *pfx,
> + int plen, const struct net_device *dev,
> + u32 flags, u32 noflags);
These args should be aligned to the previous '('.
> +
> static void addrconf_dad_start(struct inet6_ifaddr *ifp);
> static void addrconf_dad_timer(unsigned long data);
> static void addrconf_dad_completed(struct inet6_ifaddr *ifp);
> @@ -250,12 +254,6 @@ static inline bool addrconf_qdisc_ok(const struct net_device *dev)
> return !qdisc_tx_is_noop(dev);
> }
>
> -/* Check if a route is valid prefix route */
> -static inline int addrconf_is_prefix_route(const struct rt6_info *rt)
> -{
> - return (rt->rt6i_flags & (RTF_GATEWAY | RTF_DEFAULT)) == 0;
> -}
> -
> static void addrconf_del_timer(struct inet6_ifaddr *ifp)
> {
> if (del_timer(&ifp->timer))
> @@ -941,17 +939,15 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
> if ((ifp->flags & IFA_F_PERMANENT) && onlink < 1) {
> struct in6_addr prefix;
> struct rt6_info *rt;
> - struct net *net = dev_net(ifp->idev->dev);
> - struct flowi6 fl6 = {};
>
> ipv6_addr_prefix(&prefix, &ifp->addr, ifp->prefix_len);
> - fl6.flowi6_oif = ifp->idev->dev->ifindex;
> - fl6.daddr = prefix;
> - rt = (struct rt6_info *)ip6_route_lookup(net, &fl6,
> - RT6_LOOKUP_F_IFACE);
>
> - if (rt != net->ipv6.ip6_null_entry &&
> - addrconf_is_prefix_route(rt)) {
> + rt = addrconf_get_prefix_route(&prefix,
> + ifp->prefix_len,
> + ifp->idev->dev,
> + 0, RTF_GATEWAY | RTF_DEFAULT);
Same here.
> +
> + if (rt) {
> if (onlink == 0) {
> ip6_del_rt(rt);
> rt = NULL;
>
After, you can add my "Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>" ;-)
^ permalink raw reply
* [PATCH net-next] ipv6: Use FIELD_SIZEOF() instead of dummy variable.
From: YOSHIFUJI Hideaki @ 2013-01-09 15:31 UTC (permalink / raw)
To: David Miller, netdev; +Cc: YOSHIFUJI Hideaki
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
net/ipv6/af_inet6.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index b043c60..6b793bf 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -811,11 +811,10 @@ static struct pernet_operations inet6_net_ops = {
static int __init inet6_init(void)
{
- struct sk_buff *dummy_skb;
struct list_head *r;
int err = 0;
- BUILD_BUG_ON(sizeof(struct inet6_skb_parm) > sizeof(dummy_skb->cb));
+ BUILD_BUG_ON(sizeof(struct inet6_skb_parm) > FIELD_SIZEOF(struct sk_buff, cb));
/* Register the socket-side information for inet6_create. */
for (r = &inetsw6[0]; r < &inetsw6[SOCK_MAX]; ++r)
--
1.7.9.5
^ permalink raw reply related
* Re: xen-netback notify DomU to send ARP.
From: Jason Luan @ 2013-01-09 15:37 UTC (permalink / raw)
To: Jan Beulich; +Cc: netdev, xen-devel, Ian Campbell, konrad.wilk
In-Reply-To: <50ED825802000078000B4113@nat28.tlf.novell.com>
于 2013年01月09日 21:44, Jan Beulich 写道:
>>>> On 09.01.13 at 13:28, jianhai luan <jianhai.luan@oracle.com> wrote:
>>>> + switch (event) {
>>>> + case NETDEV_NOTIFY_PEERS:
>>>> + /* Notify frontend to Send gratuitous ARP */
>>>> + xenbus_switch_state(be->dev, XenbusStateInitialised);
>>>> + xenbus_switch_state(be->dev, );
>>> This is the sort of change that clearly isn't acceptable, as I don't
>>> think you have ways to check _all_ existing frontends for their
>>> compatibility with this. A connected -> connected transition
>>> might be acceptable (that was done in the block frontend too, for
>>> implementing dynamic resize), but will likely need to be
>>> accompanied by a frontend side patch to handle that (which so
>>> far should be a no-op).
>> The latest xen net-frontent driver have handled the condition. State
>> XenbusStateInitialised will do nothing,
>> but change to XenbusStateConnected will trigger
>> netdev_notify_peers(netdev) to send ARP.
> Did you read my earlier reply carefully? You still only talk about
> (upstream) Linux netfront, but this is not the only (possible)
> frontend. You should not invoke state transitions that can -
> even if only theoretically - blow up frontends. And afaict the
I only want to notify xen-netfront. I don't know what is better way?
To attainthegoal, i try to modify virtual interrupt, but the way is
morecomplicated,modified and working. So, i give up the way.
Would you like to give some suggestion about how to notify xen-netfront?
> only thing you can safely assume frontends ought to tolerate
> are transitions from Connected to Connected (or more
> generally from one state to the same one, but the other
> states aren't useful here, except maybe the Reconfigur* ones).
Sorry for that. At the beginning the patch be applied in kernel 2.6.18 to
fixed one issue. Only XenbusStateInitialised and XenbusStateClosed ( Not
Reconfigure* one) don't any thing, so i choose the XenbusStateInitialised.
Do you suggestion that i choose Reconfigure*?
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [Xen-devel] xen-netback notify DomU to send ARP.
From: Jan Beulich @ 2013-01-09 15:44 UTC (permalink / raw)
To: Jason Luan; +Cc: Ian Campbell, xen-devel, konrad.wilk, netdev
In-Reply-To: <50ED8ED3.8010007@163.com>
>>> On 09.01.13 at 16:37, Jason Luan <luanjianhai@163.com> wrote:
> 于 2013年01月09日 21:44, Jan Beulich 写道:
>>>>> On 09.01.13 at 13:28, jianhai luan <jianhai.luan@oracle.com> wrote:
>>>>> + switch (event) {
>>>>> + case NETDEV_NOTIFY_PEERS:
>>>>> + /* Notify frontend to Send gratuitous ARP */
>>>>> + xenbus_switch_state(be->dev, XenbusStateInitialised);
>>>>> + xenbus_switch_state(be->dev, );
>>>> This is the sort of change that clearly isn't acceptable, as I don't
>>>> think you have ways to check _all_ existing frontends for their
>>>> compatibility with this. A connected -> connected transition
>>>> might be acceptable (that was done in the block frontend too, for
>>>> implementing dynamic resize), but will likely need to be
>>>> accompanied by a frontend side patch to handle that (which so
>>>> far should be a no-op).
>>> The latest xen net-frontent driver have handled the condition. State
>>> XenbusStateInitialised will do nothing,
>>> but change to XenbusStateConnected will trigger
>>> netdev_notify_peers(netdev) to send ARP.
>> Did you read my earlier reply carefully? You still only talk about
>> (upstream) Linux netfront, but this is not the only (possible)
>> frontend. You should not invoke state transitions that can -
>> even if only theoretically - blow up frontends. And afaict the
> I only want to notify xen-netfront. I don't know what is better way?
> To attainthegoal, i try to modify virtual interrupt, but the way is
> morecomplicated,modified and working. So, i give up the way.
> Would you like to give some suggestion about how to notify xen-netfront?
>> only thing you can safely assume frontends ought to tolerate
>> are transitions from Connected to Connected (or more
>> generally from one state to the same one, but the other
>> states aren't useful here, except maybe the Reconfigur* ones).
> Sorry for that. At the beginning the patch be applied in kernel 2.6.18 to
> fixed one issue. Only XenbusStateInitialised and XenbusStateClosed ( Not
> Reconfigure* one) don't any thing, so i choose the XenbusStateInitialised.
> Do you suggestion that i choose Reconfigure*?
I already said that I think that only a Connected->Connected
transition is to be considered here. Bringing up Reconfigur* was
just to point out that there are other states available that could
be used, but you'd first need to make sure that (a) they aren't
used for anything else and (b) frontends can reasonably be
expected to deal with (ignore) them when not originally aware
of them (as opposed to a Connected->Connected transition,
which all frontends ought to be able to deal with afaict).
Also, when you reply to earlier mails, could you - in order to make
the result readable - insert blank lines between the quoted text
and your responses, please?
Jan
^ permalink raw reply
* Re: [PATCH] ipv6: Netlink notify forwarding change
From: Nicolas Dichtel @ 2013-01-09 16:27 UTC (permalink / raw)
To: Saurabh Mohan; +Cc: netdev
In-Reply-To: <20130109001114.GA3393@debian-saurabh-64.vyatta.com>
Le 09/01/2013 01:11, Saurabh Mohan a écrit :
>
>
> If the interface is up and the forwarding attribute
> (net.ipv6.conf.eth1.forwarding) is changed then a netlink message is not
> generated.
>
A rtnetlink message RTM_NEWNETCONF is sent (see inet6_netconf_notify_devconf()).
^ permalink raw reply
* Re: [PATCH 4/4 v3] net/smsc911x: Provide common clock functionality
From: Ulf Hansson @ 2013-01-09 16:32 UTC (permalink / raw)
To: Lee Jones
Cc: Linus Walleij, Russell King - ARM Linux, Steve Glendinning,
Robert Marklund, linus.walleij, arnd, netdev, linux-kernel,
linux-arm-kernel
In-Reply-To: <20130109085555.GA31678@gmail.com>
On 9 January 2013 09:55, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 03 Jan 2013, Linus Walleij wrote:
>
>> On Thu, Jan 3, 2013 at 12:14 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> > Some platforms provide clocks which require enabling before the
>> > SMSC911x chip will power on. This patch uses the new common clk
>> > framework to do just that. If no clock is provided, it will just
>> > be ignored and the driver will continue to assume that no clock
>> > is required for the chip to run successfully.
>> >
>> > Cc: Steve Glendinning <steve.glendinning@shawell.net>
>> > Cc: netdev@vger.kernel.org
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>>
>> Looks all right to me now:
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> I still need a maintiner Ack for this before I can push it.
>
> Anyone?
>
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
^ permalink raw reply
* Re: [PATCH net-next] ipv6: Use FIELD_SIZEOF() instead of dummy variable.
From: YOSHIFUJI Hideaki @ 2013-01-09 16:56 UTC (permalink / raw)
To: David Miller, netdev; +Cc: YOSHIFUJI Hideaki
In-Reply-To: <50ED8D35.8070506@linux-ipv6.org>
YOSHIFUJI Hideaki wrote:
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> ---
> net/ipv6/af_inet6.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
> index b043c60..6b793bf 100644
> --- a/net/ipv6/af_inet6.c
> +++ b/net/ipv6/af_inet6.c
> @@ -811,11 +811,10 @@ static struct pernet_operations inet6_net_ops = {
>
> static int __init inet6_init(void)
> {
> - struct sk_buff *dummy_skb;
> struct list_head *r;
> int err = 0;
>
> - BUILD_BUG_ON(sizeof(struct inet6_skb_parm) > sizeof(dummy_skb->cb));
> + BUILD_BUG_ON(sizeof(struct inet6_skb_parm) > FIELD_SIZEOF(struct sk_buff, cb));
>
> /* Register the socket-side information for inet6_create. */
> for (r = &inetsw6[0]; r < &inetsw6[SOCK_MAX]; ++r)
>
I'm resending this one with others.
--yoshfuji
^ permalink raw reply
* Re: tainted warnings with tcp splicing in 3.7.1
From: Eric Dumazet @ 2013-01-09 17:01 UTC (permalink / raw)
To: Christian Becker; +Cc: netdev@vger.kernel.org
In-Reply-To: <F476A81A60AA6B458C3DA58B993EA70A1B8F394A@MUCR10053060111.muc.traviangames.lan>
On Wed, 2013-01-09 at 13:01 +0000, Christian Becker wrote:
> Hi,
>
> we´ve installed 3.7.1 yesterday on one of our loadbalancer nodes in order to get TFO.
>
> Unfortunately the kernel started to print warnings every couple of minutes when using tcp splicing in haproxy.
>
> We´ve built the kernel yesterday from the 3.7.1 sources without any modifications.
>
> The System contains two Intel Xeon X6550, 64 GB RAM and there are two kinds of NICs:
>
> Broadcom Corporation NetXtreme II BCM5709 (Driver bnx2)
> Emulex Corporation OneConnect 10Gb NIC (Driver be2net)
>
> The bnx2 adapters are not in use and disconnected and the be2net handle about 1 GBit/s of traffic.
>
> We´ve downgraded again to our old kernel version, but i guess you should take a look at this.
>
> There are two kinds of messages:
>
> an 9 11:34:28 srv11 kernel: [ 1081.334970] ------------[ cut here ]------------
> Jan 9 11:34:28 srv11 kernel: [ 1081.353685] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:34:28 srv11 kernel: [ 1081.371956] Hardware name: System x3690 X5 -[7148Z68]-
> Jan 9 11:34:28 srv11 kernel: [ 1081.391820] cleanup rbuf bug: copied AD3BCF1 seq AD370AF rcvnxt AD3CF13
> Jan 9 11:34:28 srv11 kernel: [ 1081.408971] Modules linked in: 8021q garp stp llc nls_utf8 nls_cp437 vfat fat kvm_intel coretemp kvm joydev acpi_cpufreq mperf crc32c_intel hid_generic shpchp snd_pcm snd_timer snd lpc_ich mfd_core cdc_ether usb
> net mii evdev serio_raw ioatdma processor i2c_i801 tpm_tis dca soundcore snd_page_alloc pcspkr tpm microcode i2c_core tpm_bios thermal_sys button pci_hotplug ext4 mbcache jbd2 crc16 dm_mod sg sr_mod cdrom sd_mod crc_t10dif usbhid ata_generic hi
> d uhci_hcd ata_piix libata megaraid_sas bnx2 ehci_hcd usbcore scsi_mod usb_common be2net
> Jan 9 11:34:28 srv11 kernel: [ 1081.532314] Pid: 13763, comm: haproxy Not tainted 3.7.1 #1
> Jan 9 11:34:28 srv11 kernel: [ 1081.554349] Call Trace:
> Jan 9 11:34:28 srv11 kernel: [ 1081.573762] [<ffffffff8103ef70>] ? warn_slowpath_common+0x78/0x8c
> Jan 9 11:34:28 srv11 kernel: [ 1081.596750] [<ffffffff8103f023>] ? warn_slowpath_fmt+0x45/0x4a
> Jan 9 11:34:28 srv11 kernel: [ 1081.617853] [<ffffffff81297d06>] ? sock_pipe_buf_release+0xe/0xe
> Jan 9 11:34:28 srv11 kernel: [ 1081.639111] [<ffffffff812d37c2>] ? tcp_cleanup_rbuf+0x4d/0xfc
> Jan 9 11:34:28 srv11 kernel: [ 1081.661541] [<ffffffff812d39f4>] ? tcp_read_sock+0x183/0x194
> Jan 9 11:34:28 srv11 kernel: [ 1081.681164] [<ffffffff812d423d>] ? tcp_sendpage+0x45b/0x45b
> Jan 9 11:34:28 srv11 kernel: [ 1081.703355] [<ffffffff812d3ad8>] ? tcp_splice_read+0xd3/0x223
> Jan 9 11:34:28 srv11 kernel: [ 1081.724912] [<ffffffff8112d9b9>] ? sys_splice+0x345/0x3c0
> Jan 9 11:34:28 srv11 kernel: [ 1081.744525] [<ffffffff81364b69>] ? system_call_fastpath+0x16/0x1b
> Jan 9 11:34:28 srv11 kernel: [ 1081.766683] ---[ end trace fb4ffd749d51e56f ]---
>
> Jan 9 11:52:42 srv11 kernel: [ 2174.882971] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:42 srv11 kernel: [ 2174.901182] Hardware name: System x3690 X5 -[7148Z68]-
> Jan 9 11:52:42 srv11 kernel: [ 2174.921229] recvmsg bug 2: copied 4B9C4CE6 seq 4B9BE950 rcvnxt 4B9C4CE6 fl 0
> Jan 9 11:52:42 srv11 kernel: [ 2174.941681] Modules linked in: 8021q garp stp llc nls_utf8 nls_cp437 vfat fat kvm_intel coretemp kvm joydev acpi_cpufreq mperf crc32c_intel hid_generic shpchp snd_pcm snd_timer snd lpc_ich mfd_core cdc_ether usb
> net mii evdev serio_raw ioatdma processor i2c_i801 tpm_tis dca soundcore snd_page_alloc pcspkr tpm microcode i2c_core tpm_bios thermal_sys button pci_hotplug ext4 mbcache jbd2 crc16 dm_mod sg sr_mod cdrom sd_mod crc_t10dif usbhid ata_generic hi
> d uhci_hcd ata_piix libata megaraid_sas bnx2 ehci_hcd usbcore scsi_mod usb_common be2net
> Jan 9 11:52:42 srv11 kernel: [ 2175.075389] Pid: 13250, comm: haproxy Tainted: G W 3.7.1 #1
> Jan 9 11:52:42 srv11 kernel: [ 2175.099391] Call Trace:
> Jan 9 11:52:42 srv11 kernel: [ 2175.122727] [<ffffffff8103ef70>] ? warn_slowpath_common+0x78/0x8c
> Jan 9 11:52:42 srv11 kernel: [ 2175.147250] [<ffffffff8103f023>] ? warn_slowpath_fmt+0x45/0x4a
> Jan 9 11:52:42 srv11 kernel: [ 2175.170289] [<ffffffff81295f64>] ? release_sock+0xe6/0x11c
> Jan 9 11:52:43 srv11 kernel: [ 2175.192639] [<ffffffff812d45d2>] ? tcp_recvmsg+0x2ca/0x9de
> Jan 9 11:52:43 srv11 kernel: [ 2175.215020] [<ffffffff812e0b71>] ? tcp_write_xmit+0x849/0x946
> Jan 9 11:52:43 srv11 kernel: [ 2175.237682] [<ffffffff812f2720>] ? inet_recvmsg+0x64/0x75
> Jan 9 11:52:43 srv11 kernel: [ 2175.259727] [<ffffffff8129052d>] ? sock_recvmsg+0x56/0x6e
> Jan 9 11:52:43 srv11 kernel: [ 2175.281111] [<ffffffff8128fedf>] ? sockfd_lookup_light+0x1a/0x50
> Jan 9 11:52:43 srv11 kernel: [ 2175.300573] [<ffffffff812923f4>] ? sys_recvfrom+0xbf/0x120
> Jan 9 11:52:43 srv11 kernel: [ 2175.320073] [<ffffffff8135d9f7>] ? __schedule+0x4c9/0x4f6
> Jan 9 11:52:43 srv11 kernel: [ 2175.341151] [<ffffffff81364b69>] ? system_call_fastpath+0x16/0x1b
> Jan 9 11:52:43 srv11 kernel: [ 2175.360859] ---[ end trace fb4ffd749d51e5a7 ]---
>
> As you can see here, the messages are appearing every couple of minutes:
>
> Jan 9 11:34:28 srv11 kernel: [ 1081.353685] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:34:29 srv11 kernel: [ 1081.809446] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:34:29 srv11 kernel: [ 1082.235052] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:34:29 srv11 kernel: [ 1082.692732] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:34:30 srv11 kernel: [ 1083.177807] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:34:30 srv11 kernel: [ 1083.698475] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:34:31 srv11 kernel: [ 1084.221899] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:34:31 srv11 kernel: [ 1084.746992] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:34:32 srv11 kernel: [ 1085.267199] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:37:16 srv11 kernel: [ 1249.252200] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:37:17 srv11 kernel: [ 1249.782915] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:37:17 srv11 kernel: [ 1250.315653] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:37:18 srv11 kernel: [ 1250.867306] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:37:18 srv11 kernel: [ 1251.383968] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:37:19 srv11 kernel: [ 1251.897631] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:37:19 srv11 kernel: [ 1252.412535] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:37:20 srv11 kernel: [ 1252.921313] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:40:13 srv11 kernel: [ 1425.644620] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:40:13 srv11 kernel: [ 1426.314292] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:40:14 srv11 kernel: [ 1426.749374] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:40:14 srv11 kernel: [ 1427.198672] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:40:15 srv11 kernel: [ 1427.711731] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:40:15 srv11 kernel: [ 1428.189284] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:40:16 srv11 kernel: [ 1428.701230] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:09 srv11 kernel: [ 1781.780019] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:09 srv11 kernel: [ 1782.350094] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:10 srv11 kernel: [ 1782.853933] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:10 srv11 kernel: [ 1783.303487] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:11 srv11 kernel: [ 1783.757022] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:11 srv11 kernel: [ 1784.260932] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:46:12 srv11 kernel: [ 1784.874611] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:46:13 srv11 kernel: [ 1785.457209] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:46:13 srv11 kernel: [ 1785.933210] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:46:14 srv11 kernel: [ 1786.400550] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:14 srv11 kernel: [ 1786.941620] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:46:15 srv11 kernel: [ 1787.510305] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:46:15 srv11 kernel: [ 1788.077590] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:54 srv11 kernel: [ 1827.316572] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:55 srv11 kernel: [ 1827.721460] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:55 srv11 kernel: [ 1828.150593] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:56 srv11 kernel: [ 1828.620180] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:56 srv11 kernel: [ 1829.120693] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:46:57 srv11 kernel: [ 1829.597494] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:46:57 srv11 kernel: [ 1830.189551] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:46:58 srv11 kernel: [ 1830.745157] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:46:58 srv11 kernel: [ 1831.299635] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:46:59 srv11 kernel: [ 1831.852929] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:47:00 srv11 kernel: [ 1832.408950] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:52:38 srv11 kernel: [ 2170.882305] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:52:39 srv11 kernel: [ 2171.342827] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:39 srv11 kernel: [ 2171.853599] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:40 srv11 kernel: [ 2172.355757] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:40 srv11 kernel: [ 2172.856194] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:41 srv11 kernel: [ 2173.357738] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:41 srv11 kernel: [ 2173.857774] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:42 srv11 kernel: [ 2174.361131] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> Jan 9 11:52:42 srv11 kernel: [ 2174.882971] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:43 srv11 kernel: [ 2175.397627] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:43 srv11 kernel: [ 2175.911679] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:44 srv11 kernel: [ 2176.424397] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:44 srv11 kernel: [ 2176.940545] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:45 srv11 kernel: [ 2177.456173] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> Jan 9 11:52:45 srv11 kernel: [ 2177.971222] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()--
Thanks for this report
This might be a bug because of TCP collapsing
A "netstat -s" would have been a very useful information.
^ permalink raw reply
* [PATCH net-next] bnx2x: align define usage to satisfy static checkers
From: Ariel Elior @ 2013-01-09 17:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ariel Elior
Static checkers complained that the E1H_FUNC_MAX define is used
incorrectly in bnx2x_pretend_func(). The complaint was justified,
although its not a real bug, as the first part of the conditional
protects us in this case (a real bug would happen if a VF tried to
use the pretend func, but there are no VFs in E1H chips).
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 5fcaee1..8740b52 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13361,7 +13361,7 @@ int bnx2x_pretend_func(struct bnx2x *bp, u16 pretend_func_val)
{
u32 pretend_reg;
- if (CHIP_IS_E1H(bp) && pretend_func_val > E1H_FUNC_MAX)
+ if (CHIP_IS_E1H(bp) && pretend_func_val >= E1H_FUNC_MAX)
return -1;
/* get my own pretend register */
--
1.7.9.GIT
^ permalink raw reply related
* Re: tainted warnings with tcp splicing in 3.7.1
From: Eric Dumazet @ 2013-01-09 17:09 UTC (permalink / raw)
To: Christian Becker; +Cc: netdev@vger.kernel.org, Willy Tarreau
In-Reply-To: <1357750898.27446.33.camel@edumazet-glaptop>
On Wed, 2013-01-09 at 09:01 -0800, Eric Dumazet wrote:
> On Wed, 2013-01-09 at 13:01 +0000, Christian Becker wrote:
> > Hi,
> >
> > we´ve installed 3.7.1 yesterday on one of our loadbalancer nodes in order to get TFO.
> >
> > Unfortunately the kernel started to print warnings every couple of minutes when using tcp splicing in haproxy.
> >
> > We´ve built the kernel yesterday from the 3.7.1 sources without any modifications.
> >
> > The System contains two Intel Xeon X6550, 64 GB RAM and there are two kinds of NICs:
> >
> > Broadcom Corporation NetXtreme II BCM5709 (Driver bnx2)
> > Emulex Corporation OneConnect 10Gb NIC (Driver be2net)
> >
> > The bnx2 adapters are not in use and disconnected and the be2net handle about 1 GBit/s of traffic.
> >
> > We´ve downgraded again to our old kernel version, but i guess you should take a look at this.
> >
> > There are two kinds of messages:
> >
> > an 9 11:34:28 srv11 kernel: [ 1081.334970] ------------[ cut here ]------------
> > Jan 9 11:34:28 srv11 kernel: [ 1081.353685] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:34:28 srv11 kernel: [ 1081.371956] Hardware name: System x3690 X5 -[7148Z68]-
> > Jan 9 11:34:28 srv11 kernel: [ 1081.391820] cleanup rbuf bug: copied AD3BCF1 seq AD370AF rcvnxt AD3CF13
> > Jan 9 11:34:28 srv11 kernel: [ 1081.408971] Modules linked in: 8021q garp stp llc nls_utf8 nls_cp437 vfat fat kvm_intel coretemp kvm joydev acpi_cpufreq mperf crc32c_intel hid_generic shpchp snd_pcm snd_timer snd lpc_ich mfd_core cdc_ether usb
> > net mii evdev serio_raw ioatdma processor i2c_i801 tpm_tis dca soundcore snd_page_alloc pcspkr tpm microcode i2c_core tpm_bios thermal_sys button pci_hotplug ext4 mbcache jbd2 crc16 dm_mod sg sr_mod cdrom sd_mod crc_t10dif usbhid ata_generic hi
> > d uhci_hcd ata_piix libata megaraid_sas bnx2 ehci_hcd usbcore scsi_mod usb_common be2net
> > Jan 9 11:34:28 srv11 kernel: [ 1081.532314] Pid: 13763, comm: haproxy Not tainted 3.7.1 #1
> > Jan 9 11:34:28 srv11 kernel: [ 1081.554349] Call Trace:
> > Jan 9 11:34:28 srv11 kernel: [ 1081.573762] [<ffffffff8103ef70>] ? warn_slowpath_common+0x78/0x8c
> > Jan 9 11:34:28 srv11 kernel: [ 1081.596750] [<ffffffff8103f023>] ? warn_slowpath_fmt+0x45/0x4a
> > Jan 9 11:34:28 srv11 kernel: [ 1081.617853] [<ffffffff81297d06>] ? sock_pipe_buf_release+0xe/0xe
> > Jan 9 11:34:28 srv11 kernel: [ 1081.639111] [<ffffffff812d37c2>] ? tcp_cleanup_rbuf+0x4d/0xfc
> > Jan 9 11:34:28 srv11 kernel: [ 1081.661541] [<ffffffff812d39f4>] ? tcp_read_sock+0x183/0x194
> > Jan 9 11:34:28 srv11 kernel: [ 1081.681164] [<ffffffff812d423d>] ? tcp_sendpage+0x45b/0x45b
> > Jan 9 11:34:28 srv11 kernel: [ 1081.703355] [<ffffffff812d3ad8>] ? tcp_splice_read+0xd3/0x223
> > Jan 9 11:34:28 srv11 kernel: [ 1081.724912] [<ffffffff8112d9b9>] ? sys_splice+0x345/0x3c0
> > Jan 9 11:34:28 srv11 kernel: [ 1081.744525] [<ffffffff81364b69>] ? system_call_fastpath+0x16/0x1b
> > Jan 9 11:34:28 srv11 kernel: [ 1081.766683] ---[ end trace fb4ffd749d51e56f ]---
> >
> > Jan 9 11:52:42 srv11 kernel: [ 2174.882971] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:42 srv11 kernel: [ 2174.901182] Hardware name: System x3690 X5 -[7148Z68]-
> > Jan 9 11:52:42 srv11 kernel: [ 2174.921229] recvmsg bug 2: copied 4B9C4CE6 seq 4B9BE950 rcvnxt 4B9C4CE6 fl 0
> > Jan 9 11:52:42 srv11 kernel: [ 2174.941681] Modules linked in: 8021q garp stp llc nls_utf8 nls_cp437 vfat fat kvm_intel coretemp kvm joydev acpi_cpufreq mperf crc32c_intel hid_generic shpchp snd_pcm snd_timer snd lpc_ich mfd_core cdc_ether usb
> > net mii evdev serio_raw ioatdma processor i2c_i801 tpm_tis dca soundcore snd_page_alloc pcspkr tpm microcode i2c_core tpm_bios thermal_sys button pci_hotplug ext4 mbcache jbd2 crc16 dm_mod sg sr_mod cdrom sd_mod crc_t10dif usbhid ata_generic hi
> > d uhci_hcd ata_piix libata megaraid_sas bnx2 ehci_hcd usbcore scsi_mod usb_common be2net
> > Jan 9 11:52:42 srv11 kernel: [ 2175.075389] Pid: 13250, comm: haproxy Tainted: G W 3.7.1 #1
> > Jan 9 11:52:42 srv11 kernel: [ 2175.099391] Call Trace:
> > Jan 9 11:52:42 srv11 kernel: [ 2175.122727] [<ffffffff8103ef70>] ? warn_slowpath_common+0x78/0x8c
> > Jan 9 11:52:42 srv11 kernel: [ 2175.147250] [<ffffffff8103f023>] ? warn_slowpath_fmt+0x45/0x4a
> > Jan 9 11:52:42 srv11 kernel: [ 2175.170289] [<ffffffff81295f64>] ? release_sock+0xe6/0x11c
> > Jan 9 11:52:43 srv11 kernel: [ 2175.192639] [<ffffffff812d45d2>] ? tcp_recvmsg+0x2ca/0x9de
> > Jan 9 11:52:43 srv11 kernel: [ 2175.215020] [<ffffffff812e0b71>] ? tcp_write_xmit+0x849/0x946
> > Jan 9 11:52:43 srv11 kernel: [ 2175.237682] [<ffffffff812f2720>] ? inet_recvmsg+0x64/0x75
> > Jan 9 11:52:43 srv11 kernel: [ 2175.259727] [<ffffffff8129052d>] ? sock_recvmsg+0x56/0x6e
> > Jan 9 11:52:43 srv11 kernel: [ 2175.281111] [<ffffffff8128fedf>] ? sockfd_lookup_light+0x1a/0x50
> > Jan 9 11:52:43 srv11 kernel: [ 2175.300573] [<ffffffff812923f4>] ? sys_recvfrom+0xbf/0x120
> > Jan 9 11:52:43 srv11 kernel: [ 2175.320073] [<ffffffff8135d9f7>] ? __schedule+0x4c9/0x4f6
> > Jan 9 11:52:43 srv11 kernel: [ 2175.341151] [<ffffffff81364b69>] ? system_call_fastpath+0x16/0x1b
> > Jan 9 11:52:43 srv11 kernel: [ 2175.360859] ---[ end trace fb4ffd749d51e5a7 ]---
> >
> > As you can see here, the messages are appearing every couple of minutes:
> >
> > Jan 9 11:34:28 srv11 kernel: [ 1081.353685] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:34:29 srv11 kernel: [ 1081.809446] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:34:29 srv11 kernel: [ 1082.235052] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:34:29 srv11 kernel: [ 1082.692732] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:34:30 srv11 kernel: [ 1083.177807] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:34:30 srv11 kernel: [ 1083.698475] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:34:31 srv11 kernel: [ 1084.221899] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:34:31 srv11 kernel: [ 1084.746992] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:34:32 srv11 kernel: [ 1085.267199] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:37:16 srv11 kernel: [ 1249.252200] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:37:17 srv11 kernel: [ 1249.782915] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:37:17 srv11 kernel: [ 1250.315653] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:37:18 srv11 kernel: [ 1250.867306] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:37:18 srv11 kernel: [ 1251.383968] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:37:19 srv11 kernel: [ 1251.897631] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:37:19 srv11 kernel: [ 1252.412535] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:37:20 srv11 kernel: [ 1252.921313] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:40:13 srv11 kernel: [ 1425.644620] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:40:13 srv11 kernel: [ 1426.314292] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:40:14 srv11 kernel: [ 1426.749374] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:40:14 srv11 kernel: [ 1427.198672] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:40:15 srv11 kernel: [ 1427.711731] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:40:15 srv11 kernel: [ 1428.189284] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:40:16 srv11 kernel: [ 1428.701230] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:09 srv11 kernel: [ 1781.780019] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:09 srv11 kernel: [ 1782.350094] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:10 srv11 kernel: [ 1782.853933] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:10 srv11 kernel: [ 1783.303487] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:11 srv11 kernel: [ 1783.757022] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:11 srv11 kernel: [ 1784.260932] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:46:12 srv11 kernel: [ 1784.874611] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:46:13 srv11 kernel: [ 1785.457209] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:46:13 srv11 kernel: [ 1785.933210] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:46:14 srv11 kernel: [ 1786.400550] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:14 srv11 kernel: [ 1786.941620] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:46:15 srv11 kernel: [ 1787.510305] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:46:15 srv11 kernel: [ 1788.077590] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:54 srv11 kernel: [ 1827.316572] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:55 srv11 kernel: [ 1827.721460] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:55 srv11 kernel: [ 1828.150593] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:56 srv11 kernel: [ 1828.620180] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:56 srv11 kernel: [ 1829.120693] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:46:57 srv11 kernel: [ 1829.597494] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:46:57 srv11 kernel: [ 1830.189551] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:46:58 srv11 kernel: [ 1830.745157] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:46:58 srv11 kernel: [ 1831.299635] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:46:59 srv11 kernel: [ 1831.852929] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:47:00 srv11 kernel: [ 1832.408950] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:52:38 srv11 kernel: [ 2170.882305] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:52:39 srv11 kernel: [ 2171.342827] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:39 srv11 kernel: [ 2171.853599] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:40 srv11 kernel: [ 2172.355757] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:40 srv11 kernel: [ 2172.856194] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:41 srv11 kernel: [ 2173.357738] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:41 srv11 kernel: [ 2173.857774] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:42 srv11 kernel: [ 2174.361131] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> > Jan 9 11:52:42 srv11 kernel: [ 2174.882971] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:43 srv11 kernel: [ 2175.397627] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:43 srv11 kernel: [ 2175.911679] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:44 srv11 kernel: [ 2176.424397] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:44 srv11 kernel: [ 2176.940545] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:45 srv11 kernel: [ 2177.456173] WARNING: at net/ipv4/tcp.c:1639 tcp_recvmsg+0x2ca/0x9de()
> > Jan 9 11:52:45 srv11 kernel: [ 2177.971222] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()--
>
> Thanks for this report
>
> This might be a bug because of TCP collapsing
>
> A "netstat -s" would have been a very useful information.
>
>
My feeling is that tcp_recv_skb() should eat skbs instead of only
finding the right one
Thats because skb_splice_bits() releases the socket lock before calling
splice_to_pipe()
Once socket is released, other incoming TCP frames can be processed, and
the skb we are actually processing might be 'collapsed' into smaller
units.
Christian, if I send you patches, are you OK to test them ?
^ 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