* Re: [PATCH net-next 2/2] ipv6: make lookups simpler and faster
From: David Miller @ 2013-10-09 4:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <20131008.232125.1605815898898029345.davem@davemloft.net>
Eric, I had to fix up l2tp_core.c to accomodate these changes due to
something that came in during the net --> net-next merge, please
double check my work.
Thanks.
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: H. Peter Anvin @ 2013-10-09 3:55 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-dr
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
On 10/02/2013 03:29 AM, Alexander Gordeev wrote:
>
> As result, device drivers will cease to use the overcomplicated
> repeated fallbacks technique and resort to a straightforward
> pattern - determine the number of MSI/MSI-X interrupts required
> before calling pci_enable_msi_block() and pci_enable_msix()
> interfaces:
>
>
> rc = pci_msix_table_size(adapter->pdev);
> if (rc < 0)
> return rc;
>
> nvec = min(nvec, rc);
> if (nvec < FOO_DRIVER_MINIMUM_NVEC) {
> return -ENOSPC;
>
> for (i = 0; i < nvec; i++)
> adapter->msix_entries[i].entry = i;
>
> rc = pci_enable_msix(adapter->pdev,
> adapter->msix_entries, nvec);
> return rc;
>
Why not add a minimum number to pci_enable_msix(), i.e.:
pci_enable_msix(pdev, msix_entries, nvec, minvec)
... which means "nvec" is the number of interrupts *requested*, and
"minvec" is the minimum acceptable number (otherwise fail).
-hpa
^ permalink raw reply
* Re: [PATCH net-next 2/2] ipv6: make lookups simpler and faster
From: David Miller @ 2013-10-09 3:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1380840149.19002.256.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 Oct 2013 15:42:29 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP listener refactoring, part 4 :
>
> To speed up inet lookups, we moved IPv4 addresses from inet to struct
> sock_common
>
> Now is time to do the same for IPv6, because it permits us to have fast
> lookups for all kind of sockets, including upcoming SYN_RECV.
>
> Getting IPv6 addresses in TCP lookups currently requires two extra cache
> lines, plus a dereference (and memory stall).
>
> inet6_sk(sk) does the dereference of inet_sk(__sk)->pinet6
>
> This patch is way bigger than its IPv4 counter part, because for IPv4,
> we could add aliases (inet_daddr, inet_rcv_saddr), while on IPv6,
> it's not doable easily.
>
> inet6_sk(sk)->daddr becomes sk->sk_v6_daddr
> inet6_sk(sk)->rcv_saddr becomes sk->sk_v6_rcv_saddr
>
> And timewait socket also have tw->tw_v6_daddr & tw->tw_v6_rcv_saddr
> at the same offset.
>
> We get rid of INET6_TW_MATCH() as INET6_MATCH() is now the generic
> macro.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks a lot Eric.
^ permalink raw reply
* [PATCH net-next] openvswitch: fix vport-netdev unregister
From: Alexei Starovoitov @ 2013-10-09 3:07 UTC (permalink / raw)
To: David S. Miller; +Cc: Jesse Gross, Pravin B Shelar, Jiri Pirko, dev, netdev
The combination of two commits
commit 8e4e1713e4
("openvswitch: Simplify datapath locking.")
and
commit 2537b4dd0a
("openvswitch:: link upper device for port devices")
introduced a bug where upper_dev wasn't unlinked upon
netdev_unregister notification
The following steps:
modprobe openvswitch
ovs-dpctl add-dp test
ip tuntap add dev tap1 mode tap
ovs-dpctl add-if test tap1
ip tuntap del dev tap1 mode tap
are causing multiple warnings:
[ 62.747557] gre: GRE over IPv4 demultiplexor driver
[ 62.749579] openvswitch: Open vSwitch switching datapath
[ 62.755087] device test entered promiscuous mode
[ 62.765911] device tap1 entered promiscuous mode
[ 62.766033] IPv6: ADDRCONF(NETDEV_UP): tap1: link is not ready
[ 62.769017] ------------[ cut here ]------------
[ 62.769022] WARNING: CPU: 1 PID: 3267 at net/core/dev.c:5501 rollback_registered_many+0x20f/0x240()
[ 62.769023] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
[ 62.769051] CPU: 1 PID: 3267 Comm: ip Not tainted 3.12.0-rc3+ #60
[ 62.769052] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
[ 62.769053] 0000000000000009 ffff8807f25cbd28 ffffffff8175e575 0000000000000006
[ 62.769055] 0000000000000000 ffff8807f25cbd68 ffffffff8105314c ffff8807f25cbd58
[ 62.769057] ffff8807f2634000 ffff8807f25cbdc8 ffff8807f25cbd88 ffff8807f25cbdc8
[ 62.769059] Call Trace:
[ 62.769062] [<ffffffff8175e575>] dump_stack+0x55/0x76
[ 62.769065] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
[ 62.769067] [<ffffffff8105319a>] warn_slowpath_null+0x1a/0x20
[ 62.769069] [<ffffffff8162a04f>] rollback_registered_many+0x20f/0x240
[ 62.769071] [<ffffffff8162a101>] rollback_registered+0x31/0x40
[ 62.769073] [<ffffffff8162a488>] unregister_netdevice_queue+0x58/0x90
[ 62.769075] [<ffffffff8154f900>] __tun_detach+0x140/0x340
[ 62.769077] [<ffffffff8154fb36>] tun_chr_close+0x36/0x60
[ 62.769080] [<ffffffff811bddaf>] __fput+0xff/0x260
[ 62.769082] [<ffffffff811bdf5e>] ____fput+0xe/0x10
[ 62.769084] [<ffffffff8107b515>] task_work_run+0xb5/0xe0
[ 62.769087] [<ffffffff810029b9>] do_notify_resume+0x59/0x80
[ 62.769089] [<ffffffff813a41fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 62.769091] [<ffffffff81770f5a>] int_signal+0x12/0x17
[ 62.769093] ---[ end trace 838756c62e156ffb ]---
[ 62.769481] ------------[ cut here ]------------
[ 62.769485] WARNING: CPU: 1 PID: 92 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
[ 62.769486] sysfs: can not remove 'master', no directory
[ 62.769486] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
[ 62.769514] CPU: 1 PID: 92 Comm: kworker/1:2 Tainted: G W 3.12.0-rc3+ #60
[ 62.769515] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
[ 62.769518] Workqueue: events ovs_dp_notify_wq [openvswitch]
[ 62.769519] 0000000000000009 ffff880807ad3ac8 ffffffff8175e575 0000000000000006
[ 62.769521] ffff880807ad3b18 ffff880807ad3b08 ffffffff8105314c ffff880807ad3b28
[ 62.769523] 0000000000000000 ffffffff81a87a1f ffff8807f2634000 ffff880037038500
[ 62.769525] Call Trace:
[ 62.769528] [<ffffffff8175e575>] dump_stack+0x55/0x76
[ 62.769529] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
[ 62.769531] [<ffffffff81053236>] warn_slowpath_fmt+0x46/0x50
[ 62.769533] [<ffffffff8123e7e9>] sysfs_hash_and_remove+0xa9/0xb0
[ 62.769535] [<ffffffff81240e96>] sysfs_remove_link+0x26/0x30
[ 62.769538] [<ffffffff81631ef7>] __netdev_adjacent_dev_remove+0xf7/0x150
[ 62.769540] [<ffffffff81632037>] __netdev_adjacent_dev_unlink_lists+0x27/0x50
[ 62.769542] [<ffffffff8163213a>] __netdev_adjacent_dev_unlink_neighbour+0x3a/0x50
[ 62.769544] [<ffffffff8163218d>] netdev_upper_dev_unlink+0x3d/0x140
[ 62.769548] [<ffffffffa033c2db>] netdev_destroy+0x4b/0x80 [openvswitch]
[ 62.769550] [<ffffffffa033b696>] ovs_vport_del+0x46/0x60 [openvswitch]
[ 62.769552] [<ffffffffa0335314>] ovs_dp_detach_port+0x44/0x60 [openvswitch]
[ 62.769555] [<ffffffffa0336574>] ovs_dp_notify_wq+0xb4/0x150 [openvswitch]
[ 62.769557] [<ffffffff81075c28>] process_one_work+0x1d8/0x6a0
[ 62.769559] [<ffffffff81075bc8>] ? process_one_work+0x178/0x6a0
[ 62.769562] [<ffffffff8107659b>] worker_thread+0x11b/0x370
[ 62.769564] [<ffffffff81076480>] ? rescuer_thread+0x350/0x350
[ 62.769566] [<ffffffff8107f44a>] kthread+0xea/0xf0
[ 62.769568] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[ 62.769570] [<ffffffff81770bac>] ret_from_fork+0x7c/0xb0
[ 62.769572] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[ 62.769573] ---[ end trace 838756c62e156ffc ]---
[ 62.769574] ------------[ cut here ]------------
[ 62.769576] WARNING: CPU: 1 PID: 92 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
[ 62.769577] sysfs: can not remove 'upper_test', no directory
[ 62.769577] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
[ 62.769603] CPU: 1 PID: 92 Comm: kworker/1:2 Tainted: G W 3.12.0-rc3+ #60
[ 62.769604] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
[ 62.769606] Workqueue: events ovs_dp_notify_wq [openvswitch]
[ 62.769607] 0000000000000009 ffff880807ad3ac8 ffffffff8175e575 0000000000000006
[ 62.769609] ffff880807ad3b18 ffff880807ad3b08 ffffffff8105314c ffff880807ad3b58
[ 62.769611] 0000000000000000 ffff880807ad3bd9 ffff8807f2634000 ffff880037038500
[ 62.769613] Call Trace:
[ 62.769615] [<ffffffff8175e575>] dump_stack+0x55/0x76
[ 62.769617] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
[ 62.769619] [<ffffffff81053236>] warn_slowpath_fmt+0x46/0x50
[ 62.769621] [<ffffffff8123e7e9>] sysfs_hash_and_remove+0xa9/0xb0
[ 62.769622] [<ffffffff81240e96>] sysfs_remove_link+0x26/0x30
[ 62.769624] [<ffffffff81631f22>] __netdev_adjacent_dev_remove+0x122/0x150
[ 62.769627] [<ffffffff81632037>] __netdev_adjacent_dev_unlink_lists+0x27/0x50
[ 62.769629] [<ffffffff8163213a>] __netdev_adjacent_dev_unlink_neighbour+0x3a/0x50
[ 62.769631] [<ffffffff8163218d>] netdev_upper_dev_unlink+0x3d/0x140
[ 62.769633] [<ffffffffa033c2db>] netdev_destroy+0x4b/0x80 [openvswitch]
[ 62.769636] [<ffffffffa033b696>] ovs_vport_del+0x46/0x60 [openvswitch]
[ 62.769638] [<ffffffffa0335314>] ovs_dp_detach_port+0x44/0x60 [openvswitch]
[ 62.769640] [<ffffffffa0336574>] ovs_dp_notify_wq+0xb4/0x150 [openvswitch]
[ 62.769642] [<ffffffff81075c28>] process_one_work+0x1d8/0x6a0
[ 62.769644] [<ffffffff81075bc8>] ? process_one_work+0x178/0x6a0
[ 62.769646] [<ffffffff8107659b>] worker_thread+0x11b/0x370
[ 62.769648] [<ffffffff81076480>] ? rescuer_thread+0x350/0x350
[ 62.769650] [<ffffffff8107f44a>] kthread+0xea/0xf0
[ 62.769652] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[ 62.769654] [<ffffffff81770bac>] ret_from_fork+0x7c/0xb0
[ 62.769656] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[ 62.769657] ---[ end trace 838756c62e156ffd ]---
[ 62.769724] device tap1 left promiscuous mode
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
net/openvswitch/dp_notify.c | 5 +++++
net/openvswitch/vport-netdev.c | 16 +++++++++++++---
net/openvswitch/vport-netdev.h | 1 +
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/net/openvswitch/dp_notify.c b/net/openvswitch/dp_notify.c
index c323567..e9380bd 100644
--- a/net/openvswitch/dp_notify.c
+++ b/net/openvswitch/dp_notify.c
@@ -88,6 +88,11 @@ static int dp_device_event(struct notifier_block *unused, unsigned long event,
return NOTIFY_DONE;
if (event == NETDEV_UNREGISTER) {
+ /* rx_handler_unregister and upper_dev_unlink immediately */
+ if (dev->reg_state == NETREG_UNREGISTERING)
+ ovs_netdev_unlink_dev(vport);
+
+ /* schedule vport destroy, dev_put and genl notification */
ovs_net = net_generic(dev_net(dev), ovs_net_id);
queue_work(system_wq, &ovs_net->dp_notify_work);
}
diff --git a/net/openvswitch/vport-netdev.c b/net/openvswitch/vport-netdev.c
index 09d93c1..cce933a 100644
--- a/net/openvswitch/vport-netdev.c
+++ b/net/openvswitch/vport-netdev.c
@@ -150,15 +150,25 @@ static void free_port_rcu(struct rcu_head *rcu)
ovs_vport_free(vport_from_priv(netdev_vport));
}
-static void netdev_destroy(struct vport *vport)
+void ovs_netdev_unlink_dev(struct vport *vport)
{
struct netdev_vport *netdev_vport = netdev_vport_priv(vport);
- rtnl_lock();
+ ASSERT_RTNL();
netdev_vport->dev->priv_flags &= ~IFF_OVS_DATAPATH;
netdev_rx_handler_unregister(netdev_vport->dev);
- netdev_upper_dev_unlink(netdev_vport->dev, get_dpdev(vport->dp));
+ netdev_upper_dev_unlink(netdev_vport->dev,
+ netdev_master_upper_dev_get(netdev_vport->dev));
dev_set_promiscuity(netdev_vport->dev, -1);
+}
+
+static void netdev_destroy(struct vport *vport)
+{
+ struct netdev_vport *netdev_vport = netdev_vport_priv(vport);
+
+ rtnl_lock();
+ if (netdev_vport->dev->reg_state != NETREG_UNREGISTERING)
+ ovs_netdev_unlink_dev(vport);
rtnl_unlock();
call_rcu(&netdev_vport->rcu, free_port_rcu);
diff --git a/net/openvswitch/vport-netdev.h b/net/openvswitch/vport-netdev.h
index dd298b5..21e3770 100644
--- a/net/openvswitch/vport-netdev.h
+++ b/net/openvswitch/vport-netdev.h
@@ -39,5 +39,6 @@ netdev_vport_priv(const struct vport *vport)
}
const char *ovs_netdev_get_name(const struct vport *);
+void ovs_netdev_unlink_dev(struct vport *);
#endif /* vport_netdev.h */
--
1.7.9.5
^ permalink raw reply related
* You’re ATM CARD Compensation Gift
From: Mr. Alpha Isoko @ 2013-10-09 2:44 UTC (permalink / raw)
You’re ATM CARD Compensation Gift
Dear,
I am ( Mr Alpha Isoko ) glad to inform you that I have successfully concluded the transaction. The money/fund has been transferred to China through the assistance of Mr.Pong Euge, who is a business man base in China Currently I am in China righty now with him.
However, I did not forget you assists/helps because of your passed efforts also you are the source of my success to achieve the fund.
In appreciate of your effort/assistance I already mapped out/deposited ATM CARD sum of Four Hundred And Fifty Thousand United States Dollars ( US$ 450,000.00 ) as a Compensation and wrote on your favour) I left the ATM CARD sum of ( US$ 450,000.00 ) with my Secretary mr.John Mark in country Burkina Faso, on my departure to China. I would like you to contact him in Burkina Faso with the below information and instruct him where to send the ATM CARD sum of Four Hundred And Fifty Thousand United States Dollars ( US$ 450,000.00 ) to you.
Post Office Burkina Faso
Name: mr.John Mark
CONTACT HIM THROUGH EMAIL ADDRESS ON THE ABOVE SUBJECT.
( mrmark_john01@yahoo.fr )
His Direct telephone number in Burkina Faso: +22676302353
You should follow up his instructions, so that he will send the ATM CARD to you immediately, to avoid any delay / mistake.
Note: I can not check my email any more; because I am very much busy here in china investing many projects with my new partner Mr.Pong Euge,
Best Regards,
Mr Alpha Isoko.
^ permalink raw reply
* [PATCH] Stmmac: fix a bug when clk_csr == 0x0
From: Wan ZongShun @ 2013-10-09 2:37 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, Wan ZongShun
Hi Giuseppe,
According to spec, if csr clock freq is 60-100Mhz, we have to set CR[5:2] = 0000
but when I set the 'plat_dat.clk_csr = 0',acctually, this value is not used
since the driver code judge 'if (!priv->plat->clk_csr)' then go to dynamic tune
the MDC clock. So I add other judge condition.
Signed-off-by: Wan Zongshun <mcuos.com@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
include/linux/stmmac.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8d4ccd3..a849092c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2741,7 +2741,7 @@ struct stmmac_priv *stmmac_dvr_probe(struct
device *device,
* set the MDC clock dynamically according to the csr actual
* clock input.
*/
- if (!priv->plat->clk_csr)
+ if (priv->plat->dynamic_mdc_clk_en)
stmmac_clk_csr_set(priv);
else
priv->clk_csr = priv->plat->clk_csr;
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index bb5deb0..e2552ce 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -101,6 +101,7 @@ struct plat_stmmacenet_data {
struct stmmac_mdio_bus_data *mdio_bus_data;
struct stmmac_dma_cfg *dma_cfg;
int clk_csr;
+ int dynamic_mdc_clk_en;
int has_gmac;
int enh_desc;
int tx_coe;
--
1.8.1.2
--
Wan ZongShun.
www.mcuos.com
^ permalink raw reply related
* Re: Pull request: sfc 2013-10-08
From: David Miller @ 2013-10-09 1:56 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1381254091.1530.9.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 8 Oct 2013 18:41:31 +0100
> Some more fixes for EF10 support; hopefully the last lot:
>
> 1. Fixes for reading statistics, from Edward Cree and Jon Cooper.
> 2. Addition of ethtool statistics for packets dropped by the hardware
> before they were associated with a specific function, from Edward Cree.
> 3. Only bind to functions that are in control of their associated port,
> as the driver currently assumes this is the case.
Pulled, thanks Ben.
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Mark Lord @ 2013-10-09 1:55 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel
Cc: Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers, VMware,
"Inc." <pv-drive
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
On 13-10-02 06:29 AM, Alexander Gordeev wrote:
..
> This update converts pci_enable_msix() and pci_enable_msi_block()
> interfaces to canonical kernel functions and makes them return a
> error code in case of failure or 0 in case of success.
Rather than silently break dozens of drivers in mysterious ways,
please invent new function names for the replacements to the
existing pci_enable_msix() and pci_enable_msi_block() functions.
That way, both in-tree and out-of-tree drivers will notice the API change,
rather than having it go unseen and just failing for unknown reasons.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 net] pkt_sched: fq: fix non TCP flows pacing
From: David Miller @ 2013-10-09 1:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, sesse
In-Reply-To: <1381270560.12191.64.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 08 Oct 2013 15:16:00 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Steinar reported FQ pacing was not working for UDP flows.
>
> It looks like the initial sk->sk_pacing_rate value of 0 was
> a wrong choice. We should init it to ~0U (unlimited)
>
> Then, TCA_FQ_FLOW_DEFAULT_RATE should be removed because it makes
> no real sense. The default rate is really unlimited, and we
> need to avoid a zero divide.
>
> Reported-by: Steinar H. Gunderson <sesse@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> I removed the ACCESS_ONCE() stuff, as it adds conflicts for
> next (net / net-next) merge. I'll send a separate patch later.
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: David Miller @ 2013-10-09 1:52 UTC (permalink / raw)
To: stephen; +Cc: yamato, netdev
In-Reply-To: <20131008141337.1a8a556c@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 8 Oct 2013 14:13:37 -0700
> Please revert this. It is incorrect.
Ok, done.
^ permalink raw reply
* Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
From: Hannes Frederic Sowa @ 2013-10-09 1:43 UTC (permalink / raw)
To: Duan Jiong, David Miller, netdev
In-Reply-To: <20130918041337.GD8947@order.stressinduktion.org>
Hi Duan!
On Wed, Sep 18, 2013 at 06:13:37AM +0200, Hannes Frederic Sowa wrote:
> Especially because redirects also help in the on-link determination (same
> RFC, section 8), I changed my mind and am still in favour of updating it
> in the ndisc layer. In my opinion we just have to consider all routing
> tables and apply the update to every one which carries a valid next hop
> to the source of the redirect (under consideration of the destination).
>
> This will be important if we actually try to get linux to correctly
> implement the ipv6 subnet model (RFC 5942, Section 4 Rule 1). In that
> case we are not allowed to assume nodes on-link even if they would match
> the same prefix as a locally configured address.
I am playing around with a simple patch which does suppress adding routing
information for the on-link assumption we currently do in linux.
Are you intereseted in following up on this? I still do think we should update
not only the routing table the socket uses but all routing tables which have a
valid route towards the router which emitted the redirect.
I try to check if we actually handle redirect messages when ECMP routes are in
use correctly.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCHv1 net] xen-netback: transition to CLOSED when removing a VIF
From: David Miller @ 2013-10-09 1:34 UTC (permalink / raw)
To: david.vrabel
Cc: xen-devel, konrad.wilk, boris.ostrovsky, netdev, ian.campbell,
wei.liu2, Paul.Durrant
In-Reply-To: <1381150519-14557-1-git-send-email-david.vrabel@citrix.com>
From: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 7 Oct 2013 13:55:19 +0100
> From: David Vrabel <david.vrabel@citrix.com>
>
> If a guest is destroyed without transitioning its frontend to CLOSED,
> the domain becomes a zombie as netback was not grant unmapping the
> shared rings.
>
> When removing a VIF, transition the backend to CLOSED so the VIF is
> disconnected if necessary (which will unmap the shared rings etc).
>
> This fixes a regression introduced by
> 279f438e36c0a70b23b86d2090aeec50155034a9 (xen-netback: Don't destroy
> the netdev until the vif is shut down).
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Michael Ellerman @ 2013-10-09 1:34 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Benjamin Herrenschmidt,
Martin Schwidefsky, Ingo Molnar, Tejun Heo, Dan Williams,
Andy King, Jon Mason, Matt Porter, linux-pci, linux-mips,
linuxppc-dev, linux390, linux-s390, x86, linux-ide,
iss_storagedev, linux-nvme, linux-rdma, netdev, e1000-devel,
linux-driver, Solarflare linux maintainers, VMware, Inc.,
linux-scsi
In-Reply-To: <20131008073301.GC10669@dhcp-26-207.brq.redhat.com>
On Tue, Oct 08, 2013 at 09:33:02AM +0200, Alexander Gordeev wrote:
> On Tue, Oct 08, 2013 at 03:33:30PM +1100, Michael Ellerman wrote:
> > On Wed, Oct 02, 2013 at 12:29:04PM +0200, Alexander Gordeev wrote:
> > > This technique proved to be confusing and error-prone. Vast share
> > > of device drivers simply fail to follow the described guidelines.
> >
> > To clarify "Vast share of device drivers":
> >
> > - 58 drivers call pci_enable_msix()
> > - 24 try a single allocation and then fallback to MSI/LSI
> > - 19 use the loop style allocation as above
> > - 14 try an allocation, and if it fails retry once
> > - 1 incorrectly continues when pci_enable_msix() returns > 0
> >
> > So 33 drivers (> 50%) successfully make use of the "confusing and
> > error-prone" return value.
>
> Ok, you caught me - 'vast share' is incorrect and is a subject to
> rewording. But out of 19/58 how many drivers tested fallbacks on the
> real hardware? IOW, which drivers are affected by the pSeries quota?
It's not 19/58, it's 33/58.
As to how many we care about on powerpc I can't say, so you have a point
there. But I still think the interface is not actually that terrible.
cheers
^ permalink raw reply
* [PATCH] rtlwifi: Add new firmware files for rtl8188eu
From: Larry Finger @ 2013-10-08 23:28 UTC (permalink / raw)
To: dwmw2, Ben Hutchings; +Cc: Larry Finger, netdev
The vendor driver RTL8188EUS_linux_v4.1.4_6773.20130222 contains
firmware in the form of data statements. This info has been extracted
into a binary file.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
WHENCE | 9 +++++++++
rtlwifi/rtl8188eufw.bin | Bin 0 -> 13904 bytes
2 files changed, 9 insertions(+)
create mode 100644 rtlwifi/rtl8188eufw.bin
diff --git a/WHENCE b/WHENCE
index 27865b6..ee963a0 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1893,6 +1893,15 @@ Licence: Redistributable. See
LICENCE.rtlwifi_firmware.txt for details.
--------------------------------------------------------------------------
+Driver: rtl8188eu - Realtek 802.11n WLAN driver for RTL8188EU
+
+Info: Taken from Realtek version RTL8188EUS_linux_v4.1.4_6773.20130222
+File: rtlwifi/rtl8188eufw.bin
+
+Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details.
+
+--------------------------------------------------------------------------
+
Driver: r8169 - RealTek 8169/8168/8101 ethernet driver.
File: rtl_nic/rtl8168d-1.fw
diff --git a/rtlwifi/rtl8188eufw.bin b/rtlwifi/rtl8188eufw.bin
new file mode 100644
index
0000000000000000000000000000000000000000..4ae7e1c5deb7846e59c461546a49679504ffed28
GIT binary patch
literal 13904
zcmeHud2|%Vx$ksO&mtkTv{-#@BZgs*(1^ug2ZI0s#%7UB3p?HzJ9vQ@GniI9#DVD+
zFAiR=X$6v#dy{KB8OQO4^|(*IFE?J0Eu3IG!NNE>j^7Cs!;J8PG|iX+fi%<a_f^kG
z2s_C==l=8lcsi%2wy&zb`s%B1tJ3kErH&yE!6A$-n;5vt;i&XD2K|YPR}Lzp@YbeF
zYyN)u7oB#yxaQp72mJr7|L;-Y?G`ONU0x{tpkqj5hxbMH_7jQ6{P(6GOFS`iYx;=~
zpE%`zw5RiRr>I)(Kh|4o95siwN?~n8r#Cd@?Uv5KacAwQvmds2|I+pO;~l<4ku}b*
z_mp_O`z0yj2<x4Jc*>C|YJa+}!d0a19ADJanR!n4cD_>dCJp(=o=-OhnYXizX=f8f
zN1m>km?)z8a?P1hoqy~}=o^FX4t92wmPX^wgJ*{qX-5)8G*3h#6qvI#Rupjrj(Y+p
zq=;8JqkR8&AGRpkLXR)J^Eq902HlqTyVkMZh!hWNXT4{=$1a5R?*@#;M^#~W8;j#x
z^r+DISg`Sltsg$|VT;e1JhI1G<BV87Rj;b*>8wbc!9=wIEcBJ4ZY*YOvAT0wPv?1W
z=P168OxOBgLBYw<qt6u-XkU&Pp?%Vg#YisQrBlX7(B97T-LDpjFX*G(?oQre^yrfX
z1?NU<UtX#GCF$SU(<${Nt0bVc`>Z!vwfk(u;p;~vN$c$la72_RfJma~RZpS16WFD7
zap8)(Y3ifM?<cB)Z0D(^x3llF`-9%+T_?|8F<LwGyz@EN80vNc19Rxis7Hhnf_zT!
zJ|a<*__E%GE<+2RcXgiA&QR6SNA<5DLS#?40!;ic{$UKn2K8e?iMVk2E;DXrX>+um
zw_gaH8yfL;28UFh4F>9_X`aAoch}kA`0b)MV3uNt(v#zg1F<4>mo%A|%av0ru{NwH
z;`JtLcYy3`_+GBEeD9b&Q8vj$l4u&<6cUH;U~^1g@>Z++mTcFzGN*3t^CfSvy06c6
zEz6v`uFuE%qAU|-*(kGou|97s<Bes#G30x_vGd;81#j&A9^a{yw=3oCPI;3l-?QVJ
z(oG3-){gWJAM1^>3sH97_k|h#+>Cx^`Z{)WH1))Hhh*?fXlOLLy9b$c)6O07EvmTt
zzF;yMjcUil#ZQO}{~F&N1!%O!c~%or-eYI9$yB3w{6z=bXB<#UYAX)zsFBXB(S#*u
zkHxhif+%@QD{3@j@!|M(VR!KLsHMygBnp%<S#%5v#UChb<5}?en%|&!fyTmj@SUcE
z@4d6*J+nV|?6adMwKp9LnhNk0;v4DsR_r$a9k;LjMH_1~+jg`ywRJRhINBU-LYvs;
zY?IntZSFRYAskRUO?7e9JUmP7lu+b_4o`=>!_^^mI6K4+p~KP9(a{7dm>q1o;ZRt^
ztn}4U)^Jt&8vM>qe-poR(sTD-9Z}@zSMI$g(m=^KBWoy`8@UO|>gJ^HA0o2JRF_0e
z`TlTXK_D(g#O8^}bUNkx|CCsSqb}FKjr6!vUQvWJ=9HJeh4cj4V@Tspd833hfpiAa
zPVsa}qL#qxBkCr5Wf=YMtxP-0T7_~$pU8qk4Sgz8vZmq*iKnOd41EkU^vMC{VwR}x
zV%9d{NNJ1E-qv9>m3NtjK7|=g!;tz}_CR^L;sm<lb<cDoU#<vt0RSw!DMa;2`W@-d
zQc~y72J8KOlzrUa7o_Iy)?%l;><;P>azzAr*>1|Vx=}fk=cE!$%dDVF-qNT!<$ESj
z?K&^-EN?l2A^vvX;sW`)U+ow26Rax=io!Exze=tXc;<q@`?eN)$^a!+b1YijVzoVU
zkzHMOfzK#~Zj&EOqiaa1ep9RCxcyf;hNOs4Z7)i?Oy2UEHk@}YDmL`-%mT^gL%vk+
z>*)AVi|_DDgqqh7exnMeb}f+@5ar640OOUSsZC1aVC9OEsg1@?u_Jq=8s6?THA>@V
zMDQ8Hf2yJhk!E14fps;_r({gS<x@8S;PlY_f=n~iYP6?nF@DFHyqjQR5D9toFx*lF
zD`K@Z90)TOGbO_FMZ5!si`$Ux<rTmZBNdt2mFPx&@`Fp5cA{Mvr&57;Y8sw2W#w+8
zX*dhIcpY^|Ga*uaf(l-{KuBBW>1zyOHWrnMIO}h!J`o4NCCxv0O|JOl52m9n^2Bzp
zJnfeTuYff&EE3vYOcnZhK#+M7&scK9<&p0LuJX21wOXIi<dQ26(QoZvc)vru5q$)Q
zI^T@i#9Pg3D~L)n)fzJsx72H)jaFpOs)4F>Q+%e7-qCIPa>oVuy>H56p0yMqONUCy
zuFRTAMYOt=%qojovWk>RD!nT#G@IRuH=9(>t<1HQq9vJcsX)uImDGi(EZ%tsjb{be
zMogiOHIp_Q4XIy=GOGm}6k+lTGiq+Dv6?3ka3;q`9u6U!U7U^V5*_9->_EBV2{5~c
zSmJ$#JwxhaK~WzW5x}^Z47`!6T_;h!C9f{lM{;xsv6BQ-{WS==x7EbI78P+2Dzy3e
ziN~>ZV(5xYM3R?YE7xz?FBA~7LmX*N+PtOLY74*tkX7Ss?y51hz{MzzW38fln*gml
z1Td`C>p`Ii{SME>K=RV7<y(HukKHyA@^=CnMZTTct}}OBvZKk+>}_EVBu1P7Js1(?
z&ASZYrZ|quT(D$rWI9jEIa5iRhP#j{J;W(jsbMopAYrTiCQJq1rN&whmO4EOBHwJ%
z5p5MfU!2fhR8L_Qv0}npTnZsDp4IZh$afqkjOY@)hD3KrN(NXV!J}r<z8wUc+vj11
zUdgN|+Y~B1{m16Z4SgEJHVd6BH&lSR4Sg(aC&mdbrk;6GBOAguSs*@ydR4MvhHHyy
zG!2P2nu1*WLc7sa#P(>YVC%F!TFnqc_$et5Rx6ltW6$9~8~S_}U`6rt717hZppfdq
zv~TihxgZLPZ;j))^K=3OA3{3$4EIae$!Vb5i%2VR+^i7RTFJ7O=0F1|Y7+vC9k_^c
z16#ngSccPHpTI1P>(A7QS_$zcl$pFS1@-a3yBE<2BAC<YRgVN3am7c+3rD~vImB^D
zJUkZ-6G?*JV_;mRBv?-b4>>JJb)tMxkZUF3R+|?j)0X0MKmkL)hP9U~k@S`E-c01?
z?SfqAGK5=+B<>$^+C%($Nqk~J;!a|9pCMhw&IFw#x}|?&if5fC0)2&|To>%$5#m`e
zlD-gYtF-wCnsFrP%vuY<@3qLqQ2|obGRT)j>{X8|9yL!7@x`rOs}1Q2790(+%F=7N
zWF;-B_M#%O#sr;^mBy$Qq)0GI2_%W(>S3XhC<_h2=fUSh+YzIwl<oNx5DcC~p&_)9
zcm%4E>DwLh^cT^P;~Q<iI;N6DWM6s*Q|6n=;1%lF{)*aC^P*;GB;Q4iI87Hf*1#IJ
znNpaqmXb117w3fVoQs4os})VY1y?hh{K|IW$<ezmOI)dV4$M&44@U3!!DUTm;tIQH
zC9dQrXI0evB42ZbT>~%xN2BH&LJ{&$A{$kmrY~O~#ZH1s`U?9j-JDanb*P~|Ag1Ol
zi1SS%$;Cmdw<JT7-Dd?0`iXf#1dec(yefZiz!w#<e#St@<$R8iIQBt%mLTPF>>l*N
zymCsRvG!qy&4eQ!V8ODaeUhRkouuWQ@90QegwJv_hYyXvoCO!<@ZtTPtwI4uEWos(
zxlE(!eAb@@UsW-n+m}1%gV8lyix@nnlOkCoB&~3;Xx=hA@l->kyB6Fkubi9Ln1+5O
z<e)?nn;Ky`X<+ls#av1o`VA~tf<xwl4i=I0fyM2iN~5_&S?%RyO+8h1z!pQE=DWFF
zf%&=ggftz;wmVuyal1g8ZJVQ261NFmD?{UwyzAJf>LCkBS-9hwNRbAWGmeGawi3c9
zgdZdd7s0eIA`UDU4`L7!my3rYc_riqx{#{LPdxu`PCPz8v8=w#XD*_dy&A+i(2!6d
zRX0GP_vOW7$fy7=Cb!^FF~V>N@|ZVZJC4;LbOzOM`B%Z*acgt22GVd^<_&s~z-Ss_
zZVHLIlpGeEH!OJ9u#kA?Z|LWkpA@`=c4oCoQu6|Uw2D%5UB1pKH7lqiV_KJ*7v-w~
z`ehFE=6oGMKSf<=Tk}+HD~;GHxnwn{ZRB}DY96cI#j{RSZ`RgOK2+B{Mq5rfOpog2
z+WaJ#qj{z_o8xgztKwjjo2P5zZ7}Nnur`W=4be&oY@Zt@F^wiR7x1MwPbFh=6E_)@
z{a_#;EKXnZRC(E7DKC;V_R)#90WA)J)870gnXu@AQ|LqSW-ZzLsrE&V!BB@$@?;eR
z&Y`dy(cS&O)dKvss*jj?Yg389+7!6837vY0wQ1Y1a9#)7ux*#xu+Diw@W#H&?N!}P
zSOZPY?lv}dmh5ga-t9HfarnyOb7;4D+FWEG10g*D<lq#0<X}2?_zr^alJeq74VxVe
z-xC^khz*ZB8}>*IKd)$bc5K7maSgBf8{Qn>@cRi3AGA3f4IdjidW;Y^{LftGZr#o-
zXv<YJ=0LPsyW*`Iat#}L?9B1wxr*!W&t<+d&(3JMRQ%3Lu5z$j@+~*?o7#)X)HeCK
z8fKpiLtkPV4iRU>(3b)@Z<NpHkTy)#a4D?)DMPO@lQ07MHx@90A-oO})-XeOBiB2E
zQ*S11pBKuJpFc}6VRdA=957d+(uoNbVLU?>?7|FiQc4aeCeAKNidBG+I7*Yv!@nbc
zjXPeLXd)*1Ez-$IUqedJFrtVx`SE}7e-Vr&FP}##^!P<bUMaEcm1g7z5B%de#5q%4
zLve^-C6-bAVAEElG4V7N5pCG?&xz|P8nNkJq=-6%e2E(Z$Hn?E63AH#$qDf^ODqo@
zcSW3X?L_1Nw(<Z{1SdjskRqrNI;5VnqY{|w??okOH8WuwK}(F|n&uMwscew>1afe5
zTV6WFM|*1M)gX~@Fb;DiYCbG{Pv2S}v9j{iiQIRnXX~6nr%!kZCwL90x`tWpd&C-1
z=xkTBPh0Uljx6tUBRY_u|B#{I$SkET8+0X=qR<Gt7zo~*RGh)P41G2BOCxQ*8iTE7
zXbwSEb(1e<=nD3_h_cYSLs?b{P*u0$1h41{TNel^QF3oq8jdtmY7G4*lZ6(Lo1m2%
z`pq;ltlu@za6%cytv)l=o2cu};E01rZ$$boQcNqnXF_3&LEuUIlh1IRV-+V0SVXAk
zEQ*M{jPOvz=_@;FXmgWhb-5v|!|-C|udDUyebqJ9Yvbuz>8sMS({uLDiqugU>#9gS
zC9@+pQZgs9TAY4m<F%#n^t{ITp2ix{5CVy7&1hmCJ~+k+SY(ZhiyM~+i<Xo&E_F6u
zcb6f|Ni0Uo5`0VXT}S&8u=fSa5a#e5io$rK34uOMh=e9YLKBjUZRNn=WA%5Su-i6^
zhux4+*bT`|)WM-4!jOq*s4_AR64mlepVdDkPk*TX-TFHaTUrE*X8}lT**OpwJj*MQ
ztrqI%^C4>NAsQ>J`upn7*GJ-(xag_+yXrU9|9bPP`p4>jZ0ICl;L|yQ6in(UtiSXM
zSb*A55aLs3<MaQ63LjI0A?zW~2x(j$f-aPWgM{wri0nejBA^mg3v)FTComDGfg@;p
zlFBiA5=?~93Pyr*f#D<kT-}bEAK`ljpC2_pQ<vfQUsZ<Re~IJgr_f2@&w5}&ZW@fS
zIE*pU*z?+nhxY75BimD6gQ(G4WPbvq`kcWY8OAO6BOGozhjY~Yry=}~1y1}sjXIG=
z<)X<{Oyo$y<xqx~f|XJ;Dtjq((o1TS{I)8U`@LWVYy|42+CW((ld(MB;}{YOBk{t1
zPM$nb&Y^N<E`kGohBby`Qmy`rsmWACzSZec4O4R>K4a)}2o1Pfz(A;-#Iv+v9Mg;F
zOIn?F(a^tzPTzvFXZrm-K71Q3VhTA>li4OXdP}Dq_U;$N=C%7$^7N;W+jp<LaE10>
zUh`wY0p`zHo0pME>Dku{GtD;Vte_KyW%ExovH7`+?XZ2m=HKSjEF8h1hpYAr-sYbe
zLIQm0+xMm6@G>O{qmWLAwW|(z-om#O=iIihlXutgExna*=`Fb}g)_#t^p>w|Dd4cB
zfXi<w`*&=8HOoYH)9KMCu^^%VRV;AQ1s6+mBM+hy9<`-59ucAWJ;Pyuxib+1eTZGe
z=`ZH!AXol6p2lH*DjD4J?Hh%}jsAN%Id2C!9XnaNE?o~t`dFeaz=l*nVN8B!b$z!s
zALZjCDiXzV*&7HOFRHIF1b5tAU7ykXXo?M~fG)Y$y}G_v8;0_U5=c7v&IdTCwz~e@
z-ulQ+prZYd(-N}JU=_IAfb9cOoAaR~B4hx|CflE?8<iZ-_-#`hL5$xZ)EFhtwM08g
z{)+fR7UVHiNaB%(_z0^w&WnhE4hpe)sZYH3LI(1s7U8!yl4j66yjeSy=Lq2sq`dVv
z!AEbhOh`QbbEBz%S*ozz@w~^Yx!PwOnsMmk^H%b9wEdXc8cpcR4ta4Q*m=L%SS~aU
z(;J8HZyX_T_0%R$?dk_RY=gap2u-fzhjz`|12sqNn)ZPj)2=x%P;=U@d1s&|W!L;}
zpyo@v=J$Lh7EPE{h3DN~O>Cd>ao?G>e3ACrXl1<C5dHx0HfC|u-;x{VQ$GYL6sP%C
z6F1&OlW*5WH0&T6%J+}fzA*HUl4i8ajOK&3h8{B`ejc+m^iRlw)<0ss<llY*yHy+U
zMWg9`)_+$TfrcL<&_K6h2=5yDQ4abiX2tt5+3-lY;<e|c7hEs8UxH716g|6?NamEH
z^~tq=;IZIb2O9JgS?gq!AL0{J4EZDM(WTS0(G3$H%LXPhhX<Vb7!+T=bPU`KRFH%D
z5v16N$Rxg~uve~lKB)*6&UlPsUNJDiN5Nuy!h86-v?9B-?vhn@DJ7YBpP~Pmul3I&
z+3_cm=1VZ@Kg-dt#mUz{Y|#1>eErmyR<D#`2*87~C+vBG7tdoa^D}fASf)7bm-%zQ
z_CNS$hD%i;WrzhV>_~aliqxnWg4Hf>%&(<jmK&K;Gc3gX4jP!^L1AZVofI4zvv9BD
zNzygVok!zgF%@>ktWhysL|4W#qhggL_Lw!$EvrhEJ>98ftL4U!;Ht0~lTzBdVJQ}t
zQ&!j&3zwzB?pU}y752o!!%|^yEIcC>E{KI^rox4>@T^pLNGyC+DqIu`&rXGh#=>(_
z;o?~M>QuNS7QQAG4-Zcz{XM}(e_!x^zZYn=h09{Cf(ruc&UYv)x*)6UtW!GewsWN;
z!^2|PQL#*y6&}%@%Hr15LNLs3Ec@C<yXP6q@Xn|d0EdHq7=N7yH7|x|#%#U?bG+7;
z<J<5IyRyT9U2Dr-afWB*AWH$6ztBW`c$8e54G)jOt>2Bk0BY51!<SRtoUa>t_SX%4
z_1_q}f`-8lT*jZ#n5X61{r&i0-UKyL<yY{bMt&i4C|pkW)^s7G{S)#QuCcNDUSMqK
zubZ2XYc6mU_@OjLCVO3JGFXVc#yYA}V-1LF$l#YfU3;alKh@<;ebFj;!V^J3t@w-Z
z#8#IJU11PNsUzX>u|4Ru$5Hp~cz8l8Jdwu8wm)4X{vx8znAQ^uPfB4%7OYffQ)zmt
z+d`izK+SaQY9dyhoC;5mS!c50$+0_VkCV5rOojbG-V3nsq*w+TC_I7q@E85ldFs~x
zgXz!%?-^p1_+~o(IX96yyNcuRmFXtMEOZzIpET`Bf5y=-3H$jg0LZ@ZH0;ly+3Ri}
zwA85tkwEWW5^CprAb`S?lPPufRD1I5nYDaf-M6nwVSRk&cGdZB88}RR4`<aWmFHD$
z?uDd0=5t#0Ps3AaTe+~yV=?WQK4@WbU2~3d7T#K>9oCVYcU^7Y`~x^thW-HwzC+#k
z`G8#KL(DqzRNWjK5*-yGs~+W%UX8BX2J*NMIXqs26h@DI8YR%yzokHF2qqaUE6Jk!
zW#mZ29G<}KOMY7e0}w_yki@kmU2oF;q-}!&?=G%__Bvk{A(YeH@H(JgZL0S~%~Q&J
z#6D}f%vYptvJ|^uPy}cCKM7v$pBq|W=-uqVj2SZ&;F5yzxgMWpYTuxG#1weluTTdQ
zV-$x~O6^MW2Vi#bD**jVxOi@ionpaaLs*F1Y1Ax&TZvynGle2mpMjYwEM#k8tfpYB
zcB@z0J~!~>kT@q;zy{O!;aVt_^<;g27v1imk6huJy5Z_pPFFp>gCbX`1_6%)j$qc4
z6?_k))8Z8GlhtF>&c|my0`nw2?9t(kBMP~Ozm<#={WfUbs)<R-p5Ruxhswy+pC|nX
z4LxiUn_;}$xLx!Rp>a2g_tHmbNOic@c!*_f8>0N<z6ypg$Gr>}ROrpB{97@ve&J!E
z&DjPb-VG%sKI^~zysFPKA1}9&5%G}2$x*o*OQ7CZ$kRZ_UPF~B-dlrtK?{8Y!^&&K
z1uf7lTS*~d@gUFrCY*K(=VT21J8;}fvQbn0UY<Gt*l6~3XHWHh0i+)6Hls<i3&FAb
z9(UaLwy=JSxZxS+`X{CJEw1$~?)5F6^)22FGYU4WFLXFIw9uRx|M&BAWz~oIJqXPU
zjbZ3&x7mmBFa?qECx(6>T%`riP`80z0}5flkU{&y`B8cMMVf*4-ZrQ;e2J3C3vCX%
zeK6>#!TQ9|AK(_k1KbYy3C}-hTU*mW*ZUAsC4@IJQ14=_dgGQH_&vQ^`1+;|)K}nr
zY0>}PCEuU3_bypz9{cYwf3MXBdBK-KF9Tro05OC;p@?v|PPo_$AeQTAb>ZRc_q44u
zIDcV}z$`3-RljaNENQq}rqzE<FX?aga?9U7j&95^Vyq3U$`nSz0V%+l!4rWNSJyN{
zyB2;Eh4`(mDnpxx0?A8Wn2!R*8F>LdFAphNueb<s0UUZ8GQcMA0NI?}IEH>T0#sQX
zOhuqLB#mI`-=qM*94z`0pV<zsVOo72WX(w)0yXsO`^UOrAoQ(g_+j8-5kt=qPo!~W
z291iFV+Y+8>K5G<!sUW{s=<4rcLi47LoMV%2ko7R!0pJq6Q#q?8DlgRG7F@22+%cs
zk(TYk=3tU8!qGV5@$$zYh73nB7UCDvBOr~0t<Uf+qGr3n5MII3AlZcXaeHn19l0su
zmZALx+D7}BWnOhl+i~->-O-Im$#g?#VWIM_MziEu|3av`Stex9=Knw(B{+h>;mkxF
zt%Vd=2_hPZxDQ8t*HGWCVrUd$CTqAhy#UX~=A{?ncYb;ierwXTXh|$UY-}OEMfhqd
zwlkMCEKV;2z>@U!_+6U50l(L!m!l=I3_#c8y8+*Fb9M7EY!<)T=EU~d7lI+2t%)p%
zC|~|<g1qXCeLa_lfZhW{#Q+5MmB(rFH|U-a1v)r*tAJ}QKo{GQ9y~J;HRs_7Zl<pQ
zQNW5gVVQmFpIo_Xm3?8{e+SZ3jJIM<Lz4(j_MM*neaBu8O3aYPqqZ0WswG^QlKBrd
zXmP3Dd^v8a1^GNfXzAjs;B(NlEiRkDD^K6BUl?U*HS{KA-}=3tm)$KZ<yB2NL=5)}
z5Yx*|mQmV5aI^RuH|@c$KqoF5aG@`TrqH@^Wmv&@GvajGq})1%5WEds$s$B3?E6rw
z-~|!}6p9BGq<yQjA%`Oxga;p&ZcUL5oGg=9owmtMgQLHXf=$@jwQ;cBTtpeZ64$;h
z_by;<?p*-MJ#;Na!Y!2|L`3N>5wdgDP*UNzq|L7lOB<R)0n>;}v83fJ&^eZ`Pze3E
z@s1->Ql7yp6LGr+AFIo3arf^qJt4RZrV>+(ARbrZIODYz#RreaajJ11_%?C&amrgD
z;pQVYhPQZs1>b_DX7M=xasPjT9_RoD#bYsWrM&q%T$_`6^y3W+1y?oLY!p9SfrTSj
zPEji<o(o!OoR$H08Q$7Z%#jBlbB}JMQ%w0Qwgzb}ZuB6~2JV-!)vgSVHlNwbJ#(Cx
zgq>(e3_CqOKX)mgJAZcr$qyVMOAsOsFd({&Wr7R766>KcdXu*X-Pp`!G{;hQ<lpK_
z4dM4N`^w(T1(<#Esv$H2VS(5txXxp^DdIMORk?x(m)}T|$(lp!I7os^gc9Pq{wpQY
zN1!;J>WCmb(B8dAs3{!U#U1f@mF43Vej`)HHij-Ugpur37mUle`jCk_B4w9^j7gxt
zcqL3=n3N7OljxQUVHRYV^{QL&A*@`-_N+7XRTNvqAm9oL#G)C?T$O(e@-~06k$Y%$
z@vDuzz;BXCdXy#2BYQk`AqtoEhm_9XerqXPn~5xirv;cnjc8lKR%Iefc$>_EqrL`W
zF<XV0-X%S0*u^yLVr@IM`Fl*}moA-n5kV~a`iU3O#C97dzJd=jXaLNxkYE;Smw&a9
z=7;f)R*arIIb14(;uJWaif1o)-%%umAfxQ?y00r#2&Ii}sN{ZACB4qAWaNn80TbR8
z(MtrVuzVczUXm0RF0Xh6xMU55wX<==Li4fB+GHTc^LRrDk83L4f$<`|k;ybF-DuG>
zPsB?rObu6J^KxNQ_%&49|MV1s6VLjC3v*ftS{iTLa7uCgTmtchBa4_j2{itO0pgCh
zWQt0T&N%RQ|AC^{QG>6nr*Oj%K=gDpcTYfFAR=<lY0L1Y65~KH<3hp{T1YQx12{&!
ziX=w>PYMK4qxTGMyuag3bI6bjF#H=s3E|u-;OqhAUd%(+i-v1zKG@C?f)O!rv+g7$
z`91r<D*}1h3A%Kr_XLCS=kE<(@$eUoaDVwzlEM}|RD_7PLmAK?EO?!*FKlIyTUgOW
z3&Vm3t!V)NVjF*`CL4c4n@<{2-njlrWmm)AhL@F=)licy4X-GMq(Pr$UiPSE-ynmZ
zYh%H@s00F_b;LmH1ydb9P#Qz6?twD)R$2|rr5o|plc^=usTorp)(@hzt;ndu^7_5Y
z^u6SH(cLw*H-629c0>C=>}Q7d3H#T&@+k8Qu*p7QGacFXFP`rG{HY6{lMrfgst(?}
z7nXxXmZ_!C`&zn5%U${x+O{$ty%AfGB!)7-4!cZSyaW&7@I3iPOu0NXq+i0~iUTk5
OE+=Occa@IUp8UUyqelq<
literal 0
HcmV?d00001
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH 1/3] net: bpf jit: ppc: optimize choose_load_func error path
From: Jan Seiffert @ 2013-10-08 22:50 UTC (permalink / raw)
To: Vladimir Murzin, netdev
Cc: av1474, Benjamin Herrenschmidt, Paul Mackerras, Daniel Borkmann,
Matt Evans
In-Reply-To: <1381249910-17338-1-git-send-email-murzin.v@gmail.com>
Vladimir Murzin schrieb:
> Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
> were not passed. At the same time handlers for "any offset" cases make
> the same checks against r_addr at run-time, that will always lead to
> bpf_error.
>
Hmmm, if i only would remember why i wrote it that way....
I memory serves me right the idea was to always have a solid fall back, no
matter what, to the generic load function which works more like the load_pointer
from filter.c.
This way the COOSE-macro may could have been used at more places, but that
never played out.
And since all i wanted was to get the negative indirect load fixed,
optimizing the constant error case was not on my plate.
That you can get your negative K filter JITed in the first place, even
if the constant error case was slower than necessary, was good enough ;)
The ARM JIT is broken till this date...
You can have my
I'm-OK-with-this: Jan Seiffert <kaffeemonster@googlemail.com>
for all three patches, -ENOTIME for a full review ATM.
> Run-time checks are still necessary for indirect load operations, but
> error path for absolute and mesh loads are worth to optimize during bpf
> compile time.
>
> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
>
> Cc: Jan Seiffert <kaffeemonster@googlemail.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Daniel Borkmann <dborkman@redhat.com>
> Cc: Matt Evans <matt@ozlabs.org>
>
> ---
> arch/powerpc/net/bpf_jit_comp.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index bf56e33..754320a 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -132,7 +132,7 @@ static void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx)
> }
>
> #define CHOOSE_LOAD_FUNC(K, func) \
> - ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
> + ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
>
> /* Assemble the body code between the prologue & epilogue. */
> static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
> @@ -427,6 +427,11 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
> case BPF_S_LD_B_ABS:
> func = CHOOSE_LOAD_FUNC(K, sk_load_byte);
> common_load:
> + if (!func) {
> + PPC_LI(r_ret, 0);
> + PPC_JMP(exit_addr);
> + break;
> + }
> /* Load from [K]. */
> ctx->seen |= SEEN_DATAREF;
> PPC_LI64(r_scratch1, func);
>
--
An UDP packet walks into a
^ permalink raw reply
* RE: [PATCH RFC 63/77] qlcnic: Update MSI/MSI-X interrupts enablement code
From: Himanshu Madhani @ 2013-10-08 22:46 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel
Cc: Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips@linux-mips.org,
linuxppc-dev@lists.ozlabs.org, linux390@de.ibm.com,
linux-s390@vger.kernel.org, x86@kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <c92efbde96541d08f37510422c096d543bb01279.1380703263.git.agordeev@redhat.com>
> -----Original Message-----
> From: Alexander Gordeev [mailto:agordeev@redhat.com]
> Sent: Wednesday, October 02, 2013 3:49 AM
> To: linux-kernel
> Cc: Alexander Gordeev; Bjorn Helgaas; Ralf Baechle; Michael Ellerman;
> Benjamin Herrenschmidt; Martin Schwidefsky; Ingo Molnar; Tejun Heo; Dan
> Williams; Andy King; Jon Mason; Matt Porter; linux-pci; linux-mips@linux-
> mips.org; linuxppc-dev@lists.ozlabs.org; linux390@de.ibm.com; linux-
> s390@vger.kernel.org; x86@kernel.org; linux-ide@vger.kernel.org;
> iss_storagedev@hp.com; linux-nvme@lists.infradead.org; linux-
> rdma@vger.kernel.org; netdev; e1000-devel@lists.sourceforge.net; Dept-
> Eng Linux Driver; Solarflare linux maintainers; VMware, Inc.; linux-scsi
> Subject: [PATCH RFC 63/77] qlcnic: Update MSI/MSI-X interrupts enablement
> code
>
> As result of recent re-design of the MSI/MSI-X interrupts enabling pattern
> this driver has to be updated to use the new technique to obtain a optimal
> number of MSI/MSI-X interrupts required.
>
"We will test this change for the driver and provide feedback."
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Thanks,
Himanshu
^ permalink raw reply
* [PATCH v2 net] pkt_sched: fq: fix non TCP flows pacing
From: Eric Dumazet @ 2013-10-08 22:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Steinar H. Gunderson
In-Reply-To: <1381182269.12191.27.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
Steinar reported FQ pacing was not working for UDP flows.
It looks like the initial sk->sk_pacing_rate value of 0 was
a wrong choice. We should init it to ~0U (unlimited)
Then, TCA_FQ_FLOW_DEFAULT_RATE should be removed because it makes
no real sense. The default rate is really unlimited, and we
need to avoid a zero divide.
Reported-by: Steinar H. Gunderson <sesse@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
I removed the ACCESS_ONCE() stuff, as it adds conflicts for
next (net / net-next) merge. I'll send a separate patch later.
net/core/sock.c | 1 +
net/sched/sch_fq.c | 20 +++++++++-----------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 5b6beba..0b39e7a 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2319,6 +2319,7 @@ void sock_init_data(struct socket *sock, struct sock *sk)
sk->sk_ll_usec = sysctl_net_busy_read;
#endif
+ sk->sk_pacing_rate = ~0U;
/*
* Before updating sk_refcnt, we must commit prior changes to memory
* (Documentation/RCU/rculist_nulls.txt for details)
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index 48501a2..a9dfdda 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -472,20 +472,16 @@ begin:
if (f->credit > 0 || !q->rate_enable)
goto out;
- if (skb->sk && skb->sk->sk_state != TCP_TIME_WAIT) {
- rate = skb->sk->sk_pacing_rate ?: q->flow_default_rate;
+ rate = q->flow_max_rate;
+ if (skb->sk && skb->sk->sk_state != TCP_TIME_WAIT)
+ rate = min(skb->sk->sk_pacing_rate, rate);
- rate = min(rate, q->flow_max_rate);
- } else {
- rate = q->flow_max_rate;
- if (rate == ~0U)
- goto out;
- }
- if (rate) {
+ if (rate != ~0U) {
u32 plen = max(qdisc_pkt_len(skb), q->quantum);
u64 len = (u64)plen * NSEC_PER_SEC;
- do_div(len, rate);
+ if (likely(rate))
+ do_div(len, rate);
/* Since socket rate can change later,
* clamp the delay to 125 ms.
* TODO: maybe segment the too big skb, as in commit
@@ -735,12 +731,14 @@ static int fq_dump(struct Qdisc *sch, struct sk_buff *skb)
if (opts == NULL)
goto nla_put_failure;
+ /* TCA_FQ_FLOW_DEFAULT_RATE is not used anymore,
+ * do not bother giving its value
+ */
if (nla_put_u32(skb, TCA_FQ_PLIMIT, sch->limit) ||
nla_put_u32(skb, TCA_FQ_FLOW_PLIMIT, q->flow_plimit) ||
nla_put_u32(skb, TCA_FQ_QUANTUM, q->quantum) ||
nla_put_u32(skb, TCA_FQ_INITIAL_QUANTUM, q->initial_quantum) ||
nla_put_u32(skb, TCA_FQ_RATE_ENABLE, q->rate_enable) ||
- nla_put_u32(skb, TCA_FQ_FLOW_DEFAULT_RATE, q->flow_default_rate) ||
nla_put_u32(skb, TCA_FQ_FLOW_MAX_RATE, q->flow_max_rate) ||
nla_put_u32(skb, TCA_FQ_BUCKETS_LOG, q->fq_trees_log))
goto nla_put_failure;
^ permalink raw reply related
* Re: [PATCH] pkt_sched: fq: fix non TCP flows pacing
From: Eric Dumazet @ 2013-10-08 21:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sesse
In-Reply-To: <20131008.165318.1392122841162708841.davem@davemloft.net>
On Tue, 2013-10-08 at 16:53 -0400, David Miller wrote:
> Is this meant for net or net-next? It doesn't apply cleanly to the
> former.
Oh right, I need to respin for net tree, sorry for the confusion.
^ permalink raw reply
* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: Stephen Hemminger @ 2013-10-08 21:13 UTC (permalink / raw)
To: David Miller; +Cc: yamato, netdev
In-Reply-To: <20131008.152349.729447337097758010.davem@davemloft.net>
On Tue, 08 Oct 2013 15:23:49 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Masatake YAMATO <yamato@redhat.com>
> Date: Fri, 4 Oct 2013 11:34:21 +0900
>
> > ip link has ability to show extra information of net work device if
> > kernel provides sunh information. With this patch veth driver can
> > provide its peer ifindex information to ip command via netlink
> > interface.
> >
> > Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>
> Applied to net-next, thank you.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Please revert this. It is incorrect.
The info returned by any netlink message should be equal to the message
for setting.
I think the correct patch would be something like this (compile tested only).
--- a/drivers/net/veth.c 2013-10-06 14:48:23.806461177 -0700
+++ b/drivers/net/veth.c 2013-10-08 14:11:42.434074690 -0700
@@ -434,6 +434,35 @@ static const struct nla_policy veth_poli
[VETH_INFO_PEER] = { .len = sizeof(struct ifinfomsg) },
};
+static size_t veth_get_size(const struct net_device *dev)
+{
+ return nla_total_size(sizeof(struct ifinfomsg)) + /* VETH_INFO_PEER */
+ 0;
+}
+
+static int veth_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+ struct veth_priv *priv = netdev_priv(dev);
+ struct net_device *peer = rtnl_dereference(priv->peer);
+
+ if (peer) {
+ struct ifinfomsg ifi = {
+ .ifi_family = AF_UNSPEC,
+ .ifi_type = peer->type,
+ .ifi_index = peer->ifindex,
+ .ifi_flags = dev_get_flags(peer),
+ };
+
+ if (nla_put(skb, VETH_INFO_PEER, sizeof(ifi), &ifi))
+ goto nla_put_failure;
+ }
+
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
static struct rtnl_link_ops veth_link_ops = {
.kind = DRV_NAME,
.priv_size = sizeof(struct veth_priv),
@@ -443,6 +472,8 @@ static struct rtnl_link_ops veth_link_op
.dellink = veth_dellink,
.policy = veth_policy,
.maxtype = VETH_INFO_MAX,
+ .get_size = veth_get_size,
+ .fill_info = veth_fill_info,
};
/*
^ permalink raw reply
* Re: IPv6 kernel warning
From: Yuchung Cheng @ 2013-10-08 20:53 UTC (permalink / raw)
To: dormando
Cc: Michele Baldessari, Russell King - ARM Linux, netdev,
Neal Cardwell, Nandita Dukkipati
In-Reply-To: <alpine.DEB.2.02.1310081123230.21359@dtop>
On Tue, Oct 8, 2013 at 11:24 AM, dormando <dormando@rydia.net> wrote:
> On Mon, 7 Oct 2013, Yuchung Cheng wrote:
>
>> On Mon, Oct 7, 2013 at 12:56 PM, dormando <dormando@rydia.net> wrote:
>> > On Mon, 7 Oct 2013, Yuchung Cheng wrote:
>> >
>> >> On Mon, Oct 7, 2013 at 11:13 AM, dormando <dormando@rydia.net> wrote:
>> >> >
>> >> > > >
>> >> > > > there's been multiple reports about this one:
>> >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=989251
>> >> > > > http://bugzilla.kernel.org/show_bug.cgi?id=60779
>> >> > > >
>> >> > > > Could you try Yuchung's debug patch?
>> >> > > > http://www.spinics.net/lists/netdev/msg250193.html
>> >> > > Yes it looks like the same bug. Please try that patch to help identify
>> >> > > this elusive bug.
>> >> > >
>> >> >
>> >> > Hi!
>> >> >
>> >> > We get this one a few times a day in production. Here's a warning with
>> >> > your debug trace in the line immediately following:
>> >> > (I censored a few things)
>> >> >
>> >> > [125311.721950] ------------[ cut here ]------------
>> >> > [125311.721961] WARNING: at net/ipv4/tcp_input.c:2776 tcp_fastretrans_alert+0xb58/0xc80()
>> >> > [125311.721962] Modules linked in: bridge ip_vs macvlan coretemp crc32_pclmul ghash_clmulni_intel gpio_ich ipmi_watchdog microcode ipmi_devintf sb_edac lpc_ich edac_core mfd_core ipmi_si ipmi_msghandler iptable_nat nf_nat_ipv4 nf_nat ixgbe igb mdio i2c_algo_bit ptp pps_core
>> >> > [125311.721981] CPU: 11 PID: 0 Comm: swapper/11 Not tainted 3.10.13 #1
>> >> > [125311.721982] Hardware name: Supermicro XXXXXXXXXXX, BIOS 1.1 10/03/2012
>> >> > [125311.721984] ffffffff81a82007 ffff88407fc63958 ffffffff816bb9cc ffff88407fc63998
>> >> > [125311.721986] ffffffff8104b940 00ff8840ad904f82 ffff883b8a165b00 0000000000004120
>> >> > [125311.721989] 0000000000000001 0000000000000019 0000000000000000 ffff88407fc639a8
>> >> > [125311.721991] Call Trace:
>> >> > [125311.721992] <IRQ> [<ffffffff816bb9cc>] dump_stack+0x19/0x1d
>> >> > [125311.722002] [<ffffffff8104b940>] warn_slowpath_common+0x70/0xa0
>> >> > [125311.722005] [<ffffffff8104b98a>] warn_slowpath_null+0x1a/0x20
>> >> > [125311.722007] [<ffffffff81616db8>] tcp_fastretrans_alert+0xb58/0xc80
>> >> > [125311.722011] [<ffffffff8161891f>] tcp_ack+0x6df/0xe90
>> >> > [125311.722016] [<ffffffff8164e0ca>] ? ipt_do_table+0x22a/0x680
>> >> > [125311.722018] [<ffffffff816194b3>] ? tcp_validate_incoming+0x63/0x320
>> >> > [125311.722021] [<ffffffff8161a55c>] tcp_rcv_established+0x2cc/0x810
>> >> > [125311.722023] [<ffffffff81622c84>] tcp_v4_do_rcv+0x254/0x4f0
>> >> > [125311.722025] [<ffffffff816245ac>] tcp_v4_rcv+0x5fc/0x750
>> >> > [125311.722027] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
>> >> > [125311.722032] [<ffffffff815df3ad>] ? nf_hook_slow+0x7d/0x160
>> >> > [125311.722034] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
>> >> > [125311.722036] [<ffffffff815fface>] ip_local_deliver_finish+0xce/0x250
>> >> > [125311.722037] [<ffffffff815ffc9c>] ip_local_deliver+0x4c/0x80
>> >> > [125311.722039] [<ffffffff815ff329>] ip_rcv_finish+0x119/0x360
>> >> > [125311.722040] [<ffffffff815ff8e0>] ip_rcv+0x230/0x350
>> >> > [125311.722046] [<ffffffff815b4067>] __netif_receive_skb_core+0x477/0x600
>> >> > [125311.722049] [<ffffffff815b4217>] __netif_receive_skb+0x27/0x70
>> >> > [125311.722051] [<ffffffff815b4354>] process_backlog+0xf4/0x1e0
>> >> > [125311.722053] [<ffffffff815b4b45>] net_rx_action+0xf5/0x250
>> >> > [125311.722056] [<ffffffff81053a5f>] __do_softirq+0xef/0x270
>> >> > [125311.722058] [<ffffffff81053cb5>] irq_exit+0x95/0xa0
>> >> > [125311.722062] [<ffffffff816c8f26>] do_IRQ+0x66/0xe0
>> >> > [125311.722065] [<ffffffff816bf62a>] common_interrupt+0x6a/0x6a
>> >> > [125311.722065] <EOI> [<ffffffff8100abf1>] ? default_idle+0x21/0xc0
>> >> > [125311.722082] [<ffffffff8100a54f>] arch_cpu_idle+0xf/0x20
>> >> > [125311.722086] [<ffffffff8108f353>] cpu_startup_entry+0xb3/0x230
>> >> > [125311.722091] [<ffffffff816b439e>] start_secondary+0x1dc/0x1e3
>> >> > [125311.722093] ---[ end trace e77cd5ba583fcbe9 ]---
>> >> > [125311.722096] 355.355.1.355:22496 F0x4120 S1 s7 IF25+17-1-24f0 ur57 rr3 rt0 um0 hs23120 nxt23120
>> >> >
>> >> > It's been happening with all 3.10 kernels, and the one above is .13 as
>> >> > stated in the trace.
>> >>
>> >> Thanks! could you post the output of `sysctl -a |grep tcp`?
>> >>
>> >> I suspect tcp_process_tlp_ack() should not revert state to Open
>> >> directly, but calling tcp_try_keep_open() instead, similar to all the
>> >> undo processing in the tcp_fastretrans_alert(): after
>> >> tcp_end_cwnd_reduction(), the process (E) falls back to check other
>> >> stats before moving to CA_Open.
>> >>
>> >>
>> >> index 9c62257..9012b42 100644
>> >> --- a/net/ipv4/tcp_input.c
>> >> +++ b/net/ipv4/tcp_input.c
>> >> @@ -3314,7 +3314,7 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack,
>> >> tcp_init_cwnd_reduction(sk, true);
>> >> tcp_set_ca_state(sk, TCP_CA_CWR);
>> >> tcp_end_cwnd_reduction(sk);
>> >> - tcp_set_ca_state(sk, TCP_CA_Open);
>> >> + tcp_try_keep_open(sk);
>> >> NET_INC_STATS_BH(sock_net(sk),
>> >> LINUX_MIB_TCPLOSSPROBERECOVERY);
>> >> }
>> >>
>> >
>> > Should I apply this and see if the warning stops?
>> I'd like to hear what the authors of TLP think. In the mean time could
>> you help us collect more evidence by disabling TLP with
>> sysctl net.ipv4.tcp_early_retrans=2
>> and see if the problem still occurs? (it should not).
>>
>> thanks
>
> Box hasn't had a warning in the last 24ish hours. A neighboring machine
> with the default tcp_early_retrans setting has had 5-6 in the same
> timeframe.
>
> Is this a harmful situation to the socket in any way, or is it just
> informational weirdness?
It should be fairly harmless. The ack that triggers the warning should
set the TCP back to the good (non-Open) state, but it's still good to
get rid of.
^ permalink raw reply
* Re: [PATCH] qlcnic: add missing destroy_workqueue() on error path in qlcnic_probe()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: weiyj.lk
Cc: himanshu.madhani, rajesh.borundia, shahed.shaikh,
jitendra.kalsaria, sony.chacko, sucheta.chakraborty, yongjun_wei,
linux-driver, netdev
In-Reply-To: <CAPgLHd9oA08=1o_DWE0SGeg_7nokr3-WPEAOrG71bYg2C1676A@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Tue, 8 Oct 2013 11:32:17 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Add the missing destroy_workqueue() before return from
> qlcnic_probe() in the error handling case.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] sh_eth: NAPI requires netif_receive_skb()
From: Sergei Shtylyov @ 2013-10-08 21:52 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: David Miller, netdev, nobuhiro.iwamatsu.yj, linux-sh
In-Reply-To: <Pine.LNX.4.64.1309261751200.11968@axis700.grange>
Hello.
On 26-09-2013 18:12, Guennadi Liakhovetski wrote:
>> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> Date: Tue, 3 Sep 2013 03:03:10 +0400
>>> Driver supporting NAPI should use NAPI-specific function for receiving packets,
>>> so netif_rx() should be changed to netif_receive_skb().
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> This patch breaks NFS boot on Armadillo800eva for me. Network
> communication slows down to a crawl with
> net eth0: Receive FIFO Overflow
> nfs: server 192.168.x.y not responding, still trying
> With this patch reverted (e.g. in today's Linus tree snapshot) boot is
> restored.
Guennadi, are you expecting some actions (like looking into what Eric have
suggested) from me? If so, I'm still on vacation, should be back next Tuesday.
I don't think reverting the patch is a Right Thing to do.
> Thanks
> Guennadi
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] moxa: fix the error handling in moxart_mac_probe()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: weiyj.lk
Cc: grant.likely, rob.herring, jg1.han, b.zolnierkie, kyungmin.park,
yongjun_wei, netdev
In-Reply-To: <CAPgLHd95agB+cseQmD4wg50wX_ddyZ0=0VxJ8vAR80ZbcFsMTw@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Tue, 8 Oct 2013 11:19:19 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> This patch fix the error handling in moxart_mac_probe():
> - return -ENOMEM in some memory alloc fail cases
> - add missing free_netdev() in the error handling case
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: fix non TCP flows pacing
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, sesse
In-Reply-To: <1381182269.12191.27.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 07 Oct 2013 14:44:29 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Steinar reported FQ pacing was not working for UDP flows.
>
> It looks like the initial sk->sk_pacing_rate value of 0 was
> a wrong choice. We should init it to ~0U like sk_max_pacing_rate
>
> Then, TCA_FQ_FLOW_DEFAULT_RATE should be removed because it makes
> no real sense. (The default rate is really : ~0U)
>
> While debugging this issue, I realized sk_pacing_rate is shared between
> transport and packet scheduler without locking / barriers :
>
> We should use ACCESS_ONCE() to make sure compiler wont perform
> multiple loads or stores.
>
> Reported-by: Steinar H. Gunderson <sesse@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Is this meant for net or net-next? It doesn't apply cleanly to the
former.
^ permalink raw reply
* Re: [PATCH] net: vlan: fix nlmsg size calculation in vlan_get_size()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: mkl; +Cc: netdev, kernel, kaber
In-Reply-To: <1381180798-26654-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 7 Oct 2013 23:19:58 +0200
> This patch fixes the calculation of the nlmsg size, by adding the missing
> nla_total_size().
>
> Cc: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox