* [PATCH 1/3] ipv6: Prevent unexpected sk->sk_prot changes
From: Ilya Lesokhin @ 2017-08-10 10:33 UTC (permalink / raw)
To: netdev; +Cc: davejwatson, aviadye, Ilya Lesokhin, Boris Pismenny
In-Reply-To: <1502361196-127278-1-git-send-email-ilyal@mellanox.com>
With this patch IPV6 code ensure that only sockets with the
expected sk->sk_prot are converted to IPV4.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
---
net/ipv6/ipv6_sockglue.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 02d795f..318cd344 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -174,6 +174,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
if (val == PF_INET) {
struct ipv6_txoptions *opt;
struct sk_buff *pktopt;
+ struct proto *expected_prot;
if (sk->sk_type == SOCK_RAW)
break;
@@ -199,6 +200,17 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
break;
}
+ if (sk->sk_protocol == IPPROTO_TCP &&
+ sk->sk_prot != &tcpv6_prot)
+ break;
+
+ expected_prot = &udpv6_prot;
+ if (sk->sk_protocol == IPPROTO_UDPLITE)
+ expected_prot = &udplitev6_prot;
+
+ if (sk->sk_prot != expected_prot)
+ break;
+
fl6_free_socklist(sk);
__ipv6_sock_mc_close(sk);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 0/3] tls: Use correct sk->sk_prot for IPV6
From: Ilya Lesokhin @ 2017-08-10 10:33 UTC (permalink / raw)
To: netdev; +Cc: davejwatson, aviadye, Ilya Lesokhin
Fix tls code to use the correct sk->sk_prot for IPV6.
Previously it was tcp_prot of IPV4 was used.
Boris Pismenny (1):
net: Export tcpv6_prot
Ilya Lesokhin (2):
ipv6: Prevent unexpected sk->sk_prot changes
tls: Use correct sk->sk_prot for IPV6
net/ipv6/ipv6_sockglue.c | 12 ++++++++++
net/ipv6/tcp_ipv6.c | 1 +
net/tls/tls_main.c | 61 ++++++++++++++++++++++++++++++++++++++----------
3 files changed, 62 insertions(+), 12 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: Some traffic stress testing with 4.13.0-rc4-next-20170808 and BUG: [61183.212237] BUG: Bad page state in process ksoftirqd/52 pfn:855f2f
From: Paweł Staszewski @ 2017-08-10 10:05 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAM_iQpW908ri7ecz4ThD+fFESQoTvZLu-2Pu6wEtgHwGuca_1w@mail.gmail.com>
Hi
yes there are some stack traces more
enp24s0f3 - this NIC is used only for ssh to the host (not much traffic
on it)
enp216s0f1 - this NIC was have 6Mpps TX traffic (when stack trace occured)
enp216s0f0 - this NIC was have 6Mpps RX traffic (when stack trace occured)
- complete dmesg with stack traces for all nics below:
[53838.303348] NETDEV WATCHDOG: enp24s0f3 (igb): transmit queue 1 timed out
[53838.303358] ------------[ cut here ]------------
[53838.303363] WARNING: CPU: 0 PID: 8 at net/sched/sch_generic.c:316
dev_watchdog+0xc5/0x122
[53838.303363] Modules linked in: sch_fq x86_pkg_temp_thermal ipmi_si
[53838.303367] CPU: 0 PID: 8 Comm: ksoftirqd/0 Not tainted
4.13.0-rc4-next-20170808 #1
[53838.303368] task: ffff88046da39400 task.stack: ffffc900001b8000
[53838.303369] RIP: 0010:dev_watchdog+0xc5/0x122
[53838.303369] RSP: 0018:ffffc900001bbda0 EFLAGS: 00010286
[53838.303370] RAX: 000000000000003c RBX: ffff88046beb6000 RCX:
0000000000000000
[53838.303371] RDX: ffff88046fa13310 RSI: ffff88046fa0ca98 RDI:
ffff88046fa0ca98
[53838.303371] RBP: ffffc900001bbdb0 R08: 0000000000000000 R09:
0000000000000000
[53838.303372] R10: ffff88046fa188e0 R11: ffff88087ff94a84 R12:
0000000000000001
[53838.303372] R13: ffffffff815e0007 R14: ffff88046beb6438 R15:
ffff88046beb6000
[53838.303373] FS: 0000000000000000(0000) GS:ffff88046fa00000(0000)
knlGS:0000000000000000
[53838.303374] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[53838.303374] CR2: 00007ffc18047d58 CR3: 000000046c51f003 CR4:
00000000007606f0
[53838.303375] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[53838.303375] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[53838.303376] PKRU: 55555554
[53838.303376] Call Trace:
[53838.303381] call_timer_fn+0x5b/0x123
[53838.303382] run_timer_softirq+0x137/0x15a
[53838.303386] ? pick_next_task_fair+0x139/0x2f9
[53838.303388] __do_softirq+0xe4/0x23a
[53838.303390] ? sort_range+0x1d/0x1d
[53838.303391] run_ksoftirqd+0x15/0x2a
[53838.303392] smpboot_thread_fn+0x128/0x13f
[53838.303394] kthread+0xf7/0xfc
[53838.303395] ? init_completion+0x24/0x24
[53838.303399] ret_from_fork+0x22/0x30
[53838.303400] Code: 62 68 6e 00 00 75 38 48 89 df c6 05 56 68 6e 00 01
e8 f4 49 fe ff 44 89 e1 48 89 de 48 c7 c7 5b 3d ac 81 48 89 c2 e8 c8 26
a9 ff <0f> ff eb 10 41 ff c4 48 05 40 01 00 00 41 39 f4 75 9a eb 0d 48
[53838.303417] ---[ end trace cf42df41100f38ce ]---
[53838.303555] igb 0000:18:00.3 enp24s0f3: Reset adapter
[53843.119595] igb 0000:18:00.3 enp24s0f3: igb: enp24s0f3 NIC Link is Up
1000 Mbps Full Duplex, Flow Control: RX
[56238.303636] igb 0000:18:00.3 enp24s0f3: Reset adapter
[56241.651735] igb 0000:18:00.3 enp24s0f3: igb: enp24s0f3 NIC Link is Up
1000 Mbps Full Duplex, Flow Control: RX
[59482.865823] nr_pdflush_threads exported in /proc is scheduled for removal
[59697.280051] ------------[ cut here ]------------
[59697.280060] WARNING: CPU: 45 PID: 237 at kernel/rcu/tree.c:2700
rcu_process_callbacks+0x327/0x36f
[59697.280061] Modules linked in: sch_fq x86_pkg_temp_thermal ipmi_si
[59697.280066] CPU: 45 PID: 237 Comm: ksoftirqd/45 Tainted: G
W 4.13.0-rc4-next-20170808 #1
[59697.280067] task: ffff88086d07a800 task.stack: ffffc90003bd4000
[59697.280069] RIP: 0010:rcu_process_callbacks+0x327/0x36f
[59697.280070] RSP: 0018:ffffc90003bd7e00 EFLAGS: 00010097
[59697.280071] RAX: 0000000000000246 RBX: ffff88087fa598c0 RCX:
ffffffffffffd800
[59697.280071] RDX: 0000000000000001 RSI: ffffc90003bd7e18 RDI:
ffff88087fa598f8
[59697.280072] RBP: ffffc90003bd7e60 R08: 0000000000000068 R09:
00000000ffffff80
[59697.280073] R10: ffffc90003bd7dd8 R11: 000000000001cc80 R12:
ffffffff81c423c0
[59697.280073] R13: ffffc90003bd7e18 R14: ffff88087fa598f8 R15:
ffff88086d07a800
[59697.280074] FS: 0000000000000000(0000) GS:ffff88087fa40000(0000)
knlGS:0000000000000000
[59697.280075] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[59697.280075] CR2: 00007fffd1a54000 CR3: 000000086bc53001 CR4:
00000000007606e0
[59697.280076] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[59697.280077] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[59697.280077] PKRU: 55555554
[59697.280078] Call Trace:
[59697.280081] ? net_rx_action+0x21e/0x22d
[59697.280084] __do_softirq+0xe4/0x23a
[59697.280088] ? sort_range+0x1d/0x1d
[59697.280089] run_ksoftirqd+0x15/0x2a
[59697.280090] smpboot_thread_fn+0x128/0x13f
[59697.280093] kthread+0xf7/0xfc
[59697.280094] ? init_completion+0x24/0x24
[59697.280099] ret_from_fork+0x22/0x30
[59697.280100] Code: 8b 8b 90 00 00 00 48 2b 0d 2b 4e bc 00 48 39 ca 7d
07 48 89 93 90 00 00 00 48 83 7b 38 00 0f 94 c1 48 85 d2 0f 94 c2 38 d1
74 02 <0f> ff 50 9d 4c 89 f7 e8 55 22 00 00 84 c0 74 09 e8 06 f1 ff ff
[59697.280120] ---[ end trace cf42df41100f38cf ]---
[59697.280251] BUG: Bad page state in process ksoftirqd/49 pfn:85537d
[59697.280253] page:ffffea002154df40 count:0 mapcount:-1
mapping: (null) index:0xffff88085537db00
[59697.280393] flags: 0x600000000000000()
[59697.280510] raw: 0600000000000000 0000000000000000 ffff88085537db00
00000000fffffffe
[59697.280511] raw: 0000000000000000 0000000100000001 0000000000000000
0000000000000000
[59697.280511] page dumped because: nonzero mapcount
[59697.280512] Modules linked in: sch_fq x86_pkg_temp_thermal ipmi_si
[59697.280515] CPU: 49 PID: 257 Comm: ksoftirqd/49 Tainted: G
W 4.13.0-rc4-next-20170808 #1
[59697.280516] Call Trace:
[59697.280521] dump_stack+0x4d/0x63
[59697.280526] bad_page+0xf3/0x10f
[59697.280528] check_new_page_bad+0x73/0x75
[59697.280529] get_page_from_freelist+0x419/0x63f
[59697.280532] ? ip_finish_output+0x11f/0x12b
[59697.280533] __alloc_pages_nodemask+0xf2/0x187
[59697.280536] ? ip_route_input_rcu+0x489/0x7d3
[59697.280540] alloc_pages_current+0x85/0x8c
[59697.280542] new_slab+0xc2/0x2f7
[59697.280544] ___slab_alloc+0x350/0x3cd
[59697.280547] ? __build_skb+0x28/0xa4
[59697.280550] ? __netif_receive_skb_core+0x325/0x4c0
[59697.280551] __slab_alloc+0x12/0x17
[59697.280552] ? __slab_alloc+0x12/0x17
[59697.280554] kmem_cache_alloc+0x50/0x112
[59697.280555] __build_skb+0x28/0xa4
[59697.280556] build_skb+0x12/0x41
[59697.280560] ixgbe_poll+0x6e4/0xeef
[59697.280562] net_rx_action+0xd3/0x22d
[59697.280563] __do_softirq+0xe4/0x23a
[59697.280565] ? sort_range+0x1d/0x1d
[59697.280566] run_ksoftirqd+0x15/0x2a
[59697.280567] smpboot_thread_fn+0x128/0x13f
[59697.280568] kthread+0xf7/0xfc
[59697.280569] ? init_completion+0x24/0x24
[59697.280572] ret_from_fork+0x22/0x30
[59697.280573] Disabling lock debugging due to kernel taint
[60087.124142] BUG: Bad page state in process ksoftirqd/50 pfn:84ed9f
[60087.124145] page:ffffea00213b67c0 count:0 mapcount:-127
mapping: (null) index:0x0
[60087.124279] flags: 0x600000000000000()
[60087.124396] raw: 0600000000000000 0000000000000000 0000000000000000
00000000ffffff80
[60087.124397] raw: ffffea0021a029a0 ffffea00215302a0 0000000000000000
0000000000000000
[60087.124397] page dumped because: nonzero mapcount
[60087.124398] Modules linked in: sch_fq x86_pkg_temp_thermal ipmi_si
[60087.124403] CPU: 50 PID: 262 Comm: ksoftirqd/50 Tainted: G B
W 4.13.0-rc4-next-20170808 #1
[60087.124404] Call Trace:
[60087.124411] dump_stack+0x4d/0x63
[60087.124415] bad_page+0xf3/0x10f
[60087.124417] free_pages_check+0x75/0x7f
[60087.124419] __free_pages_ok+0xaf/0x158
[60087.124420] page_frag_free+0x47/0x49
[60087.124424] skb_free_head+0x19/0x22
[60087.124425] skb_release_data+0x89/0x90
[60087.124427] skb_release_all+0x1f/0x22
[60087.124428] _kfree_skb_defer+0x1e/0x5b
[60087.124430] napi_consume_skb+0x3e/0x41
[60087.124434] ixgbe_poll+0xe7/0xeef
[60087.124437] net_rx_action+0xd3/0x22d
[60087.124439] __do_softirq+0xe4/0x23a
[60087.124443] ? sort_range+0x1d/0x1d
[60087.124443] run_ksoftirqd+0x15/0x2a
[60087.124444] smpboot_thread_fn+0x128/0x13f
[60087.124447] kthread+0xf7/0xfc
[60087.124448] ? init_completion+0x24/0x24
[60087.124452] ret_from_fork+0x22/0x30
[60175.047713] BUG: Bad page state in process perf pfn:84ed9f
[60175.047715] page:ffffea00213b67c0 count:44363 mapcount:0
mapping: (null) index:0x0
[60175.047849] flags: 0x600000000000000()
[60175.047964] raw: 0600000000000000 0000000000000000 0000000000000000
0000ad4bffffffff
[60175.047965] raw: dead000000000100 dead000000000200 0000000000000000
0000000000000000
[60175.047965] page dumped because: nonzero _count
[60175.047966] Modules linked in: sch_fq x86_pkg_temp_thermal ipmi_si
[60175.047970] CPU: 28 PID: 8325 Comm: perf Tainted: G B W
4.13.0-rc4-next-20170808 #1
[60175.047971] Call Trace:
[60175.047980] dump_stack+0x4d/0x63
[60175.047986] bad_page+0xf3/0x10f
[60175.047988] check_new_page_bad+0x73/0x75
[60175.047989] get_page_from_freelist+0x2a9/0x63f
[60175.047990] __alloc_pages_nodemask+0xf2/0x187
[60175.047994] new_slab+0xd6/0x2f7
[60175.047996] ___slab_alloc+0x350/0x3cd
[60175.048000] ? kzalloc_node+0xf/0x11
[60175.048001] ? __alloc_pages_nodemask+0xf2/0x187
[60175.048002] __slab_alloc+0x12/0x17
[60175.048004] ? __slab_alloc+0x12/0x17
[60175.048005] __kmalloc_node+0x92/0x10c
[60175.048007] kzalloc_node+0xf/0x11
[60175.048008] reserve_ds_buffers+0x90/0x30d
[60175.048010] x86_reserve_hardware+0xbd/0xcd
[60175.048011] x86_pmu_event_init+0x50/0x1c9
[60175.048013] perf_try_init_event+0x41/0x72
[60175.048014] perf_event_alloc+0x36f/0x61a
[60175.048016] SYSC_perf_event_open+0x3fa/0xb22
[60175.048018] SyS_perf_event_open+0x9/0xb
[60175.048022] entry_SYSCALL_64_fastpath+0x13/0x94
[60175.048023] RIP: 0033:0x7f4b74add5c9
[60175.048024] RSP: 002b:00007ffe273ff6f8 EFLAGS: 00000202 ORIG_RAX:
000000000000012a
[60175.048025] RAX: ffffffffffffffda RBX: 00007ffe273ff830 RCX:
00007f4b74add5c9
[60175.048026] RDX: 00000000ffffffff RSI: 0000000000000000 RDI:
00007ffe273ff740
[60175.048027] RBP: 00007ffe273ff800 R08: 0000000000000000 R09:
00007ffe273ffa40
[60175.048027] R10: 00000000ffffffff R11: 0000000000000202 R12:
0000000000000000
[60175.048028] R13: 00007ffe273ffaf0 R14: 0000000000000001 R15:
00007ffe274050b0
[60205.531673] ixgbe 0000:d8:00.0 enp216s0f0: detected SFP+: 3
[60205.775698] ixgbe 0000:d8:00.0 enp216s0f0: NIC Link is Up 10 Gbps,
Flow Control: None
[60226.155671] ixgbe 0000:d8:00.0 enp216s0f0: detected SFP+: 3
[60226.399691] ixgbe 0000:d8:00.0 enp216s0f0: NIC Link is Up 10 Gbps,
Flow Control: None
[60401.551685] ixgbe 0000:d8:00.0 enp216s0f0: detected SFP+: 3
[60401.795723] ixgbe 0000:d8:00.0 enp216s0f0: NIC Link is Up 10 Gbps,
Flow Control: None
[60580.967690] ixgbe 0000:d8:00.0 enp216s0f0: detected SFP+: 3
[60581.315732] ixgbe 0000:d8:00.0 enp216s0f0: NIC Link is Up 10 Gbps,
Flow Control: None
[60961.112120] BUG: Bad page state in process ksoftirqd/44 pfn:855f2f
[60961.112123] page:ffffea002157cbc0 count:51910 mapcount:0
mapping: (null) index:0x0
[60961.112259] flags: 0x600000000000000()
[60961.112375] raw: 0600000000000000 0000000000000000 0000000000000000
0000cac6ffffffff
[60961.112376] raw: dead000000000100 dead000000000200 0000000000000000
0000000000000000
[60961.112377] page dumped because: nonzero _count
[60961.112377] Modules linked in: sch_fq x86_pkg_temp_thermal ipmi_si
[60961.112381] CPU: 44 PID: 232 Comm: ksoftirqd/44 Tainted: G B
W 4.13.0-rc4-next-20170808 #1
[60961.112382] Call Trace:
[60961.112390] dump_stack+0x4d/0x63
[60961.112394] bad_page+0xf3/0x10f
[60961.112396] check_new_page_bad+0x73/0x75
[60961.112397] get_page_from_freelist+0x2a9/0x63f
[60961.112398] __alloc_pages_nodemask+0xf2/0x187
[60961.112403] alloc_pages_current+0x85/0x8c
[60961.112405] new_slab+0xc2/0x2f7
[60961.112407] ___slab_alloc+0x350/0x3cd
[60961.112409] ? fq_enqueue+0x24e/0x3e3 [sch_fq]
[60961.112411] __slab_alloc+0x12/0x17
[60961.112412] ? __slab_alloc+0x12/0x17
[60961.112413] kmem_cache_alloc+0x50/0x112
[60961.112414] fq_enqueue+0x24e/0x3e3 [sch_fq]
[60961.112419] ? ixgbe_select_queue+0x15/0x17
[60961.112422] __dev_queue_xmit+0x2a5/0x4b9
[60961.112423] dev_queue_xmit+0xb/0xd
[60961.112423] ? dev_queue_xmit+0xb/0xd
[60961.112425] vlan_dev_hard_start_xmit+0x81/0xaa
[60961.112426] dev_hard_start_xmit+0xc3/0x197
[60961.112427] __dev_queue_xmit+0x38d/0x4b9
[60961.112429] ? eth_header+0x27/0xab
[60961.112429] dev_queue_xmit+0xb/0xd
[60961.112430] ? dev_queue_xmit+0xb/0xd
[60961.112432] neigh_connected_output+0x9b/0xb2
[60961.112436] ip_finish_output2+0x24e/0x292
[60961.112437] ip_finish_output+0x11f/0x12b
[60961.112438] ip_output+0x56/0xa7
[60961.112441] ? ip_route_input_rcu+0x489/0x7d3
[60961.112442] ip_forward_finish+0x53/0x58
[60961.112443] ip_forward+0x2ff/0x350
[60961.112443] ? ip_frag_mem+0x1e/0x1e
[60961.112444] ip_rcv_finish+0x27f/0x28a
[60961.112445] ip_rcv+0x2c0/0x30d
[60961.112448] __netif_receive_skb_core+0x325/0x4c0
[60961.112449] __netif_receive_skb+0x18/0x5a
[60961.112450] ? dev_gro_receive+0x2a9/0x3b4
[60961.112451] ? __netif_receive_skb+0x18/0x5a
[60961.112452] netif_receive_skb_internal+0x4b/0x96
[60961.112453] napi_gro_receive+0x75/0xcc
[60961.112455] ixgbe_poll+0xed8/0xeef
[60961.112459] ? __printk_ratelimit+0x8/0x15
[60961.112460] net_rx_action+0xd3/0x22d
[60961.112462] __do_softirq+0xe4/0x23a
[60961.112465] ? sort_range+0x1d/0x1d
[60961.112466] run_ksoftirqd+0x15/0x2a
[60961.112467] smpboot_thread_fn+0x128/0x13f
[60961.112470] kthread+0xf7/0xfc
[60961.112471] ? init_completion+0x24/0x24
[60961.112475] ret_from_fork+0x22/0x30
[60983.541418] capability: warning: `turbostat' uses 32-bit capabilities
(legacy support in use)
[61179.159683] ixgbe 0000:d8:00.1 enp216s0f1: detected SFP+: 4
[61179.503705] ixgbe 0000:d8:00.1 enp216s0f1: NIC Link is Up 10 Gbps,
Flow Control: None
[61183.212237] BUG: Bad page state in process ksoftirqd/52 pfn:855f2f
[61183.212240] page:ffffea002157cbc0 count:-1 mapcount:0
mapping: (null) index:0x0
[61183.212375] flags: 0x600000000000000()
[61183.212492] raw: 0600000000000000 0000000000000000 0000000000000000
ffffffffffffffff
[61183.212493] raw: dead000000000100 dead000000000200 0000000000000000
0000000000000000
[61183.212493] page dumped because: nonzero _count
[61183.212494] Modules linked in: sch_fq x86_pkg_temp_thermal ipmi_si
[61183.212498] CPU: 52 PID: 272 Comm: ksoftirqd/52 Tainted: G B
W 4.13.0-rc4-next-20170808 #1
[61183.212500] Call Trace:
[61183.212507] dump_stack+0x4d/0x63
[61183.212512] bad_page+0xf3/0x10f
[61183.212514] check_new_page_bad+0x73/0x75
[61183.212515] get_page_from_freelist+0x2a9/0x63f
[61183.212517] __alloc_pages_nodemask+0xf2/0x187
[61183.212523] ixgbe_alloc_rx_buffers+0x77/0x1bb
[61183.212524] ixgbe_poll+0x421/0xeef
[61183.212529] ? cfs_rq_util_change+0x1e/0x20
[61183.212532] net_rx_action+0xd3/0x22d
[61183.212534] __do_softirq+0xe4/0x23a
[61183.212536] ? sort_range+0x1d/0x1d
[61183.212537] run_ksoftirqd+0x15/0x2a
[61183.212538] smpboot_thread_fn+0x128/0x13f
[61183.212540] kthread+0xf7/0xfc
[61183.212541] ? init_completion+0x24/0x24
[61183.212546] ret_from_fork+0x22/0x30
[61183.283732] ixgbe 0000:d8:00.0 enp216s0f0: detected SFP+: 3
[61183.527747] ixgbe 0000:d8:00.0 enp216s0f0: NIC Link is Up 10 Gbps,
Flow Control: None
[61223.651684] ixgbe 0000:d8:00.1 enp216s0f1: detected SFP+: 4
[61223.891712] ixgbe 0000:d8:00.1 enp216s0f1: NIC Link is Up 10 Gbps,
Flow Control: None
[61228.651748] ixgbe 0000:d8:00.0 enp216s0f0: detected SFP+: 3
[61228.891759] ixgbe 0000:d8:00.0 enp216s0f0: NIC Link is Up 10 Gbps,
Flow Control: None
[61408.583698] ixgbe 0000:d8:00.1 enp216s0f1: detected SFP+: 4
[61408.831720] ixgbe 0000:d8:00.1 enp216s0f1: NIC Link is Up 10 Gbps,
Flow Control: None
[61414.003718] ixgbe 0000:d8:00.0 enp216s0f0: detected SFP+: 3
[61414.247764] ixgbe 0000:d8:00.0 enp216s0f0: NIC Link is Up 10 Gbps,
Flow Control: None
[63318.496105] igb 0000:18:00.3 enp24s0f3: Reset adapter
[63321.828156] igb 0000:18:00.3 enp24s0f3: igb: enp24s0f3 NIC Link is Up
1000 Mbps Full Duplex, Flow Control: RX
W dniu 2017-08-10 o 01:27, Cong Wang pisze:
> On Wed, Aug 9, 2017 at 8:50 AM, Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>>
>>
>> [60961.112120] BUG: Bad page state in process ksoftirqd/44 pfn:855f2f
>> [60961.112123] page:ffffea002157cbc0 count:51910 mapcount:0 mapping:
>> (null) index:0x0
>> [60961.112259] flags: 0x600000000000000()
>> [60961.112375] raw: 0600000000000000 0000000000000000 0000000000000000
>> 0000cac6ffffffff
>> [60961.112376] raw: dead000000000100 dead000000000200 0000000000000000
>> 0000000000000000
>> [60961.112377] page dumped because: nonzero _count
>> [60961.112377] Modules linked in: sch_fq x86_pkg_temp_thermal ipmi_si
>> [60961.112381] CPU: 44 PID: 232 Comm: ksoftirqd/44 Tainted: G B W
>> 4.13.0-rc4-next-20170808 #1
>> [60961.112382] Call Trace:
>> [60961.112390] dump_stack+0x4d/0x63
>> [60961.112394] bad_page+0xf3/0x10f
>> [60961.112396] check_new_page_bad+0x73/0x75
>> [60961.112397] get_page_from_freelist+0x2a9/0x63f
>> [60961.112398] __alloc_pages_nodemask+0xf2/0x187
>> [60961.112403] alloc_pages_current+0x85/0x8c
>> [60961.112405] new_slab+0xc2/0x2f7
>> [60961.112407] ___slab_alloc+0x350/0x3cd
>> [60961.112409] ? fq_enqueue+0x24e/0x3e3 [sch_fq]
>> [60961.112411] __slab_alloc+0x12/0x17
>> [60961.112412] ? __slab_alloc+0x12/0x17
>> [60961.112413] kmem_cache_alloc+0x50/0x112
>> [60961.112414] fq_enqueue+0x24e/0x3e3 [sch_fq]
>> [60961.112419] ? ixgbe_select_queue+0x15/0x17
>> [60961.112422] __dev_queue_xmit+0x2a5/0x4b9
>> [60961.112423] dev_queue_xmit+0xb/0xd
>
> Is this the first stack trace in your dmesg?
>
> It doesn't look like a bug in sch_fq, but like we have
> a bad mm page somewhere else, perhaps ixgbe driver.
>
>
>
>> [60961.112423] ? dev_queue_xmit+0xb/0xd
>> [60961.112425] vlan_dev_hard_start_xmit+0x81/0xaa
>> [60961.112426] dev_hard_start_xmit+0xc3/0x197
>> [60961.112427] __dev_queue_xmit+0x38d/0x4b9
>> [60961.112429] ? eth_header+0x27/0xab
>> [60961.112429] dev_queue_xmit+0xb/0xd
>> [60961.112430] ? dev_queue_xmit+0xb/0xd
>> [60961.112432] neigh_connected_output+0x9b/0xb2
>> [60961.112436] ip_finish_output2+0x24e/0x292
>> [60961.112437] ip_finish_output+0x11f/0x12b
>> [60961.112438] ip_output+0x56/0xa7
>> [60961.112441] ? ip_route_input_rcu+0x489/0x7d3
>> [60961.112442] ip_forward_finish+0x53/0x58
>> [60961.112443] ip_forward+0x2ff/0x350
>> [60961.112443] ? ip_frag_mem+0x1e/0x1e
>> [60961.112444] ip_rcv_finish+0x27f/0x28a
>> [60961.112445] ip_rcv+0x2c0/0x30d
>> [60961.112448] __netif_receive_skb_core+0x325/0x4c0
>> [60961.112449] __netif_receive_skb+0x18/0x5a
>> [60961.112450] ? dev_gro_receive+0x2a9/0x3b4
>> [60961.112451] ? __netif_receive_skb+0x18/0x5a
>> [60961.112452] netif_receive_skb_internal+0x4b/0x96
>> [60961.112453] napi_gro_receive+0x75/0xcc
>> [60961.112455] ixgbe_poll+0xed8/0xeef
>> [60961.112459] ? __printk_ratelimit+0x8/0x15
>> [60961.112460] net_rx_action+0xd3/0x22d
>> [60961.112462] __do_softirq+0xe4/0x23a
>> [60961.112465] ? sort_range+0x1d/0x1d
>> [60961.112466] run_ksoftirqd+0x15/0x2a
>> [60961.112467] smpboot_thread_fn+0x128/0x13f
>> [60961.112470] kthread+0xf7/0xfc
>> [60961.112471] ? init_completion+0x24/0x24
>> [60961.112475] ret_from_fork+0x22/0x30
>> [60983.541418] capability: warning: `turbostat' uses 32-bit capabilities
>> (legacy support in use)
>> [61179.159683] ixgbe 0000:d8:00.1 enp216s0f1: detected SFP+: 4
>> [61179.503705] ixgbe 0000:d8:00.1 enp216s0f1: NIC Link is Up 10 Gbps, Flow
>> Control: None
>> [61183.212237] BUG: Bad page state in process ksoftirqd/52 pfn:855f2f
>> [61183.212240] page:ffffea002157cbc0 count:-1 mapcount:0 mapping:
>> (null) index:0x0
>> [61183.212375] flags: 0x600000000000000()
>> [61183.212492] raw: 0600000000000000 0000000000000000 0000000000000000
>> ffffffffffffffff
>> [61183.212493] raw: dead000000000100 dead000000000200 0000000000000000
>> 0000000000000000
>> [61183.212493] page dumped because: nonzero _count
>> [61183.212494] Modules linked in: sch_fq x86_pkg_temp_thermal ipmi_si
>> [61183.212498] CPU: 52 PID: 272 Comm: ksoftirqd/52 Tainted: G B W
>> 4.13.0-rc4-next-20170808 #1
>> [61183.212500] Call Trace:
>> [61183.212507] dump_stack+0x4d/0x63
>> [61183.212512] bad_page+0xf3/0x10f
>> [61183.212514] check_new_page_bad+0x73/0x75
>> [61183.212515] get_page_from_freelist+0x2a9/0x63f
>> [61183.212517] __alloc_pages_nodemask+0xf2/0x187
>> [61183.212523] ixgbe_alloc_rx_buffers+0x77/0x1bb
>> [61183.212524] ixgbe_poll+0x421/0xeef
>> [61183.212529] ? cfs_rq_util_change+0x1e/0x20
>> [61183.212532] net_rx_action+0xd3/0x22d
>> [61183.212534] __do_softirq+0xe4/0x23a
>> [61183.212536] ? sort_range+0x1d/0x1d
>> [61183.212537] run_ksoftirqd+0x15/0x2a
>> [61183.212538] smpboot_thread_fn+0x128/0x13f
>> [61183.212540] kthread+0xf7/0xfc
>> [61183.212541] ? init_completion+0x24/0x24
>> [61183.212546] ret_from_fork+0x22/0x30
>> [61183.283732] ixgbe 0000:d8:00.0 enp216s0f0: detected SFP+: 3
>> [61183.527747] ixgbe 0000:d8:00.0 enp216s0f0: NIC Link is Up 10 Gbps, Flow
>> Control: None
>> [61223.651684] ixgbe 0000:d8:00.1 enp216s0f1: detected SFP+: 4
>> [61223.891712] ixgbe 0000:d8:00.1 enp216s0f1: NIC Link is Up 10 Gbps, Flow
>> Control: None
>> [61228.651748] ixgbe 0000:d8:00.0 enp216s0f0: detected SFP+: 3
>> [61228.891759] ixgbe 0000:d8:00.0 enp216s0f0: NIC Link is Up 10 Gbps, Flow
>> Control: None
>> [61408.583698] ixgbe 0000:d8:00.1 enp216s0f1: detected SFP+: 4
>> [61408.831720] ixgbe 0000:d8:00.1 enp216s0f1: NIC Link is Up 10 Gbps, Flow
>> Control: None
>> [61414.003718] ixgbe 0000:d8:00.0 enp216s0f0: detected SFP+: 3
>> [61414.247764] ixgbe 0000:d8:00.0 enp216s0f0: NIC Link is Up 10 Gbps, Flow
>> Control: None
>> [63318.496105] igb 0000:18:00.3 enp24s0f3: Reset adapter
>> [63321.828156] igb 0000:18:00.3 enp24s0f3: igb: enp24s0f3 NIC Link is Up
>> 1000 Mbps Full Duplex, Flow Control: RX
>>
>>
>>
>>
>>
>> If matters configuration below:
>>
>> tc -s -d qdisc show
>> qdisc noqueue 0: dev lo root refcnt 2
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc mq 0: dev enp24s0f3 root
>> Sent 10595979 bytes 44275 pkt (dropped 0, overlimits 0 requeues 7)
>> backlog 0b 0p requeues 7
>> qdisc pfifo_fast 0: dev enp24s0f3 parent :8 bands 3 priomap 1 2 2 2 1 2 0 0
>> 1 1 1 1 1 1 1 1
>> Sent 2562064 bytes 7304 pkt (dropped 0, overlimits 0 requeues 1)
>> backlog 0b 0p requeues 1
>> qdisc pfifo_fast 0: dev enp24s0f3 parent :7 bands 3 priomap 1 2 2 2 1 2 0 0
>> 1 1 1 1 1 1 1 1
>> Sent 152292 bytes 3589 pkt (dropped 0, overlimits 0 requeues 2)
>> backlog 0b 0p requeues 2
>> qdisc pfifo_fast 0: dev enp24s0f3 parent :6 bands 3 priomap 1 2 2 2 1 2 0 0
>> 1 1 1 1 1 1 1 1
>> Sent 7298 bytes 15 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc pfifo_fast 0: dev enp24s0f3 parent :5 bands 3 priomap 1 2 2 2 1 2 0 0
>> 1 1 1 1 1 1 1 1
>> Sent 5042 bytes 5 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc pfifo_fast 0: dev enp24s0f3 parent :4 bands 3 priomap 1 2 2 2 1 2 0 0
>> 1 1 1 1 1 1 1 1
>> Sent 3194 bytes 4 pkt (dropped 0, overlimits 0 requeues 1)
>> backlog 0b 0p requeues 1
>> qdisc pfifo_fast 0: dev enp24s0f3 parent :3 bands 3 priomap 1 2 2 2 1 2 0 0
>> 1 1 1 1 1 1 1 1
>> Sent 5386576 bytes 13206 pkt (dropped 0, overlimits 0 requeues 1)
>> backlog 0b 0p requeues 1
>> qdisc pfifo_fast 0: dev enp24s0f3 parent :2 bands 3 priomap 1 2 2 2 1 2 0 0
>> 1 1 1 1 1 1 1 1
>> Sent 6286 bytes 24 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc pfifo_fast 0: dev enp24s0f3 parent :1 bands 3 priomap 1 2 2 2 1 2 0 0
>> 1 1 1 1 1 1 1 1
>> Sent 2473227 bytes 20128 pkt (dropped 0, overlimits 0 requeues 2)
>> backlog 0b 0p requeues 2
>> qdisc mq 1: dev enp216s0f0 root
>> Sent 140 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc fq 831c: dev enp216s0f0 parent 1:a limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 8320: dev enp216s0f0 parent 1:e limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 831e: dev enp216s0f0 parent 1:c limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 8322: dev enp216s0f0 parent 1:10 limit 8192p flow_limit 100p
>> buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate
>> 10Gbit refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 8313: dev enp216s0f0 parent 1:1 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 8315: dev enp216s0f0 parent 1:3 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 8317: dev enp216s0f0 parent 1:5 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 831b: dev enp216s0f0 parent 1:9 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 8319: dev enp216s0f0 parent 1:7 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 140 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 1 flows (1 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 831d: dev enp216s0f0 parent 1:b limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 831f: dev enp216s0f0 parent 1:d limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 8321: dev enp216s0f0 parent 1:f limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 8316: dev enp216s0f0 parent 1:4 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 8314: dev enp216s0f0 parent 1:2 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 8318: dev enp216s0f0 parent 1:6 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc fq 831a: dev enp216s0f0 parent 1:8 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> 0 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 0 throttled
>> qdisc mq 1: dev enp216s0f1 root
>> Sent 5724464060294 bytes 3017574303 pkt (dropped 261703917, overlimits 0
>> requeues 1588)
>> backlog 19340684b 68101p requeues 1588
>> qdisc fq 8331: dev enp216s0f1 parent 1:f limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357754034478 bytes 1261904590 pkt (dropped 16345926, overlimits 0
>> requeues 99)
>> backlog 1190528b 4198p requeues 99
>> 64 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 15 throttled, 2238 ns latency, 16345926 flows_plimit
>> qdisc fq 8324: dev enp216s0f1 parent 1:2 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357941986556 bytes 1265190082 pkt (dropped 16334441, overlimits 0
>> requeues 114)
>> backlog 1203308b 4237p requeues 114
>> 64 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 56 throttled, 1988 ns latency, 16334441 flows_plimit
>> qdisc fq 8326: dev enp216s0f1 parent 1:4 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357756741808 bytes 1261951272 pkt (dropped 16352852, overlimits 0
>> requeues 108)
>> backlog 1195356b 4210p requeues 108
>> 64 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 10 throttled, 1652 ns latency, 16352852 flows_plimit
>> qdisc fq 832a: dev enp216s0f1 parent 1:8 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357754168172 bytes 1261906634 pkt (dropped 16375523, overlimits 0
>> requeues 93)
>> backlog 1191664b 4196p requeues 93
>> 64 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 4 throttled, 1722 ns latency, 16375523 flows_plimit
>> qdisc fq 8328: dev enp216s0f1 parent 1:6 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357755800928 bytes 1261934832 pkt (dropped 16297692, overlimits 0
>> requeues 89)
>> backlog 1206432b 4248p requeues 89
>> 65 flows (1 inactive, 0 throttled)
>> 0 gc, 0 highprio, 4 throttled, 1520 ns latency, 16297692 flows_plimit
>> qdisc fq 832c: dev enp216s0f1 parent 1:a limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357757943172 bytes 1261969807 pkt (dropped 16393936, overlimits 0
>> requeues 97)
>> backlog 1185984b 4176p requeues 97
>> 64 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 4 throttled, 1257 ns latency, 16393936 flows_plimit
>> qdisc fq 832e: dev enp216s0f1 parent 1:c limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357754956814 bytes 1261920403 pkt (dropped 16373257, overlimits 0
>> requeues 111)
>> backlog 1184848b 4172p requeues 111
>> 65 flows (1 inactive, 0 throttled)
>> 0 gc, 0 highprio, 11 throttled, 2070 ns latency, 16373257 flows_plimit
>> qdisc fq 8332: dev enp216s0f1 parent 1:10 limit 8192p flow_limit 100p
>> buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate
>> 10Gbit refill_delay 40.0ms
>> Sent 357754779582 bytes 1261916755 pkt (dropped 16306559, overlimits 0
>> requeues 80)
>> backlog 1151336b 4054p requeues 80
>> 65 flows (1 inactive, 0 throttled)
>> 0 gc, 0 highprio, 3 throttled, 1530 ns latency, 16306559 flows_plimit
>> qdisc fq 8330: dev enp216s0f1 parent 1:e limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357754801422 bytes 1261919138 pkt (dropped 16360298, overlimits 0
>> requeues 68)
>> backlog 1266072b 4457p requeues 68
>> 64 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 7 throttled, 1114 ns latency, 16360298 flows_plimit
>> qdisc fq 8325: dev enp216s0f1 parent 1:3 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357756968400 bytes 1261953663 pkt (dropped 16377069, overlimits 0
>> requeues 84)
>> backlog 1267492b 4463p requeues 84
>> 64 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 6 throttled, 2470 ns latency, 16377069 flows_plimit
>> qdisc fq 8323: dev enp216s0f1 parent 1:1 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357944308424 bytes 1265224502 pkt (dropped 16351766, overlimits 0
>> requeues 125)
>> backlog 1227164b 4321p requeues 125
>> 65 flows (1 inactive, 0 throttled)
>> 0 gc, 0 highprio, 58 throttled, 2143 ns latency, 16351766 flows_plimit
>> qdisc fq 8327: dev enp216s0f1 parent 1:5 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357756634544 bytes 1261949446 pkt (dropped 16354220, overlimits 0
>> requeues 114)
>> backlog 1176896b 4143p requeues 114
>> 64 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 5 throttled, 2274 ns latency, 16354220 flows_plimit
>> qdisc fq 8329: dev enp216s0f1 parent 1:7 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357755020876 bytes 1261921756 pkt (dropped 16366535, overlimits 0
>> requeues 108)
>> backlog 1171216b 4124p requeues 108
>> 65 flows (1 inactive, 0 throttled)
>> 0 gc, 0 highprio, 3 throttled, 932 ns latency, 16366535 flows_plimit
>> qdisc fq 832d: dev enp216s0f1 parent 1:b limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357755470474 bytes 1261930198 pkt (dropped 16347462, overlimits 0
>> requeues 99)
>> backlog 1255848b 4422p requeues 99
>> 64 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 5 throttled, 1699 ns latency, 16347462 flows_plimit
>> qdisc fq 832b: dev enp216s0f1 parent 1:9 limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357754977102 bytes 1261920885 pkt (dropped 16407954, overlimits 0
>> requeues 92)
>> backlog 1260108b 4437p requeues 92
>> 64 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 5 throttled, 1638 ns latency, 16407954 flows_plimit
>> qdisc fq 832f: dev enp216s0f1 parent 1:d limit 8192p flow_limit 100p buckets
>> 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 maxrate 10Gbit
>> refill_delay 40.0ms
>> Sent 357755499918 bytes 1261929638 pkt (dropped 16358427, overlimits 0
>> requeues 107)
>> backlog 1194220b 4205p requeues 107
>> 64 flows (0 inactive, 0 throttled)
>> 0 gc, 0 highprio, 8 throttled, 2257 ns latency, 16358427 flows_plimit
>> qdisc noqueue 0: dev vlan1000 root refcnt 2
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>>
>> ethtool -k enp216s0f1
>> Features for enp216s0f1:
>> Cannot get device udp-fragmentation-offload settings: Operation not
>> supported
>> rx-checksumming: on
>> tx-checksumming: on
>> tx-checksum-ipv4: off [fixed]
>> tx-checksum-ip-generic: on
>> tx-checksum-ipv6: off [fixed]
>> tx-checksum-fcoe-crc: off [fixed]
>> tx-checksum-sctp: on
>> scatter-gather: on
>> tx-scatter-gather: on
>> tx-scatter-gather-fraglist: off [fixed]
>> tcp-segmentation-offload: on
>> tx-tcp-segmentation: on
>> tx-tcp-ecn-segmentation: off [fixed]
>> tx-tcp-mangleid-segmentation: on
>> tx-tcp6-segmentation: on
>> udp-fragmentation-offload: off
>> generic-segmentation-offload: off
>> generic-receive-offload: on
>> large-receive-offload: off
>> rx-vlan-offload: on
>> tx-vlan-offload: on
>> ntuple-filters: on
>> receive-hashing: on
>> highdma: on [fixed]
>> rx-vlan-filter: on
>> vlan-challenged: off [fixed]
>> tx-lockless: off [fixed]
>> netns-local: off [fixed]
>> tx-gso-robust: off [fixed]
>> tx-fcoe-segmentation: off [fixed]
>> tx-gre-segmentation: on
>> tx-gre-csum-segmentation: on
>> tx-ipxip4-segmentation: on
>> tx-ipxip6-segmentation: on
>> tx-udp_tnl-segmentation: on
>> tx-udp_tnl-csum-segmentation: on
>> tx-gso-partial: on
>> tx-sctp-segmentation: off [fixed]
>> tx-esp-segmentation: off [fixed]
>> fcoe-mtu: off [fixed]
>> tx-nocache-copy: on
>> loopback: off [fixed]
>> rx-fcs: off [fixed]
>> rx-all: off
>> tx-vlan-stag-hw-insert: off [fixed]
>> rx-vlan-stag-hw-parse: off [fixed]
>> rx-vlan-stag-filter: off [fixed]
>> l2-fwd-offload: off
>> hw-tc-offload: on
>> esp-hw-offload: off [fixed]
>> esp-tx-csum-hw-offload: off [fixed]
>> rx-udp_tunnel-port-offload: on
>>
>> ethtool -k enp216s0f0
>> Features for enp216s0f0:
>> Cannot get device udp-fragmentation-offload settings: Operation not
>> supported
>> rx-checksumming: on
>> tx-checksumming: on
>> tx-checksum-ipv4: off [fixed]
>> tx-checksum-ip-generic: on
>> tx-checksum-ipv6: off [fixed]
>> tx-checksum-fcoe-crc: off [fixed]
>> tx-checksum-sctp: on
>> scatter-gather: on
>> tx-scatter-gather: on
>> tx-scatter-gather-fraglist: off [fixed]
>> tcp-segmentation-offload: on
>> tx-tcp-segmentation: on
>> tx-tcp-ecn-segmentation: off [fixed]
>> tx-tcp-mangleid-segmentation: on
>> tx-tcp6-segmentation: on
>> udp-fragmentation-offload: off
>> generic-segmentation-offload: off
>> generic-receive-offload: on
>> large-receive-offload: off
>> rx-vlan-offload: on
>> tx-vlan-offload: on
>> ntuple-filters: on
>> receive-hashing: on
>> highdma: on [fixed]
>> rx-vlan-filter: on
>> vlan-challenged: off [fixed]
>> tx-lockless: off [fixed]
>> netns-local: off [fixed]
>> tx-gso-robust: off [fixed]
>> tx-fcoe-segmentation: off [fixed]
>> tx-gre-segmentation: on
>> tx-gre-csum-segmentation: on
>> tx-ipxip4-segmentation: on
>> tx-ipxip6-segmentation: on
>> tx-udp_tnl-segmentation: on
>> tx-udp_tnl-csum-segmentation: on
>> tx-gso-partial: on
>> tx-sctp-segmentation: off [fixed]
>> tx-esp-segmentation: off [fixed]
>> fcoe-mtu: off [fixed]
>> tx-nocache-copy: on
>> loopback: off [fixed]
>> rx-fcs: off [fixed]
>> rx-all: off
>> tx-vlan-stag-hw-insert: off [fixed]
>> rx-vlan-stag-hw-parse: off [fixed]
>> rx-vlan-stag-filter: off [fixed]
>> l2-fwd-offload: off
>> hw-tc-offload: off
>> esp-hw-offload: off [fixed]
>> esp-tx-csum-hw-offload: off [fixed]
>> rx-udp_tunnel-port-offload: on
>>
>>
^ permalink raw reply
* Re: [PATCH v4 1/4] can: dev: Add support for limiting configured bitrate
From: Sergei Shtylyov @ 2017-08-10 10:05 UTC (permalink / raw)
To: Franklin S Cooper Jr, linux-kernel, devicetree, netdev, linux-can,
wg, mkl, robh+dt, quentin.schulz, dev.kurt, andrew, socketcan
In-Reply-To: <20170810005916.27163-2-fcooper@ti.com>
Hello!
On 8/10/2017 3:59 AM, Franklin S Cooper Jr wrote:
> Various CAN or CAN-FD IP may be able to run at a faster rate than
> what the transceiver the CAN node is connected to. This can lead to
> unexpected errors. However, CAN transceivers typically have fixed
> limitations and provide no means to discover these limitations at
> runtime. Therefore, add support for a can-transceiver node that
> can be reused by other CAN peripheral drivers to determine for both
> CAN and CAN-FD what the max bitrate that can be used. If the user
> tries to configure CAN to pass these maximum bitrates it will throw
> an error.
>
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> ---
> Version 4 changes:
> Used can-transceiver instead of fixed-transceiver.
>
> drivers/net/can/dev.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/can/dev.h | 5 +++++
> 2 files changed, 55 insertions(+)
>
> diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
> index 365a8cc..372108f 100644
> --- a/drivers/net/can/dev.c
> +++ b/drivers/net/can/dev.c
[...]
> @@ -814,6 +815,39 @@ int open_candev(struct net_device *dev)
> }
> EXPORT_SYMBOL_GPL(open_candev);
>
> +#ifdef CONFIG_OF
> +/*
> + * Common function that can be used to understand the limitation of
> + * a transceiver when it provides no means to determine these limitations
> + * at runtime.
> + */
> +void of_can_transceiver(struct net_device *dev)
> +{
> + struct device_node *dn;
> + struct can_priv *priv = netdev_priv(dev);
> + struct device_node *np;
> + unsigned int max_bitrate;
> + int ret;
> +
> + np = dev->dev.parent->of_node;
I'd do that as an initializer.
> +
> + dn = of_get_child_by_name(np, "can-transceiver");
> + if (!dn)
> + return;
> +
> + max_bitrate = 0;
> + ret = of_property_read_u32(dn, "max-bitrate", &max_bitrate);
I'd initialize max_bitrate to 0 as iff of_property_read_u32() fails, it'll
leave the variable unset...
> +
> + if (max_bitrate > 0) {
You risk checking unset variable here.
> + priv->max_bitrate = max_bitrate;
> + priv->is_bitrate_limited = true;
> + } else if (ret != -EINVAL) {
> + netdev_warn(dev, "Invalid value for transceiver max bitrate\n");
> + }
> +}
> +EXPORT_SYMBOL(of_can_transceiver);
> +#endif
> +
> /*
> * Common close function for cleanup before the device gets closed.
> *
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: Vitaly Kuznetsov @ 2017-08-10 10:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrew Lunn, network dev, David S. Miller, Eric Dumazet,
Stephen Hemminger
In-Reply-To: <1502355817.4936.9.camel@edumazet-glaptop3.roam.corp.google.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On Thu, 2017-08-10 at 10:41 +0200, Vitaly Kuznetsov wrote:
>> Andrew Lunn <andrew@lunn.ch> writes:
>>
>> >> I understand the 'legacy' concern but at the same time we don't want to
>> >> have aftificial limitations too. Name change, in particular, doesn't
>> >> happen 'under the hood' -- someone privileged enough needs to request
>> >> the change.
>> >>
>> >> Can you think of any particular real world scenarios which are broken by
>> >> the change?
>> >
>> > How about:
>> >
>> > man 8 dhclient-script
>> >
>> > The interface name is passed in $interface to the scripts. Do we get
>> > the old name or the new name? I suspect scripts are going to break if
>> > they are given the old name, which no longer exists.
>>
>> Yes but why would anyone change interface name while dhclient-script is
>> running? Things will also go wrong if you try bringing interface down
>> during the run or do some other configuration, right? Running multiple
>> configuration tools at the same moment is a bad idea, you never know
>> what you're gonna end up with.
>>
>> As I see it, checks in kernel we have are meant to protect kernel
>> itself, not to disallow all user<->kernel interactions leading to
>> imperfect result.
>>
>> (AFAIU) If we remove the check nothing is going to change: udev will
>> still be renaming interfaces before bringing them up. In netvsc case
>> users are not supposed to configure the VF interface at all, it just
>> becomes a slave of netvsc interface.
>
> Are we sending an event if device name is changed ?
>
We are - rtnetlink_event() does the job. We, however, don't have a
special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
> If yes, your patch is fine.
>
> If not, daemons would not be aware the need to refresh their view of the
> world.
Yes but AFAIU daemons may need to do the same refresh when the interface
is down too (and, hopefully, they do it already).
--
Vitaly
^ permalink raw reply
* [PATCH 2/2 net-next] hns3pf: Fix some harmless copy and paste bugs
From: Dan Carpenter @ 2017-08-10 9:56 UTC (permalink / raw)
To: Yisen Zhuang, Salil Mehta
Cc: David S. Miller, Jiri Pirko, Jamal Hadi Salim, Daode Huang,
Wei Hu (Xavier), netdev, kernel-janitors
These were copy and paste bugs, but I believe they are harmless.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
index e519795dff7c..9589b7e1d24c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -330,7 +330,7 @@ static int hns3_nic_mc_sync(struct net_device *netdev,
struct hns3_nic_priv *priv = netdev_priv(netdev);
struct hnae3_handle *h = priv->ae_handle;
- if (h->ae_algo->ops->add_uc_addr)
+ if (h->ae_algo->ops->add_mc_addr)
return h->ae_algo->ops->add_mc_addr(h, addr);
return 0;
@@ -342,7 +342,7 @@ static int hns3_nic_mc_unsync(struct net_device *netdev,
struct hns3_nic_priv *priv = netdev_priv(netdev);
struct hnae3_handle *h = priv->ae_handle;
- if (h->ae_algo->ops->rm_uc_addr)
+ if (h->ae_algo->ops->rm_mc_addr)
return h->ae_algo->ops->rm_mc_addr(h, addr);
return 0;
^ permalink raw reply related
* MICROSOFT OUTLOOK UPGRADE
From: Correa, Carla @ 2017-08-10 9:40 UTC (permalink / raw)
To: no-reply@verified.net
MICROSOFT OUTLOOK UPGRADE
Do hereby be notify that you email box account wil soon stop working if not Upgrade to our latest version now.
Do verify<https://mrschgong5.wixsite.com/jilp> here without no delay for it to be Upgraded.
Microsoft Upgrade Team.
Microsoft Outlook Inc. © 2017
?
?
^ permalink raw reply
* [PATCH 1/2 net-next] hns3pf: fix hns3_del_tunnel_port()
From: Dan Carpenter @ 2017-08-10 9:54 UTC (permalink / raw)
To: Yisen Zhuang
Cc: Salil Mehta, David S. Miller, Jiri Pirko, Jamal Hadi Salim,
lipeng, netdev, linux-kernel, kernel-janitors
This function has a copy and paste bug so it accidentally calls the add
function instead of the delete function.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
index 069ae426aa24..e519795dff7c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -1138,7 +1138,7 @@ static void hns3_del_tunnel_port(struct net_device *netdev, u16 port,
udp_tnl->dst_port = 0;
/* TBD send command to hardware to del port */
if (h->ae_algo->ops->del_tunnel_udp)
- h->ae_algo->ops->add_tunnel_udp(h, port);
+ h->ae_algo->ops->del_tunnel_udp(h, port);
}
/* hns3_nic_udp_tunnel_add - Get notifiacetion about UDP tunnel ports
^ permalink raw reply related
* [PATCH] net/sched/hfsc: allocate tcf block for hfsc root class
From: Konstantin Khlebnikov @ 2017-08-10 9:31 UTC (permalink / raw)
To: netdev, Jiri Pirko, David S. Miller, Jamal Hadi Salim
Without this filters cannot be attached.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure")
---
net/sched/sch_hfsc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
index b52f74610dc7..3ad02bbe6903 100644
--- a/net/sched/sch_hfsc.c
+++ b/net/sched/sch_hfsc.c
@@ -1428,6 +1428,10 @@ hfsc_init_qdisc(struct Qdisc *sch, struct nlattr *opt)
return err;
q->eligible = RB_ROOT;
+ err = tcf_block_get(&q->root.block, &q->root.filter_list);
+ if (err)
+ goto err_tcf;
+
q->root.cl_common.classid = sch->handle;
q->root.refcnt = 1;
q->root.sched = q;
@@ -1447,6 +1451,10 @@ hfsc_init_qdisc(struct Qdisc *sch, struct nlattr *opt)
qdisc_watchdog_init(&q->watchdog, sch);
return 0;
+
+err_tcf:
+ qdisc_class_hash_destroy(&q->clhash);
+ return err;
}
static int
^ permalink raw reply related
* [PATCH] net/sched: reset block pointer in tcf_block_put()
From: Konstantin Khlebnikov @ 2017-08-10 9:31 UTC (permalink / raw)
To: netdev, Jiri Pirko, David S. Miller, Jamal Hadi Salim
In previous API tcf_destroy_chain() could be called several times and
some schedulers like hfsc and atm use that. In new API tcf_block_put()
frees block but leaves stale pointer, second call will free it once again.
This patch fixes such double-frees.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure")
---
include/net/pkt_cls.h | 4 ++--
net/sched/cls_api.c | 4 +++-
net/sched/sch_atm.c | 4 ++--
net/sched/sch_cbq.c | 6 +++---
net/sched/sch_drr.c | 2 +-
net/sched/sch_dsmark.c | 2 +-
net/sched/sch_fq_codel.c | 2 +-
net/sched/sch_hfsc.c | 6 +++---
net/sched/sch_htb.c | 8 ++++----
net/sched/sch_ingress.c | 6 +++---
net/sched/sch_multiq.c | 2 +-
net/sched/sch_prio.c | 2 +-
net/sched/sch_qfq.c | 2 +-
net/sched/sch_sfb.c | 2 +-
net/sched/sch_sfq.c | 2 +-
15 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index 537d0a0ad4c4..96aef16e5d56 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -23,7 +23,7 @@ struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
void tcf_chain_put(struct tcf_chain *chain);
int tcf_block_get(struct tcf_block **p_block,
struct tcf_proto __rcu **p_filter_chain);
-void tcf_block_put(struct tcf_block *block);
+void tcf_block_put(struct tcf_block **p_block);
int tcf_classify(struct sk_buff *skb, const struct tcf_proto *tp,
struct tcf_result *res, bool compat_mode);
@@ -35,7 +35,7 @@ int tcf_block_get(struct tcf_block **p_block,
return 0;
}
-static inline void tcf_block_put(struct tcf_block *block)
+static inline void tcf_block_put(struct tcf_block **p_block)
{
}
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 39da0c5801c9..72147650b179 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -281,8 +281,9 @@ int tcf_block_get(struct tcf_block **p_block,
}
EXPORT_SYMBOL(tcf_block_get);
-void tcf_block_put(struct tcf_block *block)
+void tcf_block_put(struct tcf_block **p_block)
{
+ struct tcf_block *block = *p_block;
struct tcf_chain *chain, *tmp;
if (!block)
@@ -291,6 +292,7 @@ void tcf_block_put(struct tcf_block *block)
list_for_each_entry_safe(chain, tmp, &block->chain_list, list)
tcf_chain_destroy(chain);
kfree(block);
+ *p_block = NULL;
}
EXPORT_SYMBOL(tcf_block_put);
diff --git a/net/sched/sch_atm.c b/net/sched/sch_atm.c
index 572fe2584e48..b6b24a9834b0 100644
--- a/net/sched/sch_atm.c
+++ b/net/sched/sch_atm.c
@@ -144,7 +144,7 @@ static void atm_tc_put(struct Qdisc *sch, unsigned long cl)
list_del_init(&flow->list);
pr_debug("atm_tc_put: qdisc %p\n", flow->q);
qdisc_destroy(flow->q);
- tcf_block_put(flow->block);
+ tcf_block_put(&flow->block);
if (flow->sock) {
pr_debug("atm_tc_put: f_count %ld\n",
file_count(flow->sock->file));
@@ -573,7 +573,7 @@ static void atm_tc_destroy(struct Qdisc *sch)
pr_debug("atm_tc_destroy(sch %p,[qdisc %p])\n", sch, p);
list_for_each_entry(flow, &p->flows, list)
- tcf_block_put(flow->block);
+ tcf_block_put(&flow->block);
list_for_each_entry_safe(flow, tmp, &p->flows, list) {
if (flow->ref > 1)
diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
index 481036f6b54e..89bff8d4e113 100644
--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -1407,7 +1407,7 @@ static void cbq_destroy_class(struct Qdisc *sch, struct cbq_class *cl)
WARN_ON(cl->filters);
- tcf_block_put(cl->block);
+ tcf_block_put(&cl->block);
qdisc_destroy(cl->q);
qdisc_put_rtab(cl->R_tab);
gen_kill_estimator(&cl->rate_est);
@@ -1432,7 +1432,7 @@ static void cbq_destroy(struct Qdisc *sch)
*/
for (h = 0; h < q->clhash.hashsize; h++) {
hlist_for_each_entry(cl, &q->clhash.hash[h], common.hnode)
- tcf_block_put(cl->block);
+ tcf_block_put(&cl->block);
}
for (h = 0; h < q->clhash.hashsize; h++) {
hlist_for_each_entry_safe(cl, next, &q->clhash.hash[h],
@@ -1599,7 +1599,7 @@ cbq_change_class(struct Qdisc *sch, u32 classid, u32 parentid, struct nlattr **t
qdisc_root_sleeping_running(sch),
tca[TCA_RATE]);
if (err) {
- tcf_block_put(cl->block);
+ tcf_block_put(&cl->block);
kfree(cl);
goto failure;
}
diff --git a/net/sched/sch_drr.c b/net/sched/sch_drr.c
index a413dc1c2098..fb73a903ab74 100644
--- a/net/sched/sch_drr.c
+++ b/net/sched/sch_drr.c
@@ -466,7 +466,7 @@ static void drr_destroy_qdisc(struct Qdisc *sch)
struct hlist_node *next;
unsigned int i;
- tcf_block_put(q->block);
+ tcf_block_put(&q->block);
for (i = 0; i < q->clhash.hashsize; i++) {
hlist_for_each_entry_safe(cl, next, &q->clhash.hash[i],
diff --git a/net/sched/sch_dsmark.c b/net/sched/sch_dsmark.c
index 6d94fcc3592a..1110d577c978 100644
--- a/net/sched/sch_dsmark.c
+++ b/net/sched/sch_dsmark.c
@@ -406,7 +406,7 @@ static void dsmark_destroy(struct Qdisc *sch)
pr_debug("%s(sch %p,[qdisc %p])\n", __func__, sch, p);
- tcf_block_put(p->block);
+ tcf_block_put(&p->block);
qdisc_destroy(p->q);
if (p->mv != p->embedded)
kfree(p->mv);
diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
index 337f2d6d81e4..f905c83a5f4a 100644
--- a/net/sched/sch_fq_codel.c
+++ b/net/sched/sch_fq_codel.c
@@ -452,7 +452,7 @@ static void fq_codel_destroy(struct Qdisc *sch)
{
struct fq_codel_sched_data *q = qdisc_priv(sch);
- tcf_block_put(q->block);
+ tcf_block_put(&q->block);
kvfree(q->backlogs);
kvfree(q->flows);
}
diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
index 3ad02bbe6903..8da31692c675 100644
--- a/net/sched/sch_hfsc.c
+++ b/net/sched/sch_hfsc.c
@@ -1053,7 +1053,7 @@ hfsc_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
qdisc_root_sleeping_running(sch),
tca[TCA_RATE]);
if (err) {
- tcf_block_put(cl->block);
+ tcf_block_put(&cl->block);
kfree(cl);
return err;
}
@@ -1099,7 +1099,7 @@ hfsc_destroy_class(struct Qdisc *sch, struct hfsc_class *cl)
{
struct hfsc_sched *q = qdisc_priv(sch);
- tcf_block_put(cl->block);
+ tcf_block_put(&cl->block);
qdisc_destroy(cl->qdisc);
gen_kill_estimator(&cl->rate_est);
if (cl != &q->root)
@@ -1531,7 +1531,7 @@ hfsc_destroy_qdisc(struct Qdisc *sch)
for (i = 0; i < q->clhash.hashsize; i++) {
hlist_for_each_entry(cl, &q->clhash.hash[i], cl_common.hnode)
- tcf_block_put(cl->block);
+ tcf_block_put(&cl->block);
}
for (i = 0; i < q->clhash.hashsize; i++) {
hlist_for_each_entry_safe(cl, next, &q->clhash.hash[i],
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index 203286ab4427..890ad577022f 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -1237,7 +1237,7 @@ static void htb_destroy_class(struct Qdisc *sch, struct htb_class *cl)
qdisc_destroy(cl->un.leaf.q);
}
gen_kill_estimator(&cl->rate_est);
- tcf_block_put(cl->block);
+ tcf_block_put(&cl->block);
kfree(cl);
}
@@ -1255,11 +1255,11 @@ static void htb_destroy(struct Qdisc *sch)
* because filter need its target class alive to be able to call
* unbind_filter on it (without Oops).
*/
- tcf_block_put(q->block);
+ tcf_block_put(&q->block);
for (i = 0; i < q->clhash.hashsize; i++) {
hlist_for_each_entry(cl, &q->clhash.hash[i], common.hnode)
- tcf_block_put(cl->block);
+ tcf_block_put(&cl->block);
}
for (i = 0; i < q->clhash.hashsize; i++) {
hlist_for_each_entry_safe(cl, next, &q->clhash.hash[i],
@@ -1415,7 +1415,7 @@ static int htb_change_class(struct Qdisc *sch, u32 classid,
qdisc_root_sleeping_running(sch),
tca[TCA_RATE] ? : &est.nla);
if (err) {
- tcf_block_put(cl->block);
+ tcf_block_put(&cl->block);
kfree(cl);
goto failure;
}
diff --git a/net/sched/sch_ingress.c b/net/sched/sch_ingress.c
index d8a9bebcab90..f0bcc78c43e0 100644
--- a/net/sched/sch_ingress.c
+++ b/net/sched/sch_ingress.c
@@ -78,7 +78,7 @@ static void ingress_destroy(struct Qdisc *sch)
{
struct ingress_sched_data *q = qdisc_priv(sch);
- tcf_block_put(q->block);
+ tcf_block_put(&q->block);
net_dec_ingress_queue();
}
@@ -185,8 +185,8 @@ static void clsact_destroy(struct Qdisc *sch)
{
struct clsact_sched_data *q = qdisc_priv(sch);
- tcf_block_put(q->egress_block);
- tcf_block_put(q->ingress_block);
+ tcf_block_put(&q->egress_block);
+ tcf_block_put(&q->ingress_block);
net_dec_ingress_queue();
net_dec_egress_queue();
diff --git a/net/sched/sch_multiq.c b/net/sched/sch_multiq.c
index f143b7bbaa0d..7e5f1a021664 100644
--- a/net/sched/sch_multiq.c
+++ b/net/sched/sch_multiq.c
@@ -172,7 +172,7 @@ multiq_destroy(struct Qdisc *sch)
int band;
struct multiq_sched_data *q = qdisc_priv(sch);
- tcf_block_put(q->block);
+ tcf_block_put(&q->block);
for (band = 0; band < q->bands; band++)
qdisc_destroy(q->queues[band]);
diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c
index e3e364cc9a70..83c63670df98 100644
--- a/net/sched/sch_prio.c
+++ b/net/sched/sch_prio.c
@@ -147,7 +147,7 @@ prio_destroy(struct Qdisc *sch)
int prio;
struct prio_sched_data *q = qdisc_priv(sch);
- tcf_block_put(q->block);
+ tcf_block_put(&q->block);
for (prio = 0; prio < q->bands; prio++)
qdisc_destroy(q->queues[prio]);
}
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 0e16dfda0bd7..b111d98b43cb 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -1497,7 +1497,7 @@ static void qfq_destroy_qdisc(struct Qdisc *sch)
struct hlist_node *next;
unsigned int i;
- tcf_block_put(q->block);
+ tcf_block_put(&q->block);
for (i = 0; i < q->clhash.hashsize; i++) {
hlist_for_each_entry_safe(cl, next, &q->clhash.hash[i],
diff --git a/net/sched/sch_sfb.c b/net/sched/sch_sfb.c
index 11fb6ec878d6..76b469cd97d1 100644
--- a/net/sched/sch_sfb.c
+++ b/net/sched/sch_sfb.c
@@ -467,7 +467,7 @@ static void sfb_destroy(struct Qdisc *sch)
{
struct sfb_sched_data *q = qdisc_priv(sch);
- tcf_block_put(q->block);
+ tcf_block_put(&q->block);
qdisc_destroy(q->qdisc);
}
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index f80ea2cc5f1f..10a8aef68162 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -699,7 +699,7 @@ static void sfq_destroy(struct Qdisc *sch)
{
struct sfq_sched_data *q = qdisc_priv(sch);
- tcf_block_put(q->block);
+ tcf_block_put(&q->block);
q->perturb_period = 0;
del_timer_sync(&q->perturb_timer);
sfq_free(q->ht);
^ permalink raw reply related
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: Eric Dumazet @ 2017-08-10 9:03 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: Andrew Lunn, network dev, David S. Miller, Eric Dumazet,
Stephen Hemminger
In-Reply-To: <871sojyfv0.fsf@vitty.brq.redhat.com>
On Thu, 2017-08-10 at 10:41 +0200, Vitaly Kuznetsov wrote:
> Andrew Lunn <andrew@lunn.ch> writes:
>
> >> I understand the 'legacy' concern but at the same time we don't want to
> >> have aftificial limitations too. Name change, in particular, doesn't
> >> happen 'under the hood' -- someone privileged enough needs to request
> >> the change.
> >>
> >> Can you think of any particular real world scenarios which are broken by
> >> the change?
> >
> > How about:
> >
> > man 8 dhclient-script
> >
> > The interface name is passed in $interface to the scripts. Do we get
> > the old name or the new name? I suspect scripts are going to break if
> > they are given the old name, which no longer exists.
>
> Yes but why would anyone change interface name while dhclient-script is
> running? Things will also go wrong if you try bringing interface down
> during the run or do some other configuration, right? Running multiple
> configuration tools at the same moment is a bad idea, you never know
> what you're gonna end up with.
>
> As I see it, checks in kernel we have are meant to protect kernel
> itself, not to disallow all user<->kernel interactions leading to
> imperfect result.
>
> (AFAIU) If we remove the check nothing is going to change: udev will
> still be renaming interfaces before bringing them up. In netvsc case
> users are not supposed to configure the VF interface at all, it just
> becomes a slave of netvsc interface.
Are we sending an event if device name is changed ?
If yes, your patch is fine.
If not, daemons would not be aware the need to refresh their view of the
world.
^ permalink raw reply
* Re: [v2,06/20] brcm80211: constify usb_device_id
From: Kalle Valo @ 2017-08-10 8:58 UTC (permalink / raw)
To: Arvind Yadav
Cc: petkan, arend.vanspriel, franky.lin, wright.feng, hante.meuleman,
linux-kernel, netdev, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list
In-Reply-To: <1502295926-21042-1-git-send-email-arvind.yadav.cs@gmail.com>
Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> usb_device_id are not supposed to change at runtime. All functions
> working with usb_device_id provided by <linux/usb.h> work with
> const usb_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Does not apply to wireless-drivers-next:
error: Failed to merge in the changes.
Applying: brcm80211: constify usb_device_id
Using index info to reconstruct a base tree...
M drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
CONFLICT (content): Merge conflict in drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
Patch failed at 0001 brcm80211: constify usb_device_id
The copy of the patch that failed is found in: .git/rebase-apply/patch
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9890985/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2,01/20] ar5523: constify usb_device_id
From: Kalle Valo @ 2017-08-10 8:57 UTC (permalink / raw)
To: Arvind Yadav; +Cc: petkan, linux-kernel, netdev, linux-wireless
In-Reply-To: <1502295823-20824-2-git-send-email-arvind.yadav.cs@gmail.com>
Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> usb_device_id are not supposed to change at runtime. All functions
> working with usb_device_id provided by <linux/usb.h> work with
> const usb_device_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
17 patches applied to wireless-drivers-next.git, thanks.
c5c60b2d577e ar5523: constify usb_device_id
76f6a5c80a4b carl9170: constify usb_device_id
22796d149229 at76c50x: constify usb_device_id
c4291319b6fe orinoco: constify usb_device_id
54c9f21605d8 p54: constify usb_device_id
3673c417f509 libertas: constify usb_device_id
8a3132fa6bbb libertas_tf: constify usb_device_id
7516dbd470e3 mwifiex: constify usb_device_id
e2717b312750 mt7601u: constify usb_device_id
88ee79a1a11c rt2500usb: constify usb_device_id
c7bb7d79cf4f rt2800usb: constify usb_device_id
543e4f87508b rt73usb: constify usb_device_id
e0b081b20523 rtl8187: constify usb_device_id
5033d70de169 rtl8xxxu: constify usb_device_id
3a55a4afd187 rtl8192cu: constify usb_device_id
b924ffd7a4cd zd1201: constify usb_device_id
ecf23a788e13 zd1211rw: constify usb_device_id
--
https://patchwork.kernel.org/patch/9890989/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH 3/3] net: stmmac: dwmac-sun8i: choose internal PHY via phy-is-integrated
From: Corentin Labbe @ 2017-08-10 8:51 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, maxime.ripard, wens,
peppe.cavallaro, alexandre.torgue, andrew, f.fainelli
Cc: netdev, devicetree, linux-kernel, linux-arm-kernel,
Corentin Labbe
In-Reply-To: <20170810085129.20463-1-clabbe.montjoie@gmail.com>
The current way to find if the phy is internal is to compare DT phy-mode
and emac_variant/internal_phy.
But it will negate a possible future SoC where an external PHY use the
same phy mode than the internal one.
This patch adds a new way to find if the PHY is internal, via
the phy-is-integrated property.
Since the internal_phy variable does not need anymore to contain the xMII mode
used by the internal PHY, it is still used for knowing the presence of an
internal PHY, so it is modified to a boolean soc_has_internal_phy.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index fffd6d5fc907..672553b652bd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -41,14 +41,14 @@
* This value is used for disabling properly EMAC
* and used as a good starting value in case of the
* boot process(uboot) leave some stuff.
- * @internal_phy: Does the MAC embed an internal PHY
+ * @soc_has_internal_phy: Does the MAC embed an internal PHY
* @support_mii: Does the MAC handle MII
* @support_rmii: Does the MAC handle RMII
* @support_rgmii: Does the MAC handle RGMII
*/
struct emac_variant {
u32 default_syscon_value;
- int internal_phy;
+ bool soc_has_internal_phy;
bool support_mii;
bool support_rmii;
bool support_rgmii;
@@ -75,7 +75,7 @@ struct sunxi_priv_data {
static const struct emac_variant emac_variant_h3 = {
.default_syscon_value = 0x58000,
- .internal_phy = PHY_INTERFACE_MODE_MII,
+ .soc_has_internal_phy = true,
.support_mii = true,
.support_rmii = true,
.support_rgmii = true
@@ -83,20 +83,20 @@ static const struct emac_variant emac_variant_h3 = {
static const struct emac_variant emac_variant_v3s = {
.default_syscon_value = 0x38000,
- .internal_phy = PHY_INTERFACE_MODE_MII,
+ .soc_has_internal_phy = true,
.support_mii = true
};
static const struct emac_variant emac_variant_a83t = {
.default_syscon_value = 0,
- .internal_phy = 0,
+ .soc_has_internal_phy = false,
.support_mii = true,
.support_rgmii = true
};
static const struct emac_variant emac_variant_a64 = {
.default_syscon_value = 0,
- .internal_phy = 0,
+ .soc_has_internal_phy = false,
.support_mii = true,
.support_rmii = true,
.support_rgmii = true
@@ -648,7 +648,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
"Current syscon value is not the default %x (expect %x)\n",
val, reg);
- if (gmac->variant->internal_phy) {
+ if (gmac->variant->soc_has_internal_phy) {
if (!gmac->use_internal_phy) {
/* switch to external PHY interface */
reg &= ~H3_EPHY_SELECT;
@@ -932,7 +932,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
}
plat_dat->interface = of_get_phy_mode(dev->of_node);
- if (plat_dat->interface == gmac->variant->internal_phy) {
+ if (of_property_read_bool(plat_dat->phy_node, "phy-is-integrated")) {
dev_info(&pdev->dev, "Will use internal PHY\n");
gmac->use_internal_phy = true;
gmac->ephy_clk = of_clk_get(plat_dat->phy_node, 0);
--
2.13.0
^ permalink raw reply related
* [PATCH 2/3] ARM: sun8i: sunxi-h3-h5: add phy-is-integrated property to internal PHY
From: Corentin Labbe @ 2017-08-10 8:51 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, maxime.ripard, wens,
peppe.cavallaro, alexandre.torgue, andrew, f.fainelli
Cc: netdev, devicetree, linux-kernel, linux-arm-kernel,
Corentin Labbe
In-Reply-To: <20170810085129.20463-1-clabbe.montjoie@gmail.com>
This patch add the new phy-is-integrated property to the internal PHY
node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 4b599b5d26f6..54fc24e4c569 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -425,6 +425,7 @@
reg = <1>;
clocks = <&ccu CLK_BUS_EPHY>;
resets = <&ccu RST_BUS_EPHY>;
+ phy-is-integrated;
};
};
};
--
2.13.0
^ permalink raw reply related
* [PATCH 1/3] Documentation: bindings: Add documentation for phy-is-integrated
From: Corentin Labbe @ 2017-08-10 8:51 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, maxime.ripard, wens,
peppe.cavallaro, alexandre.torgue, andrew, f.fainelli
Cc: netdev, Corentin Labbe, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20170810085129.20463-1-clabbe.montjoie@gmail.com>
This patch adds documentation for phy-is-integrated, a boolean property
for PHY which permit to know if the PHY is integrated in the SoC.
For example, Allwinner H3 embeds an internal PHY but still permit to
connect an external PHY.
Since it is possible in theory to have the same PHY model both internal
and external, the only way to detect the location of the PHY is via this property.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
Documentation/devicetree/bindings/net/phy.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index b55857696fc3..6fabc14da432 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -52,6 +52,10 @@ Optional Properties:
Mark the corresponding energy efficient ethernet mode as broken and
request the ethernet to stop advertising it.
+- phy-is-integrated: If set, indicates that the PHY is integrated in the SoC
+ and so is not an external PHY. (Some SoC embeds a PHY and still provide
+ support for an optional external PHY)
+
Example:
ethernet-phy@0 {
--
2.13.0
^ permalink raw reply related
* [PATCH 0/3] net: stmmac: Detect PHY location with phy-is-integrated
From: Corentin Labbe @ 2017-08-10 8:51 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, maxime.ripard, wens,
peppe.cavallaro, alexandre.torgue, andrew, f.fainelli
Cc: netdev, devicetree, linux-kernel, linux-arm-kernel,
Corentin Labbe
Hello
The current way to find if the phy is internal is to compare DT phy-mode
and emac_variant/internal_phy.
But it will negate a possible future SoC where an external PHY use the
same phy mode than the internal one.
This patchs series adds a new way to find if the PHY is internal, via
the phy-is-integrated DT property.
The first and third patch should go via the net tree.
the second via the sunxi tree.
Thanks
Regards
Corentin Labbe (3):
Documentation: bindings: Add documentation for phy-is-integrated
ARM: sun8i: sunxi-h3-h5: add phy-is-integrated property to internal
PHY
net: stmmac: dwmac-sun8i: choose internal PHY via phy-is-integrated
Documentation/devicetree/bindings/net/phy.txt | 4 ++++
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 16 ++++++++--------
3 files changed, 13 insertions(+), 8 deletions(-)
--
2.13.0
^ permalink raw reply
* Re: [PATCH iproute2 master] bpf: unbreak libelf linkage for bpf obj loader
From: Daniel Borkmann @ 2017-08-10 8:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170809173512.2db1eb40@xeon-e3>
On 08/10/2017 02:35 AM, Stephen Hemminger wrote:
> On Thu, 10 Aug 2017 00:15:41 +0200
> Daniel Borkmann <daniel@iogearbox.net> wrote:
>
>> Commit 69fed534a533 ("change how Config is used in Makefile's") moved
>> HAVE_MNL specific CFLAGS/LDLIBS for building with libmnl out of the
>> top level Makefile into sub-Makefiles. However, it also removed the
>> HAVE_ELF specific CFLAGS/LDLIBS entirely, which breaks the BPF object
>> loader for tc and ip with "No ELF library support compiled in." despite
>> having libelf detected in configure script. Fix it similarly as in
>> 69fed534a533 for HAVE_ELF.
>>
>> Fixes: 69fed534a533 ("change how Config is used in Makefile's")
>> Reported-by: Jeffrey Panneman <jeffrey.panneman@tno.nl>
>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>
> Thanks, but I am thinking maybe a better solution long term would be to
> move all the package specific stuff into the generated Config file.
>
> That way only the generation shell script would have to change.
>
> Also, all the flags should probably be using pkg-config to get the values.
Sure, sounds all good, for the time being, I would like to have
that breakage undone though, so users can work with loading BPF
programs again on -master.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: Vitaly Kuznetsov @ 2017-08-10 8:41 UTC (permalink / raw)
To: Andrew Lunn
Cc: ????????????, network dev, Linux Kernel Mailing List,
David S. Miller, Eric Dumazet, Stephen Hemminger
In-Reply-To: <20170809161027.GA28694@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
>> I understand the 'legacy' concern but at the same time we don't want to
>> have aftificial limitations too. Name change, in particular, doesn't
>> happen 'under the hood' -- someone privileged enough needs to request
>> the change.
>>
>> Can you think of any particular real world scenarios which are broken by
>> the change?
>
> How about:
>
> man 8 dhclient-script
>
> The interface name is passed in $interface to the scripts. Do we get
> the old name or the new name? I suspect scripts are going to break if
> they are given the old name, which no longer exists.
Yes but why would anyone change interface name while dhclient-script is
running? Things will also go wrong if you try bringing interface down
during the run or do some other configuration, right? Running multiple
configuration tools at the same moment is a bad idea, you never know
what you're gonna end up with.
As I see it, checks in kernel we have are meant to protect kernel
itself, not to disallow all user<->kernel interactions leading to
imperfect result.
(AFAIU) If we remove the check nothing is going to change: udev will
still be renaming interfaces before bringing them up. In netvsc case
users are not supposed to configure the VF interface at all, it just
becomes a slave of netvsc interface.
--
Vitaly
^ permalink raw reply
* Re: [PATCH v2 net-next 5/7] rtnetlink: protect handler table with rcu
From: Ido Schimmel @ 2017-08-10 8:26 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <20170809184153.16700-6-fw@strlen.de>
On Wed, Aug 09, 2017 at 08:41:51PM +0200, Florian Westphal wrote:
> Note that netlink dumps still acquire rtnl mutex via the netlink
> dump infrastructure.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> Reviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Florian, can you please check the following splat? I didn't bisect, but
looks like it's related to this patch.
Thanks
[ 2.940093] =============================
[ 2.944145] WARNING: suspicious RCU usage
[ 2.948147] 4.13.0-rc4-idosch-next-custom #565 Not tainted
[ 2.954116] -----------------------------
[ 2.958113] net/core/rtnetlink.c:175 suspicious rcu_dereference_check() usage!
[ 2.965116]
[ 2.965116] other info that might help us debug this:
[ 2.965116]
[ 2.973123]
[ 2.973123] rcu_scheduler_active = 1, debug_locks = 1
[ 2.979119] no locks held by swapper/0/1.
[ 2.983109]
[ 2.983109] stack backtrace:
[ 2.988117] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc4-idosch-next-custom #565
[ 2.989000] Hardware name: Mellanox Technologies Ltd. Mellanox switch/Mellanox switch, BIOS 4.6.5 05/21/2015
[ 2.989000] Call Trace:
[ 2.989000] dump_stack+0xb1/0x10c
[ 2.989000] ? _atomic_dec_and_lock+0x124/0x124
[ 2.989000] ? lockdep_print_held_locks+0x9b/0xf0
[ 2.989000] lockdep_rcu_suspicious+0xdd/0x110
[ 2.989000] __rtnl_register+0x1c1/0x320
[ 2.989000] ? rtnetlink_bind+0x50/0x50
[ 2.989000] ? net_defaults_init+0x29/0x29
[ 2.989000] rtnl_register+0x11/0x30
[ 2.989000] net_ns_init+0x1bd/0x1fd
[ 2.989000] ? net_defaults_init+0x29/0x29
[ 2.989000] ? __init_srcu_struct+0x54/0x60
[ 2.989000] ? srcu_init_notifier_head+0x4a/0x80
[ 2.989000] do_one_initcall+0x9a/0x241
[ 2.989000] ? initcall_blacklisted+0x140/0x140
[ 2.989000] ? up_read+0x40/0x40
[ 2.989000] ? _raw_spin_unlock_irqrestore+0x3d/0x60
[ 2.989000] ? __wake_up+0x3f/0x50
[ 2.989000] kernel_init_freeable+0x3ea/0x485
[ 2.989000] ? rest_init+0x100/0x100
[ 2.989000] kernel_init+0xe/0x140
[ 2.989000] ? rest_init+0x100/0x100
[ 2.989000] ? rest_init+0x100/0x100
[ 2.989000] ret_from_fork+0x27/0x40
^ permalink raw reply
* [PATCH 1/1] forcedeth: replace init_timer_deferrable with setup_deferrable_timer
From: Zhu Yanjun @ 2017-08-10 8:13 UTC (permalink / raw)
To: davem, netdev
Replace init_timer_deferrable with setup_deferrable_timer to simplify
the source code.
Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
---
drivers/net/ethernet/nvidia/forcedeth.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index aa912f4..bdbfe8f 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -5629,9 +5629,8 @@ static int nv_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
setup_timer(&np->oom_kick, nv_do_rx_refill, (unsigned long)dev);
setup_timer(&np->nic_poll, nv_do_nic_poll, (unsigned long)dev);
- init_timer_deferrable(&np->stats_poll);
- np->stats_poll.data = (unsigned long) dev;
- np->stats_poll.function = nv_do_stats_poll; /* timer handler */
+ setup_deferrable_timer(&np->stats_poll, nv_do_stats_poll,
+ (unsigned long)dev);
err = pci_enable_device(pci_dev);
if (err)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/4] net-next: dsa: fix flow dissection
From: John Crispin @ 2017-08-10 8:10 UTC (permalink / raw)
To: Eric Dumazet, David Miller
Cc: andrew, f.fainelli, muciri, vivien.didelot, netdev, sean.wang,
linux-kernel, shashidhar.lakkavalli, linux-mediatek
In-Reply-To: <1502347335.4936.2.camel@edumazet-glaptop3.roam.corp.google.com>
On 10/08/17 08:42, Eric Dumazet wrote:
> On Wed, 2017-08-09 at 22:52 -0700, David Miller wrote:
>> From: John Crispin <john@phrozen.org>
>> Date: Wed, 9 Aug 2017 14:41:15 +0200
>>
>>> RPS and probably other kernel features are currently broken on some if not
>>> all DSA devices. The root cause of this is that skb_hash will call the
>>> flow_dissector. At this point the skb still contains the magic switch
>>> header and the skb->protocol field is not set up to the correct 802.3
>>> value yet. By the time the tag specific code is called, removing the header
>>> and properly setting the protocol an invalid hash is already set. In the
>>> case of the mt7530 this will result in all flows always having the same
>>> hash.
>>>
>>> Changes since RFC:
>>> * use a callback instead of static values
>>> * add cover letter
>> Series applied, thanks.
> Is this related ?
>
> net/core/flow_dissector.c: In function '__skb_flow_dissect':
> net/core/flow_dissector.c:448:18: error: 'struct net_device' has no member named 'dsa_ptr'
> ops = skb->dev->dsa_ptr->tag_ops;
> ^
> make[3]: *** [net/core/flow_dissector.o] Error 1
>
>
Hi Eric,
I have just sent the fix for this compile error
John
^ permalink raw reply
* [PATCH net-next] net: core: fix compile error inside flow_dissector due to new dsa callback
From: John Crispin @ 2017-08-10 8:09 UTC (permalink / raw)
To: Jiri Pirko, Eric Dumazet, David S . Miller
Cc: netdev, linux-kernel, John Crispin
The following error was introduced by
commit 43e665287f93 ("net-next: dsa: fix flow dissection")
due to a missing #if guard
net/core/flow_dissector.c: In function '__skb_flow_dissect':
net/core/flow_dissector.c:448:18: error: 'struct net_device' has no member named 'dsa_ptr'
ops = skb->dev->dsa_ptr->tag_ops;
^
make[3]: *** [net/core/flow_dissector.o] Error 1
Signed-off-by: John Crispin <john@phrozen.org>
---
net/core/flow_dissector.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 5b5be9577257..79b9c06c83ad 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -441,6 +441,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
skb->vlan_proto : skb->protocol;
nhoff = skb_network_offset(skb);
hlen = skb_headlen(skb);
+#if IS_ENABLED(CONFIG_NET_DSA)
if (unlikely(netdev_uses_dsa(skb->dev))) {
const struct dsa_device_ops *ops;
int offset;
@@ -452,6 +453,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
nhoff += offset;
}
}
+#endif
}
/* It is ensured by skb_flow_dissector_init() that control key will
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3 05/11] net: stmmac: dwmac-rk: Add internal phy support
From: David.Wu @ 2017-08-10 7:48 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Corentin Labbe, Florian Fainelli, Andrew Lunn, David Miller,
Heiko Stübner, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Olof Johansson, Russell King, Arnd Bergmann,
Tao Huang, hwg, alexandre.torgue, devicetree, netdev,
linux-kernel, open list:ARM/Rockchip SoC..., Giuseppe Cavallaro
In-Reply-To: <CAGb2v66ZG3Ct1aFBOXQd8vkMCF-UNk7bN-vsXasbe_j5FexENw@mail.gmail.com>
Hi Chen-Yu,
在 2017/8/10 10:40, Chen-Yu Tsai 写道:
> Hi David,
>
> On Wed, Aug 9, 2017 at 5:38 PM, David.Wu <david.wu@rock-chips.com> wrote:
>> Hello Corentin, Chen-Yu
>>
>>
>> 在 2017/8/9 16:45, Corentin Labbe 写道:
>>>
>>> On Thu, Aug 03, 2017 at 07:06:33PM +0800, Chen-Yu Tsai wrote:
>>>>
>>>> On Thu, Aug 3, 2017 at 1:38 AM, Florian Fainelli <f.fainelli@gmail.com>
>>>> wrote:
>>>>>
>>>>> On 08/01/2017 11:21 PM, David Wu wrote:
>>>>>>
>>>>>> To make internal phy work, need to configure the phy_clock,
>>>>>> phy cru_reset and related registers.
>>>>>>
>>>>>> Signed-off-by: David Wu <david.wu@rock-chips.com>
>>>>>> ---
>>>>>> .../devicetree/bindings/net/rockchip-dwmac.txt | 6 +-
>>>>>> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 81
>>>>>> ++++++++++++++++++++++
>>>>>> 2 files changed, 86 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
>>>>>> b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
>>>>>> index 8f42755..ec39b31 100644
>>>>>> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
>>>>>> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
>>>>>> @@ -25,7 +25,8 @@ Required properties:
>>>>>> - clock-names: One name for each entry in the clocks property.
>>>>>> - phy-mode: See ethernet.txt file in the same directory.
>>>>>> - pinctrl-names: Names corresponding to the numbered pinctrl states.
>>>>>> - - pinctrl-0: pin-control mode. can be <&rgmii_pins> or <&rmii_pins>.
>>>>>> + - pinctrl-0: pin-control mode. can be <&rgmii_pins>, <&rmii_pins> or
>>>>>> led pins
>>>>>> + for internal phy mode.
>>>>>> - clock_in_out: For RGMII, it must be "input", means main
>>>>>> clock(125MHz)
>>>>>> is not sourced from SoC's PLL, but input from PHY; For RMII,
>>>>>> "input" means
>>>>>> PHY provides the reference clock(50MHz), "output" means GMAC
>>>>>> provides the
>>>>>> @@ -40,6 +41,9 @@ Optional properties:
>>>>>> - tx_delay: Delay value for TXD timing. Range value is 0~0x7F, 0x30
>>>>>> as default.
>>>>>> - rx_delay: Delay value for RXD timing. Range value is 0~0x7F, 0x10
>>>>>> as default.
>>>>>> - phy-supply: phandle to a regulator if the PHY needs one
>>>>>> + - clocks: <&cru MAC_PHY>: Clock selector for internal macphy
>>>>>> + - phy-is-internal: A boolean property allows us to know that MAC will
>>>>>> connect to
>>>>>> + internal phy.
>>>>>
>>>>>
>>>>> This is incorrect in two ways:
>>>>>
>>>>> - this is a property of the PHY, so it should be documented as such in
>>>>> Documentation/devicetree/bindings/net/phy.txt so other bindings can
>>>>> re-use it
>>>>>
>>>>> - if it was specific to your MAC you would expect a vendor prefix to
>>>>> this property, which is not there
>>>>>
>>>>> An alternative way to implement the external/internal logic selection
>>>>> would be mandate that your Ethernet PHY node have a compatible string
>>>>> like this:
>>>>>
>>>>> phy@0 {
>>>>> compatible = "ethernet-phy-id1234.d400",
>>>>> "ethernet-phy-802.3-c22";
>>>>> };
>>>>>
>>>>> Then you don't need this phy-is-internal property, because you can
>>>>> locate the PHY node by the phy-handle (see more about that in a reply to
>>>>> patch 10) and you can determine ahead of time whether this PHY is
>>>>> internal or not based on its compatible string.
>>>>
>>>>
>>>> This doesn't really work for us (sunxi). The "internal" PHY of the H3
>>>> is also available in the X-Powers AC200 combo chip, which would be
>>>> external. Same ID. So if someone were to be stupid and put the two
>>>> together, you wouldn't know which one it actually is. Generically
>>>> it doesn't make sense to match against the ID either. The PHY is
>>>> only integrated or inlined into the SoC, meaning it could be moved
>>>> elsewhere or even be a discreet part.
>>>>
>>>> The way I see it is more like a reversed pinmux. The system should
>>>> select either the internal set or external set of xMII pins to use.
>>>>
>>>> A phy-is-internal property in the PHY node would work for us. We
>>>> already need a PHY node to describe its clocks and resets.
>>>>
>>>> A side note to this solution is that, since the internal PHY is defined
>>>> at the .dtsi level, any external PHYs at the same address would need to
>>>> make sure to delete the property, which is kind of counterintuitive, but
>>>> it is how device tree works. One would want to put the internal PHY's
>>>> address, assuming it is configurable, on something that is rarely used.
>>>>
>>>
>>> Hello David, Florian, Andrew
>>>
>>> Could someone ack this ? or nack if you think that the chance for having
>>> two PHY id both internal and external is too low.
>>> Anyway, we need a choice.
>>>
>>
>> I think we should be specific to the situation, for us we have the
>> possibility that the Mac only picks up internal PHY, so this can be fixed at
>> the. DTSi level, also possible INTERNL PHY's Mac can also be used to connect
>> external PHY, while cutting off the connection with the internal PHY, so we
>> should define the internal PHY at the DTS level, so I think Florian's
>> approach is acceptable.
>
> So it looks like you have the clock for the internal/integrated PHY at the
> MAC level. I think this lets you define/add the PHY at the board level more
> easily without a lot of duplication?
>
> Sunxi has the clock and reset in the PHY node, which is defined in the dtsi
> file. (This part is already done.)
Okay, that is better difined in the PHY node, i'll move them later.
>
> ChenYu
>
>
>
^ permalink raw reply
* [PATCHv2 2/2] drivers: net: davinci_mdio: print bus frequency
From: Max Uvarov @ 2017-08-10 7:47 UTC (permalink / raw)
To: netdev; +Cc: linux-omap, grygorii.strashko, Max Uvarov
In-Reply-To: <1502351267-23841-1-git-send-email-muvarov@gmail.com>
Frequency can be adjusted in DT it make sense to
print current used value on driver init.
Signed-off-by: Max Uvarov <muvarov@gmail.com>
---
drivers/net/ethernet/ti/davinci_mdio.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 611e7cc..3c33f45 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -159,8 +159,10 @@ static int davinci_mdio_reset(struct mii_bus *bus)
/* dump hardware version info */
ver = __raw_readl(&data->regs->version);
- dev_info(data->dev, "davinci mdio revision %d.%d\n",
- (ver >> 8) & 0xff, ver & 0xff);
+ dev_info(data->dev,
+ "davinci mdio revision %d.%d, bus freq %ld\n",
+ (ver >> 8) & 0xff, ver & 0xff,
+ data->pdata.bus_freq);
if (data->skip_scan)
goto done;
--
2.5.0
^ permalink raw reply related
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