* Re: ipv4_dst_destroy panic regression after 3.10.15
From: dormando @ 2014-01-20 2:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-kernel
In-Reply-To: <1390027758.31367.505.camel@edumazet-glaptop2.roam.corp.google.com>
> On Fri, 2014-01-17 at 17:25 -0800, dormando wrote:
> > Hi,
> >
> > Upgraded a few kernels to the latest 3.10 stable tree while tracking down
> > a rare kernel panic, seems to have introduced a much more frequent kernel
> > panic. Takes anywhere from 4 hours to 2 days to trigger:
> >
> > <4>[196727.311203] general protection fault: 0000 [#1] SMP
> > <4>[196727.311224] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode ipmi_watchdog ipmi_devintf sb_edac edac_core lpc_ich mfd_core tpm_tis tpm tpm_bios ipmi_si ipmi_msghandler isci igb libsas i2c_algo_bit ixgbe ptp pps_core mdio
> > <4>[196727.311333] CPU: 17 PID: 0 Comm: swapper/17 Not tainted 3.10.26 #1
> > <4>[196727.311344] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
> > <4>[196727.311364] task: ffff885e6f069700 ti: ffff885e6f072000 task.ti: ffff885e6f072000
> > <4>[196727.311377] RIP: 0010:[<ffffffff815f8c7f>] [<ffffffff815f8c7f>] ipv4_dst_destroy+0x4f/0x80
> > <4>[196727.311399] RSP: 0018:ffff885effd23a70 EFLAGS: 00010282
> > <4>[196727.311409] RAX: dead000000200200 RBX: ffff8854c398ecc0 RCX: 0000000000000040
> > <4>[196727.311423] RDX: dead000000100100 RSI: dead000000100100 RDI: dead000000200200
> > <4>[196727.311437] RBP: ffff885effd23a80 R08: ffffffff815fd9e0 R09: ffff885d5a590800
> > <4>[196727.311451] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > <4>[196727.311464] R13: ffffffff81c8c280 R14: 0000000000000000 R15: ffff880e85ee16ce
> > <4>[196727.311510] FS: 0000000000000000(0000) GS:ffff885effd20000(0000) knlGS:0000000000000000
> > <4>[196727.311554] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > <4>[196727.311581] CR2: 00007a46751eb000 CR3: 0000005e65688000 CR4: 00000000000407e0
> > <4>[196727.311625] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > <4>[196727.311669] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > <4>[196727.311713] Stack:
> > <4>[196727.311733] ffff8854c398ecc0 ffff8854c398ecc0 ffff885effd23ab0 ffffffff815b7f42
> > <4>[196727.311784] ffff88be6595bc00 ffff8854c398ecc0 0000000000000000 ffff8854c398ecc0
> > <4>[196727.311834] ffff885effd23ad0 ffffffff815b86c6 ffff885d5a590800 ffff8816827821c0
> > <4>[196727.311885] Call Trace:
> > <4>[196727.311907] <IRQ>
> > <4>[196727.311912] [<ffffffff815b7f42>] dst_destroy+0x32/0xe0
> > <4>[196727.311959] [<ffffffff815b86c6>] dst_release+0x56/0x80
> > <4>[196727.311986] [<ffffffff81620bd5>] tcp_v4_do_rcv+0x2a5/0x4a0
> > <4>[196727.312013] [<ffffffff81622b5a>] tcp_v4_rcv+0x7da/0x820
> > <4>[196727.312041] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
> > <4>[196727.312070] [<ffffffff815de02d>] ? nf_hook_slow+0x7d/0x150
> > <4>[196727.312097] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
> > <4>[196727.312125] [<ffffffff815fda92>] ip_local_deliver_finish+0xb2/0x230
> > <4>[196727.312154] [<ffffffff815fdd9a>] ip_local_deliver+0x4a/0x90
> > <4>[196727.312183] [<ffffffff815fd799>] ip_rcv_finish+0x119/0x360
> > <4>[196727.312212] [<ffffffff815fe00b>] ip_rcv+0x22b/0x340
> > <4>[196727.312242] [<ffffffffa0339680>] ? macvlan_broadcast+0x160/0x160 [macvlan]
> > <4>[196727.312275] [<ffffffff815b0c62>] __netif_receive_skb_core+0x512/0x640
> > <4>[196727.312308] [<ffffffff811427fb>] ? kmem_cache_alloc+0x13b/0x150
> > <4>[196727.312338] [<ffffffff815b0db1>] __netif_receive_skb+0x21/0x70
> > <4>[196727.312368] [<ffffffff815b0fa1>] netif_receive_skb+0x31/0xa0
> > <4>[196727.312397] [<ffffffff815b1ae8>] napi_gro_receive+0xe8/0x140
> > <4>[196727.312433] [<ffffffffa00274f1>] ixgbe_poll+0x551/0x11f0 [ixgbe]
> > <4>[196727.312463] [<ffffffff815fe00b>] ? ip_rcv+0x22b/0x340
> > <4>[196727.312491] [<ffffffff815b1691>] net_rx_action+0x111/0x210
> > <4>[196727.312521] [<ffffffff815b0db1>] ? __netif_receive_skb+0x21/0x70
> > <4>[196727.312552] [<ffffffff810519d0>] __do_softirq+0xd0/0x270
> > <4>[196727.312583] [<ffffffff816cef3c>] call_softirq+0x1c/0x30
> > <4>[196727.312613] [<ffffffff81004205>] do_softirq+0x55/0x90
> > <4>[196727.312640] [<ffffffff81051c85>] irq_exit+0x55/0x60
> > <4>[196727.312668] [<ffffffff816cf5c3>] do_IRQ+0x63/0xe0
> > <4>[196727.312696] [<ffffffff816c5aaa>] common_interrupt+0x6a/0x6a
> > <4>[196727.312722] <EOI>
> > <4>[196727.312727] [<ffffffff8100a150>] ? default_idle+0x20/0xe0
> > <4>[196727.312775] [<ffffffff8100a8ff>] arch_cpu_idle+0xf/0x20
> > <4>[196727.312803] [<ffffffff8108d330>] cpu_startup_entry+0xc0/0x270
> > <4>[196727.312833] [<ffffffff816b276e>] start_secondary+0x1f9/0x200
> > <4>[196727.312860] Code: 4a 9f e9 81 e8 13 cb 0c 00 48 8b 93 b0 00 00 00 48 bf 00 02 20 00 00 00 ad de 48 8b 83 b8 00 00 00 48 be 00 01 10 00 00 00 ad de <48> 89 42 08 48 89 10 48 89 bb b8 00 00 00 48 c7 c7 4a 9f e9 81
> > <1>[196727.313071] RIP [<ffffffff815f8c7f>] ipv4_dst_destroy+0x4f/0x80
> > <4>[196727.313100] RSP <ffff885effd23a70>
> > <4>[196727.313377] ---[ end trace 64b3f14fae0f2e29 ]---
> > <0>[196727.380908] Kernel panic - not syncing: Fatal exception in interrupt
> >
> >
> > ... bisecting it's going to be a pain... I tried eyeballing the diffs and
> > am trying a revert or two.
> >
> > We've hit it in .25, .26 so far. I have .27 running but not sure if it
> > crashed, so the change exists between .15 and .25.
>
> Please try following fix, thanks for the report !
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 25071b48921c..78a50a22298a 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1333,7 +1333,7 @@ static void ipv4_dst_destroy(struct dst_entry
> *dst)
>
> if (!list_empty(&rt->rt_uncached)) {
> spin_lock_bh(&rt_uncached_lock);
> - list_del(&rt->rt_uncached);
> + list_del_init(&rt->rt_uncached);
> spin_unlock_bh(&rt_uncached_lock);
> }
> }
This one crashed after a day and a half with a new-to-me trace. The other
machine running 3.10.27 + the reversion of the other patch is still going.
I now have two machines on that kernel to see if they're stable for more
than two days.
Panic#2 Part1
<4>[116124.368440] ------------[ cut here ]------------
<4>[116124.368450] WARNING: at net/core/dst.c:276 dst_release+0x7e/0x80()
<4>[116124.368451] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich isci ipmi_watchdog ipmi_devintf ixgbe microcode igb sb_edac edac_core libsas lpc_ich i2c_algo_bit mfd_core ptp pps_core tpm_tis mdio tpm tpm_bios ipmi_si ipmi_msghandler
<4>[116124.368470] CPU: 1 PID: 166084 Comm: cache-worker Tainted: G W 3.10.27 #1
<4>[116124.368471] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[116124.368473] ffffffff81a86f96 ffff885effc23b30 ffffffff816c045e ffff885effc23b70
<4>[116124.368475] ffffffff81049930 ffff88be64ed4000 ffff88531e227980 00000000fffffff9
<4>[116124.368477] ffffffff81c876c0 ffff8852ef21ec00 ffff882dffaaa5e2 ffff885effc23b80
<4>[116124.368479] Call Trace:
<4>[116124.368480] <IRQ> [<ffffffff816c045e>] dump_stack+0x19/0x1b
<4>[116124.368490] [<ffffffff81049930>] warn_slowpath_common+0x70/0xa0
<4>[116124.368492] [<ffffffff8104997a>] warn_slowpath_null+0x1a/0x20
<4>[116124.368494] [<ffffffff815b870e>] dst_release+0x7e/0x80
<4>[116124.368497] [<ffffffff816351f9>] inet_sock_destruct+0x129/0x1d0
<4>[116124.368500] [<ffffffff8159d4bd>] __sk_free+0x1d/0x140
<4>[116124.368502] [<ffffffff8159d675>] sk_free+0x25/0x30
<4>[116124.368506] [<ffffffff8161e3fd>] sock_put+0x1d/0x30
<4>[116124.368508] [<ffffffff81622afb>] tcp_v4_rcv+0x77b/0x820
<4>[116124.368511] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
<4>[116124.368515] [<ffffffff815de03d>] ? nf_hook_slow+0x7d/0x150
<4>[116124.368517] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
<4>[116124.368519] [<ffffffff815fda92>] ip_local_deliver_finish+0xb2/0x230
<4>[116124.368521] [<ffffffff815fdd9a>] ip_local_deliver+0x4a/0x90
<4>[116124.368523] [<ffffffff815fd799>] ip_rcv_finish+0x119/0x360
<4>[116124.368526] [<ffffffff815fe00b>] ip_rcv+0x22b/0x340
<4>[116124.368529] [<ffffffff815b0c82>] __netif_receive_skb_core+0x512/0x640
<4>[116124.368531] [<ffffffff815b0dd1>] __netif_receive_skb+0x21/0x70
<4>[116124.368533] [<ffffffff815b0ebb>] process_backlog+0x9b/0x170
<4>[116124.368535] [<ffffffff815b16b1>] net_rx_action+0x111/0x210
<4>[116124.368538] [<ffffffff810519d0>] __do_softirq+0xd0/0x270
<4>[116124.368542] [<ffffffff816cf03c>] call_softirq+0x1c/0x30
<4>[116124.368546] [<ffffffff81004215>] do_softirq+0x55/0x90
<4>[116124.368548] [<ffffffff81051c85>] irq_exit+0x55/0x60
<4>[116124.368550] [<ffffffff816cf6c3>] do_IRQ+0x63/0xe0
<4>[116124.368553] [<ffffffff816c5baa>] common_interrupt+0x6a/0x6a
<4>[116124.368554] <EOI> [<ffffffff816cde02>] ? system_call_fastpath+0x16/0x1b
<4>[116124.368558] ---[ end trace 3ed2370f32f77a53 ]---
<7>[116125.177470] Peer 88.153.144.82:50962/80 unexpectedly shrunk window 2770172661:2770430920 (repaired)
<7>[116127.452869] Peer 88.153.144.82:50962/80 unexpectedly shrunk window 2770172661:2770430920 (repaired)
<7>[116132.003660] Peer 88.153.144.82:50962/80 unexpectedly shrunk window 2770172661:2770430920 (repaired)
<4>[116133.987013] general protection fault: 0000 [#1] SMP
<4>[116133.987033] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich isci ipmi_watchdog ipmi_devintf ixgbe microcode igb sb_edac edac_core libsas lpc_ich i2c_algo_bit mfd_core ptp pps_core tpm_tis mdio tpm tpm_bios ipmi_si ipmi_msghandler
<4>[116133.987137] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G W 3.10.27 #1
<4>[116133.987150] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[116133.987168] task: ffff885e6f7edc00 ti: ffff885e6f7f4000 task.ti: ffff885e6f7f4000
<4>[116133.987182] RIP: 0010:[<ffffffff8164f120>] [<ffffffff8164f120>] iptable_raw_hook+0x20/0x70
<4>[116133.987202] RSP: 0018:ffff885effca38f0 EFLAGS: 00010246
<4>[116133.987212] RAX: ffca3aa0ffff885e RBX: ffca3aa0ffff885e RCX: ffca3aa0ffff885e
<4>[116133.987226] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff885e3b447100
<4>[116133.987240] RBP: ffff885effca38f0 R08: ffff884b3183fc00 R09: ffff885e3b447100
<4>[116133.987254] R10: ffff88be6df7be80 R11: 0000000000000013 R12: ffff885effca3990
<4>[116133.987285] R13: 0000000000000000 R14: 0000000000000003 R15: ffff885e3b447100
<4>[116133.987328] FS: 0000000000000000(0000) GS:ffff885effca0000(0000) knlGS:0000000000000000
<4>[116133.987372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[116133.987399] CR2: 00007a306991d000 CR3: 0000005e0e44f000 CR4: 00000000000407e0
<4>[116133.987441] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[116133.987484] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[116133.987526] Stack:
<4>[116133.987546] ffff885effca3950 ffffffff815ddf7f ffff885effca3910 ffffffff81cb4c90
<4>[116133.987596] ffff885effca3930 ffff885e66024f30 0000000000000020 ffff885e3b447100
<4>[116133.987645] ffffffff81600e90 0000000000000003 ffff885e3b447100 0000000000000000
<4>[116133.987695] Call Trace:
<4>[116133.987716] <IRQ>
<4>[116133.987721] [<ffffffff815ddf7f>] nf_iterate+0x8f/0xd0
<4>[116133.987770] [<ffffffff81600e90>] ? ip_forward_options+0x200/0x200
<4>[116133.987798] [<ffffffff815de03d>] nf_hook_slow+0x7d/0x150
<4>[116133.987825] [<ffffffff81600e90>] ? ip_forward_options+0x200/0x200
<4>[116133.987853] [<ffffffff81602c22>] __ip_local_out+0x72/0x80
<4>[116133.987880] [<ffffffff81602c46>] ip_local_out+0x16/0x30
<4>[116133.987906] [<ffffffff81603f39>] ip_send_skb+0x19/0x50
<4>[116133.987932] [<ffffffff81603fa7>] ip_push_pending_frames+0x37/0x40
<4>[116133.987960] [<ffffffff8160438f>] ip_send_unicast_reply+0x29f/0x2f0
<4>[116133.987989] [<ffffffff8161a5b6>] ? tcp_write_xmit+0x2b6/0xa90
<4>[116133.988019] [<ffffffff8161e2ba>] tcp_v4_send_ack+0x1ba/0x210
<4>[116133.988048] [<ffffffff816226f5>] tcp_v4_rcv+0x375/0x820
<4>[116133.988075] [<ffffffff815de03d>] ? nf_hook_slow+0x7d/0x150
<4>[116133.988103] [<ffffffff815fd9e0>] ? ip_rcv_finish+0x360/0x360
<4>[116133.988131] [<ffffffff815fda92>] ip_local_deliver_finish+0xb2/0x230
<4>[116133.988159] [<ffffffff815fdd9a>] ip_local_deliver+0x4a/0x90
<4>[116133.988187] [<ffffffff815fd799>] ip_rcv_finish+0x119/0x360
<4>[116133.988214] [<ffffffff815fe00b>] ip_rcv+0x22b/0x340
<4>[116133.988242] [<ffffffff815b0c82>] __netif_receive_skb_core+0x512/0x640
<4>[116133.988272] [<ffffffff81079b00>] ? resched_task+0x60/0x70
<4>[116133.988299] [<ffffffff815b0dd1>] __netif_receive_skb+0x21/0x70
<4>[116133.988326] [<ffffffff815b0ebb>] process_backlog+0x9b/0x170
<4>[116133.988354] [<ffffffff8107a1a6>] ? ttwu_do_activate.constprop.91+0x66/0x70
<4>[116133.988384] [<ffffffff815b16b1>] net_rx_action+0x111/0x210
<4>[116133.988412] [<ffffffff810519d0>] __do_softirq+0xd0/0x270
<4>[116133.988441] [<ffffffff816cf03c>] call_softirq+0x1c/0x30
<4>[116133.988470] [<ffffffff81004215>] do_softirq+0x55/0x90
<4>[116133.988495] [<ffffffff81051c85>] irq_exit+0x55/0x60
<4>[116133.988521] [<ffffffff816cf6c3>] do_IRQ+0x63/0xe0
<4>[116133.988548] [<ffffffff816c5baa>] common_interrupt+0x6a/0x6a
<4>[116133.988574] <EOI>
<4>[116133.988578] [<ffffffff8100a160>] ? default_idle+0x20/0xe0
<4>[116133.988624] [<ffffffff8100a90f>] arch_cpu_idle+0xf/0x20
<4>[116133.988652] [<ffffffff8108d330>] cpu_startup_entry+0xc0/0x270
<4>[116133.988681] [<ffffffff816b288e>] start_secondary+0x1f9/0x200
<4>[116133.988708] Code: eb f2 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 83 ff 03 49 89 f1 48 89 e5 74 27 48 85 d2 48 89 d0 89 fe 48 0f 44 c1 4c 89 cf <48> 8b 80 e8 03 00 00 4c 8b 80 50 03 00 00 e8 6d d8 ff ff 5d c3
<1>[116133.988905] RIP [<ffffffff8164f120>] iptable_raw_hook+0x20/0x70
<4>[116133.988934] RSP <ffff885effca38f0>
<4>[116133.989217] ---[ end trace 3ed2370f32f77a54 ]---
<0>[116134.851050] Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* [PATCH 2/2] net/cxgb4: Don't retrieve stats during recovery
From: Gavin Shan @ 2014-01-20 3:05 UTC (permalink / raw)
To: netdev; +Cc: dm, Gavin Shan
In-Reply-To: <1390187144-15495-1-git-send-email-shangw@linux.vnet.ibm.com>
We possiblly retrieve the adapter's statistics during EEH recovery
and that should be disallowed. Otherwise, it would possibly incur
replicate EEH error and EEH recovery is going to fail eventually.
The patch checks if the PCI device is off-line before statistic
retrieval.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index c8eafbf..b0e72fb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4288,6 +4288,17 @@ static struct rtnl_link_stats64 *cxgb_get_stats(struct net_device *dev,
struct port_info *p = netdev_priv(dev);
struct adapter *adapter = p->adapter;
+ /*
+ * We possibly retrieve the statistics while the PCI
+ * device is off-line. That would cause the recovery
+ * on off-lined PCI device going to fail. So it's
+ * reasonable to block it during the recovery period.
+ */
+ if (pci_channel_offline(adapter->pdev)) {
+ memset(ns, 0, sizeof(*ns));
+ return ns;
+ }
+
spin_lock(&adapter->stats_lock);
t4_get_port_stats(adapter, p->tx_chan, &stats);
spin_unlock(&adapter->stats_lock);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] net/cxgb4: Avoid disabling PCI device for towice
From: Gavin Shan @ 2014-01-20 3:05 UTC (permalink / raw)
To: netdev; +Cc: dm, Gavin Shan
If we have EEH error happens to the adapter and we have to remove
it from the system for some reasons (e.g. more than 5 EEH errors
detected from the device in last hour), the adapter will be disabled
for towice separately by eeh_err_detected() and remove_one(), which
will incur following unexpected backtrace. The patch tries to avoid
it.
WARNING: at drivers/pci/pci.c:1431
CPU: 12 PID: 121 Comm: eehd Not tainted 3.13.0-rc7+ #1
task: c0000001823a3780 ti: c00000018240c000 task.ti: c00000018240c000
NIP: c0000000003c1e40 LR: c0000000003c1e3c CTR: 0000000001764c5c
REGS: c00000018240f470 TRAP: 0700 Not tainted (3.13.0-rc7+)
MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28000024 XER: 00000004
CFAR: c000000000706528 SOFTE: 1
GPR00: c0000000003c1e3c c00000018240f6f0 c0000000010fe1f8 0000000000000035
GPR04: 0000000000000000 0000000000000000 00000000003ae509 0000000000000000
GPR08: 000000000000346f 0000000000000000 0000000000000000 0000000000003fef
GPR12: 0000000028000022 c00000000ec93000 c0000000000c11b0 c000000184ac3e40
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000000 c0000000009398d8 c00000000101f9c0 c0000001860ae000
GPR28: c000000182ba0000 00000000000001f0 c0000001860ae6f8 c0000001860ae000
NIP [c0000000003c1e40] .pci_disable_device+0xd0/0xf0
LR [c0000000003c1e3c] .pci_disable_device+0xcc/0xf0
Call Trace:
[c0000000003c1e3c] .pci_disable_device+0xcc/0xf0 (unreliable)
[d0000000073881c4] .remove_one+0x174/0x320 [cxgb4]
[c0000000003c57e0] .pci_device_remove+0x60/0x100
[c00000000046396c] .__device_release_driver+0x9c/0x120
[c000000000463a20] .device_release_driver+0x30/0x60
[c0000000003bcdb4] .pci_stop_bus_device+0x94/0xd0
[c0000000003bcf48] .pci_stop_and_remove_bus_device+0x18/0x30
[c00000000003f548] .pcibios_remove_pci_devices+0xa8/0x140
[c000000000035c00] .eeh_handle_normal_event+0xa0/0x3c0
[c000000000035f50] .eeh_handle_event+0x30/0x2b0
[c0000000000362c4] .eeh_event_handler+0xf4/0x1b0
[c0000000000c12b8] .kthread+0x108/0x130
[c00000000000a168] .ret_from_kernel_thread+0x5c/0x74
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 5 +++--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 23 ++++++++++++++++++-----
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 56e0415..b4ca0a1 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -387,8 +387,9 @@ struct work_struct;
enum { /* adapter flags */
FULL_INIT_DONE = (1 << 0),
- USING_MSI = (1 << 1),
- USING_MSIX = (1 << 2),
+ DEV_ENABLED = (1 << 1),
+ USING_MSI = (1 << 2),
+ USING_MSIX = (1 << 3),
FW_OK = (1 << 4),
RSS_TNLALLLOOKUP = (1 << 5),
USING_SOFT_PARAMS = (1 << 6),
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index fff02ed..c8eafbf 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -5505,7 +5505,10 @@ static pci_ers_result_t eeh_err_detected(struct pci_dev *pdev,
if (adap->flags & FULL_INIT_DONE)
cxgb_down(adap);
rtnl_unlock();
- pci_disable_device(pdev);
+ if ((adap->flags & DEV_ENABLED)) {
+ pci_disable_device(pdev);
+ adap->flags &= ~DEV_ENABLED;
+ }
out: return state == pci_channel_io_perm_failure ?
PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_NEED_RESET;
}
@@ -5522,9 +5525,13 @@ static pci_ers_result_t eeh_slot_reset(struct pci_dev *pdev)
return PCI_ERS_RESULT_RECOVERED;
}
- if (pci_enable_device(pdev)) {
- dev_err(&pdev->dev, "cannot reenable PCI device after reset\n");
- return PCI_ERS_RESULT_DISCONNECT;
+ if (!(adap->flags & DEV_ENABLED)) {
+ if (pci_enable_device(pdev)) {
+ dev_err(&pdev->dev, "Cannot reenable PCI "
+ "device after reset\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ adap->flags |= DEV_ENABLED;
}
pci_set_master(pdev);
@@ -5910,6 +5917,9 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
goto out_disable_device;
}
+ /* PCI device has been enabled */
+ adapter->flags |= DEV_ENABLED;
+
adapter->regs = pci_ioremap_bar(pdev, 0);
if (!adapter->regs) {
dev_err(&pdev->dev, "cannot map device registers\n");
@@ -6145,7 +6155,10 @@ static void remove_one(struct pci_dev *pdev)
iounmap(adapter->bar2);
kfree(adapter);
pci_disable_pcie_error_reporting(pdev);
- pci_disable_device(pdev);
+ if ((adapter->flags & DEV_ENABLED)) {
+ pci_disable_device(pdev);
+ adapter->flags &= ~DEV_ENABLED;
+ }
pci_release_regions(pdev);
} else
pci_release_regions(pdev);
--
1.7.10.4
^ permalink raw reply related
* [PATCH net] tun: handle copy failure in tun_put_user()
From: Jason Wang @ 2014-01-20 3:16 UTC (permalink / raw)
To: davem, netdev, linux-kernel; +Cc: Jason Wang, Michael S. Tsirkin
This patch return the error code of copy helpers in tun_put_user() instead of
ignoring them.
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ecec802..4ec8f28 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1185,7 +1185,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
{
struct tun_pi pi = { 0, skb->protocol };
ssize_t total = 0;
- int vlan_offset = 0, copied;
+ int vlan_offset = 0, copied, ret;
if (!(tun->flags & TUN_NO_PI)) {
if ((len -= sizeof(pi)) < 0)
@@ -1254,7 +1254,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
if (!vlan_tx_tag_present(skb)) {
len = min_t(int, skb->len, len);
} else {
- int copy, ret;
+ int copy;
struct {
__be16 h_vlan_proto;
__be16 h_vlan_TCI;
@@ -1282,13 +1282,13 @@ static ssize_t tun_put_user(struct tun_struct *tun,
goto done;
}
- skb_copy_datagram_const_iovec(skb, vlan_offset, iv, copied, len);
+ ret = skb_copy_datagram_const_iovec(skb, vlan_offset, iv, copied, len);
done:
tun->dev->stats.tx_packets++;
tun->dev->stats.tx_bytes += len;
- return total;
+ return ret ? ret : total;
}
static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
--
1.8.3.2
^ permalink raw reply related
* [PATCH net] net: document accel_priv parameter for __dev_queue_xmit()
From: Jason Wang @ 2014-01-20 3:25 UTC (permalink / raw)
To: davem, netdev, linux-kernel; +Cc: Jason Wang
To silent "make htmldocs" warning.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
net/core/dev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0ce469e..d78dc62 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2781,8 +2781,9 @@ int dev_loopback_xmit(struct sk_buff *skb)
EXPORT_SYMBOL(dev_loopback_xmit);
/**
- * dev_queue_xmit - transmit a buffer
+ * __dev_queue_xmit - transmit a buffer
* @skb: buffer to transmit
+ * @accel_priv: private data used for L2 forwarding offload
*
* Queue a buffer for transmission to a network device. The caller must
* have set the device and priority and built the buffer before calling
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH net] tun: handle copy failure in tun_put_user()
From: David Miller @ 2014-01-20 3:48 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst
In-Reply-To: <1390187808-5462-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Mon, 20 Jan 2014 11:16:48 +0800
> This patch return the error code of copy helpers in tun_put_user() instead of
> ignoring them.
>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
If you perform some of the copy successfully, you have to report that
length rather than just an error.
Otherwise userland has no way to determine how much of the data was
successfully sourced.
I'm not applying this, sorry.
^ permalink raw reply
* Re: [PATCH 2/2] net/cxgb4: Don't retrieve stats during recovery
From: Ben Hutchings @ 2014-01-20 3:49 UTC (permalink / raw)
To: Gavin Shan; +Cc: netdev, dm
In-Reply-To: <1390187144-15495-2-git-send-email-shangw@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]
On Mon, 2014-01-20 at 11:05 +0800, Gavin Shan wrote:
> We possiblly retrieve the adapter's statistics during EEH recovery
> and that should be disallowed. Otherwise, it would possibly incur
> replicate EEH error and EEH recovery is going to fail eventually.
> The patch checks if the PCI device is off-line before statistic
> retrieval.
>
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> ---
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> index c8eafbf..b0e72fb 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> @@ -4288,6 +4288,17 @@ static struct rtnl_link_stats64 *cxgb_get_stats(struct net_device *dev,
> struct port_info *p = netdev_priv(dev);
> struct adapter *adapter = p->adapter;
>
> + /*
> + * We possibly retrieve the statistics while the PCI
> + * device is off-line. That would cause the recovery
> + * on off-lined PCI device going to fail. So it's
> + * reasonable to block it during the recovery period.
> + */
> + if (pci_channel_offline(adapter->pdev)) {
> + memset(ns, 0, sizeof(*ns));
> + return ns;
> + }
The buffer is already zero-initialised so there's no need for this
memset().
> spin_lock(&adapter->stats_lock);
> t4_get_port_stats(adapter, p->tx_chan, &stats);
> spin_unlock(&adapter->stats_lock);
Is there anything to stop this running just after pci_channel_offline()
becomes true?
Ben.
--
Ben Hutchings
One of the nice things about standards is that there are so many of them.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: document accel_priv parameter for __dev_queue_xmit()
From: David Miller @ 2014-01-20 3:49 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel
In-Reply-To: <1390188313-9275-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Mon, 20 Jan 2014 11:25:13 +0800
> To silent "make htmldocs" warning.
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
This is certainly not such a catastrophic error that it should be
targetted at the 'net' tree.
^ permalink raw reply
* [PATCH] ipv6: udp: check sk->sk_no_check when sending udpv6 packet
From: Duan Jiong @ 2014-01-20 3:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev
According to the user's intention, if SO_NO_CHECK option is
set to true, the udpv6 packet should be out with no checksum.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
net/ipv6/udp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 089c741..8808c69 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1001,6 +1001,10 @@ static int udp_v6_push_pending_frames(struct sock *sk)
if (is_udplite)
csum = udplite_csum_outgoing(sk, skb);
+ else if (sk->sk_no_check == UDP_CSUM_NOXMIT) {
+ skb->ip_summed = CHECKSUM_NONE;
+ goto send;
+ }
else if (skb->ip_summed == CHECKSUM_PARTIAL) { /* UDP hardware csum */
udp6_hwcsum_outgoing(sk, skb, &fl6->saddr, &fl6->daddr,
up->len);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next] ipv6: make IPV6_RECVPKTINFO work for ipv4 datagrams
From: David Miller @ 2014-01-20 3:53 UTC (permalink / raw)
To: hannes; +Cc: netdev, gert
In-Reply-To: <20140120024308.GE16462@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon, 20 Jan 2014 03:43:08 +0100
> We currently don't report IPV6_RECVPKTINFO in cmsg access ancillary data
> for IPv4 datagrams on IPv6 sockets.
>
> This patch splits the ip6_datagram_recv_ctl into two functions, one
> which handles both protocol families, AF_INET and AF_INET6, while the
> ip6_datagram_recv_specific_ctl only handles IPv6 cmsg data.
>
> ip6_datagram_recv_*_ctl never reported back any errors, so we can make
> them return void. Also provide a helper for protocols which don't offer dual
> personality to further use ip6_datagram_recv_ctl, which is exported to
> modules.
>
> I needed to shuffle the code for ping around a bit to make it easier to
> implement dual personality for ping ipv6 sockets in future.
>
> Reported-by: Gert Doering <gert@space.net>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: udp: check sk->sk_no_check when sending udpv6 packet
From: David Miller @ 2014-01-20 3:54 UTC (permalink / raw)
To: duanj.fnst; +Cc: netdev
In-Reply-To: <52DC9D25.9070809@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Mon, 20 Jan 2014 11:51:01 +0800
> According to the user's intention, if SO_NO_CHECK option is
> set to true, the udpv6 packet should be out with no checksum.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
This is intentionally not supported in ipv6.
^ permalink raw reply
* Re: [PATCH] ipv6: udp: check sk->sk_no_check when sending udpv6 packet
From: Hannes Frederic Sowa @ 2014-01-20 3:54 UTC (permalink / raw)
To: Duan Jiong; +Cc: David Miller, netdev
In-Reply-To: <52DC9D25.9070809@cn.fujitsu.com>
On Mon, Jan 20, 2014 at 11:51:01AM +0800, Duan Jiong wrote:
>
> According to the user's intention, if SO_NO_CHECK option is
> set to true, the udpv6 packet should be out with no checksum.
Nak, UDP checksumming is mandatory when used with IPv6.
Greetings,
Hannes
^ permalink raw reply
* Re: [ PATCH net-next vw] qlcnic: fix sparse warnings
From: David Miller @ 2014-01-20 3:56 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20140119113712.18f75ba9@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sun, 19 Jan 2014 11:37:12 -0800
> From: Fengguang Wu <fengguang.wu@intel.com>
> Subject: [PATCH net-next] qlcnic: fix sparse warnings
>
> Previous patch changed prototypes, but forgot functions.
>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] phy: cleanup 10g code
From: David Miller @ 2014-01-20 3:56 UTC (permalink / raw)
To: stephen; +Cc: afleming, netdev
In-Reply-To: <20140119114820.028fa940@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sun, 19 Jan 2014 11:48:20 -0800
> Code should avoid needless exports, don't export something unless it used.
> Make local functions static and remove unused stubs.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: optimize link local address search
From: David Miller @ 2014-01-20 3:56 UTC (permalink / raw)
To: hannes; +Cc: netdev, brian.haley
In-Reply-To: <20140119205819.GD16462@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sun, 19 Jan 2014 21:58:19 +0100
> ipv6_link_dev_addr sorts newly added addresses by scope in
> ifp->addr_list. Smaller scope addresses are added to the tail of the
> list. Use this fact to iterate in reverse over addr_list and break out
> as soon as a higher scoped one showes up, so we can spare some cycles
> on machines with lot's of addresses.
>
> The ordering of the addresses is not relevant and we are more likely to
> get the eui64 generated address with this change anyway.
>
> Suggested-by: Brian Haley <brian.haley@hp.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sctp: fix missing SCTP mailing list address update
From: David Miller @ 2014-01-20 3:56 UTC (permalink / raw)
To: sakiwit; +Cc: vyasevich, nhorman, linux-sctp, netdev, dborkman
In-Reply-To: <1390170293-15851-1-git-send-email-sakiwit@gmail.com>
From: Jean Sacren <sakiwit@gmail.com>
Date: Sun, 19 Jan 2014 15:24:53 -0700
> The commit 91705c61b5202 ("net: sctp: trivial: update mailing list
> address") updated almost all the SCTP mailing list address from
>
> "lksctp-developers@lists.sourceforge.net"
> to
> "linux-sctp@vger.kernel.org"
>
> except for the one in include/linux/sctp.h file. Fix this way trivial
> one so that all is updated.
>
> Signed-off-by: Jean Sacren <sakiwit@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: document accel_priv parameter for __dev_queue_xmit()
From: David Miller @ 2014-01-20 3:56 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel
In-Reply-To: <1390188313-9275-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Mon, 20 Jan 2014 11:25:13 +0800
> To silent "make htmldocs" warning.
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied to net-next.
^ permalink raw reply
* Re: [Patch net-next] net_sched: act: remove capab from struct tc_action_ops
From: David Miller @ 2014-01-20 3:58 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, jhs
In-Reply-To: <1389829770-811-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 15 Jan 2014 15:49:30 -0800
> It is not actually implemented.
>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, we shouldn't keep something around which was added more than
a decade ago but never actually used.
If we find a use for it, we can add it back.
^ permalink raw reply
* Re: [PATCH net-next v3 0/8] net: stmmac: Add Allwinner A20 GMAC ethernet
From: David Miller @ 2014-01-20 4:03 UTC (permalink / raw)
To: wens-jdAy2FN1RRM
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, peppe.cavallaro-qxv4g6HH51o,
srinivas.kandagatla-qxv4g6HH51o, vapier-aBrp7R+bbdUdnm+yROfE0A,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1389965087-21971-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Date: Fri, 17 Jan 2014 21:24:39 +0800
> This is v3 of the Allwinner A20 GMAC glue layer for stmmac.
> I have split the series into stmmac driver changes for net-next,
> and clock and DT patches for their respective trees.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] [PATCH net-next v2] net: stmmac: fix NULL pointer dereference in stmmac_get_tx_hwtstamp
From: David Miller @ 2014-01-20 4:03 UTC (permalink / raw)
To: damuzi000; +Cc: peppe.cavallaro, netdev, linux-kernel
In-Reply-To: <1389973679-2755-1-git-send-email-damuzi000@gmail.com>
From: Bruce Liu <damuzi000@gmail.com>
Date: Fri, 17 Jan 2014 23:47:59 +0800
> When timestamping is enabled, stmmac_tx_clean will call
> stmmac_get_tx_hwtstamp to get tx TS.
> But the skb can be NULL because the last of its tx_skbuff is NULL
> if this packet frame is filled in more than one descriptors.
>
> To fix the issue, change the code:
> - Store TX skb to the tx_skbuff[] of frame's last segment.
> - Check skb is not NULL in stmmac_get_tx_hwtstamp.
>
> Signed-off-by: Bruce Liu <damuzi000@gmail.com>
Looks a lot better, applied, thanks.
^ permalink raw reply
* Re: [PATCH] DT: net: davinci_emac: "phy-handle" property is actually optional
From: David Miller @ 2014-01-20 4:04 UTC (permalink / raw)
To: sergei.shtylyov
Cc: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree, linux-doc, davinci-linux-open-source
In-Reply-To: <201401170132.14479.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Fri, 17 Jan 2014 01:32:13 +0300
> Though described as required, the "phy-handle" property for the DaVinci EMAC
> binding is actually optional, as the driver will happily function without it,
> assuming 100/FULL link; the property is not specified either in the example
> device node, or in the actual EMAC device nodes for DA850 and AM3517 device
> trees.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v5 0/2] stmmac: fix kernel crashes for jumbo frames
From: David Miller @ 2014-01-20 4:04 UTC (permalink / raw)
To: vbridgers2013-Re5JQEeQqe8AvxtiuMwx3w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
peppe.cavallaro-qxv4g6HH51o, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, dinguyen-EIB2kfCEclfQT0dZR+AlfA,
rayagond-AmucfkJibqKGw+nKnLezzg
In-Reply-To: <1389903026-12064-1-git-send-email-vbridgers2013-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Vince Bridgers <vbridgers2013-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 16 Jan 2014 14:10:24 -0600
> These patches address two kernel crashes seen when using jumbo frames on
> the Synopsys stmmac driver, and adds device tree configurability for the
> maximum mtu. The Synopsys emac fifo sizes can be configured when a logic
> design is synthesized, but does not provide a way for a driver to query the
> exact fifo size.
These patches do not apply to the current net-next tree, please respin.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: fix "queues" uevent between network namespaces
From: David Miller @ 2014-01-20 4:04 UTC (permalink / raw)
To: chenweilong; +Cc: gregkh, netdev
In-Reply-To: <1389864271-24212-1-git-send-email-chenweilong@huawei.com>
From: Chen Weilong <chenweilong@huawei.com>
Date: Thu, 16 Jan 2014 17:24:31 +0800
> From: Weilong Chen <chenweilong@huawei.com>
>
> When I create a new namespace with 'ip netns add net0', or add/remove
> new links in a namespace with 'ip link add/delete type veth', rx/tx
> queues events can be got in all namespaces. That is because rx/tx queue
> ktypes do not have namespace support, and their kobj parents are setted to
> NULL. This patch is to fix it.
>
> Reported-by: Libo Chen <chenlibo@huawei.com>
> Signed-off-by: Libo Chen <chenlibo@huawei.com>
> Signed-off-by: Weilong Chen <chenweilong@huawei.com>
Applied to net-next, thanks.
^ permalink raw reply
* [PATCH net] ipv6: protect protocols not handling ipv4 from v4 connection/bind attempts
From: Hannes Frederic Sowa @ 2014-01-20 4:16 UTC (permalink / raw)
To: netdev
Some ipv6 protocols cannot handle ipv4 addresses, so we must not allow
connecting and binding to them. sendmsg logic does already check msg->name
for this but must trust already connected sockets which could be set up
for connection to ipv4 address family.
Per-socket flag ipv6only is of no use here, as it is under users control
by setsockopt.
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/net/ipv6.h | 2 ++
net/ipv4/ping.c | 3 +++
net/ipv6/datagram.c | 10 ++++++++++
net/ipv6/ping.c | 2 +-
net/ipv6/raw.c | 6 +++++-
net/l2tp/l2tp_ip6.c | 3 +++
6 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 6d80f51..5b0f1d2 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -782,6 +782,8 @@ int compat_ipv6_getsockopt(struct sock *sk, int level, int optname,
char __user *optval, int __user *optlen);
int ip6_datagram_connect(struct sock *sk, struct sockaddr *addr, int addr_len);
+int ip6_datagram_connect_v6_only(struct sock *sk, struct sockaddr *addr,
+ int addr_len);
int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len,
int *addr_len);
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index e09e883..ba59d6f 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -320,6 +320,9 @@ static int ping_check_bind_addr(struct sock *sk, struct inet_sock *isk,
if (addr_len < sizeof(*addr))
return -EINVAL;
+ if (addr->sin6_family != AF_INET6)
+ return -EINVAL;
+
pr_debug("ping_check_bind_addr(sk=%p,addr=%pI6c,port=%d)\n",
sk, addr->sin6_addr.s6_addr, ntohs(addr->sin6_port));
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index bce73cb..86c705f 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -205,6 +205,16 @@ out:
}
EXPORT_SYMBOL_GPL(ip6_datagram_connect);
+int ip6_datagram_connect_v6_only(struct sock *sk, struct sockaddr *uaddr,
+ int addr_len)
+{
+ DECLARE_SOCKADDR(struct sockaddr_in6 *, sin6, uaddr);
+ if (sin6->sin6_family != AF_INET6)
+ return -EAFNOSUPPORT;
+ return ip6_datagram_connect(sk, uaddr, addr_len);
+}
+EXPORT_SYMBOL_GPL(ip6_datagram_connect_v6_only);
+
void ipv6_icmp_error(struct sock *sk, struct sk_buff *skb, int err,
__be16 port, u32 info, u8 *payload)
{
diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c
index cd71f3a..b19214e 100644
--- a/net/ipv6/ping.c
+++ b/net/ipv6/ping.c
@@ -31,7 +31,7 @@ struct proto pingv6_prot = {
.owner = THIS_MODULE,
.init = ping_init_sock,
.close = ping_close,
- .connect = ip6_datagram_connect,
+ .connect = ip6_datagram_connect_v6_only,
.disconnect = udp_disconnect,
.setsockopt = ipv6_setsockopt,
.getsockopt = ipv6_getsockopt,
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index b452311..1f29996 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -250,6 +250,10 @@ static int rawv6_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
if (addr_len < SIN6_LEN_RFC2133)
return -EINVAL;
+
+ if (addr->sin6_family != AF_INET6)
+ return -EINVAL;
+
addr_type = ipv6_addr_type(&addr->sin6_addr);
/* Raw sockets are IPv6 only */
@@ -1209,7 +1213,7 @@ struct proto rawv6_prot = {
.owner = THIS_MODULE,
.close = rawv6_close,
.destroy = raw6_destroy,
- .connect = ip6_datagram_connect,
+ .connect = ip6_datagram_connect_v6_only,
.disconnect = udp_disconnect,
.ioctl = rawv6_ioctl,
.init = rawv6_init_sk,
diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
index aab5f74..7704ea9 100644
--- a/net/l2tp/l2tp_ip6.c
+++ b/net/l2tp/l2tp_ip6.c
@@ -371,6 +371,9 @@ static int l2tp_ip6_connect(struct sock *sk, struct sockaddr *uaddr,
if (addr_len < sizeof(*lsa))
return -EINVAL;
+ if (usin->sin6_family != AF_INET6)
+ return -EINVAL;
+
addr_type = ipv6_addr_type(&usin->sin6_addr);
if (addr_type & IPV6_ADDR_MULTICAST)
return -EINVAL;
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH net] tun: handle copy failure in tun_put_user()
From: Jason Wang @ 2014-01-20 5:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, mst
In-Reply-To: <20140119.194856.491294439635992592.davem@davemloft.net>
On 01/20/2014 11:48 AM, David Miller wrote:
> From: Jason Wang <jasowang@redhat.com>
> Date: Mon, 20 Jan 2014 11:16:48 +0800
>
>> This patch return the error code of copy helpers in tun_put_user() instead of
>> ignoring them.
>>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> If you perform some of the copy successfully, you have to report that
> length rather than just an error.
>
> Otherwise userland has no way to determine how much of the data was
> successfully sourced.
>
> I'm not applying this, sorry.
Right, looks like we need more changes in tun to return the accurate
length copied in this case.
^ 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