* 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-09 15:50 UTC (permalink / raw)
To: netdev
[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
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 3/3] net: rxrpc: Replace time_t type with time64_t type
From: David Howells @ 2017-08-09 15:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: dhowells, Baolin Wang, David Miller, james.l.morris,
Serge E. Hallyn, marc.dionne, Dan Carpenter, Jason A. Donenfeld,
Mark Brown, keyrings, Linux Kernel Mailing List, LSM List,
Networking
In-Reply-To: <CAK8P3a2STbhgFB5kbVTZqAgY70K_GCaWgj6Kqs4RJOOt2oSd-g@mail.gmail.com>
Arnd Bergmann <arnd@arndb.de> wrote:
> Ah, I'm slowly starting to understand how this fits together. So you can add
> a key either through key_add() from local user space, or through an rxrpc
> socket.
No, you can't add keys through an rxrpc socket.
There are three 'classes' of key:
(1) Client keys (type rxrpc). These must be added by add_key() by userspace
(but could also be acquired by upcalling to /sbin/request-key) and then
the kernel calls request_key() to locate them on entry through either a
kafs inode/file operation or through sendmsg() to an AF_RXRPC socket.
(2) Server keys (type rxrpc_s). These are created by userspace and are
presented to an AF_RXRPC server socket by calling setsockopt(). The
server uses these to validate/decrypt the token passed by a RESPONSE
packet.
(3) Service connection keys (type rxrpc). These are created internally by
AF_RXRPC after a successful challenge/response negotiation to hold the
security details so that we have a struct key to pass around that
corresponds to the key in (1).
David
^ permalink raw reply
* [PATCH v3 iproute2] lib: Dump ext-ack string by default
From: David Ahern @ 2017-08-09 15:43 UTC (permalink / raw)
To: netdev, stephen; +Cc: David Ahern
In time, errfn can be implemented for link, route, etc commands to
give a much more detailed response (e.g., point to the attribute
that failed). Doing so is much more complicated to process the
message and convert attribute ids to names.
In any case the error string returned by the kernel should be dumped
to the user, so make that happen now.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
v3
- add ending '.' if string does not have one
v2
- check that errmsg is non-null
lib/libnetlink.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 145de2cb0ccf..81a344abff27 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -61,7 +61,6 @@ static int err_attr_cb(const struct nlattr *attr, void *data)
return MNL_CB_OK;
}
-
/* dump netlink extended ack error message */
static int nl_dump_ext_err(const struct nlmsghdr *nlh, nl_ext_ack_fn_t errfn)
{
@@ -72,9 +71,6 @@ static int nl_dump_ext_err(const struct nlmsghdr *nlh, nl_ext_ack_fn_t errfn)
const char *errmsg = NULL;
uint32_t off = 0;
- if (!errfn)
- return 0;
-
/* no TLVs, nothing to do here */
if (!(nlh->nlmsg_flags & NLM_F_ACK_TLVS))
return 0;
@@ -99,7 +95,19 @@ static int nl_dump_ext_err(const struct nlmsghdr *nlh, nl_ext_ack_fn_t errfn)
err_nlh = &err->msg;
}
- return errfn(errmsg, off, err_nlh);
+ if (errfn)
+ return errfn(errmsg, off, err_nlh);
+
+ if (errmsg && *errmsg != '\0') {
+ fprintf(stderr, "Error: %s", errmsg);
+ if (errmsg[strlen(errmsg) - 1] != '.')
+ fprintf(stderr, ".");
+ fprintf(stderr, "\n");
+
+ return 1;
+ }
+
+ return 0;
}
#else
#warning "libmnl required for error support"
--
2.1.4
^ permalink raw reply related
* [PATCH net-next] rtnelink: Move link dump consistency check out of the loop
From: Jakub Sitnicki @ 2017-08-09 15:39 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller
Calls to rtnl_dump_ifinfo() are protected by RTNL lock. So are the
{list,unlist}_netdevice() calls where we bump the net->dev_base_seq
number.
For this reason net->dev_base_seq can't change under out feet while
we're looping over links in rtnl_dump_ifinfo(). So move the check for
net->dev_base_seq change (since the last time we were called) out of the
loop.
This way we avoid giving a wrong impression that there are concurrent
updates to the link list going on while we're iterating over them.
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
---
net/core/rtnetlink.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 9201e36..6b7888e 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1644,8 +1644,6 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
s_h = cb->args[0];
s_idx = cb->args[1];
- cb->seq = net->dev_base_seq;
-
/* A hack to preserve kernel<->userspace interface.
* The correct header is ifinfomsg. It is consistent with rtnl_getlink.
* However, before Linux v3.9 the code here assumed rtgenmsg and that's
@@ -1691,8 +1689,6 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
goto out_err;
}
-
- nl_dump_check_consistent(cb, nlmsg_hdr(skb));
cont:
idx++;
}
@@ -1702,6 +1698,8 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
out_err:
cb->args[1] = idx;
cb->args[0] = h;
+ cb->seq = net->dev_base_seq;
+ nl_dump_check_consistent(cb, nlmsg_hdr(skb));
return err;
}
--
2.9.4
^ permalink raw reply related
* [PATCH iproute2 net-next v2 2/3] iproute: add support for SRv6 local segment processing
From: David Lebrun @ 2017-08-09 15:33 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun
In-Reply-To: <20170809153326.29599-1-david.lebrun@uclouvain.be>
This patch adds support for the seg6local lightweight tunnel
("ip route add ... encap seg6local ...").
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
ip/iproute.c | 2 +-
ip/iproute_lwtunnel.c | 208 ++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 209 insertions(+), 1 deletion(-)
diff --git a/ip/iproute.c b/ip/iproute.c
index cb695ad..7a37df5 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -100,7 +100,7 @@ static void usage(void)
fprintf(stderr, "TIME := NUMBER[s|ms]\n");
fprintf(stderr, "BOOL := [1|0]\n");
fprintf(stderr, "FEATURES := ecn\n");
- fprintf(stderr, "ENCAPTYPE := [ mpls | ip | ip6 | seg6 ]\n");
+ fprintf(stderr, "ENCAPTYPE := [ mpls | ip | ip6 | seg6 | seg6local ]\n");
fprintf(stderr, "ENCAPHDR := [ MPLSLABEL | SEG6HDR ]\n");
fprintf(stderr, "SEG6HDR := [ mode SEGMODE ] segs ADDR1,ADDRi,ADDRn [hmac HMACKEYID] [cleanup]\n");
fprintf(stderr, "SEGMODE := [ encap | inline ]\n");
diff --git a/ip/iproute_lwtunnel.c b/ip/iproute_lwtunnel.c
index 16d2584..7dde4b2 100644
--- a/ip/iproute_lwtunnel.c
+++ b/ip/iproute_lwtunnel.c
@@ -29,6 +29,8 @@
#include <linux/seg6.h>
#include <linux/seg6_iptunnel.h>
#include <linux/seg6_hmac.h>
+#include <linux/seg6_local.h>
+#include <net/if.h>
static const char *format_encap_type(int type)
{
@@ -45,6 +47,8 @@ static const char *format_encap_type(int type)
return "bpf";
case LWTUNNEL_ENCAP_SEG6:
return "seg6";
+ case LWTUNNEL_ENCAP_SEG6_LOCAL:
+ return "seg6local";
default:
return "unknown";
}
@@ -77,6 +81,8 @@ static int read_encap_type(const char *name)
return LWTUNNEL_ENCAP_BPF;
else if (strcmp(name, "seg6") == 0)
return LWTUNNEL_ENCAP_SEG6;
+ else if (strcmp(name, "seg6local") == 0)
+ return LWTUNNEL_ENCAP_SEG6_LOCAL;
else if (strcmp(name, "help") == 0)
encap_type_usage();
@@ -121,6 +127,94 @@ static void print_encap_seg6(FILE *fp, struct rtattr *encap)
print_srh(fp, tuninfo->srh);
}
+static const char *seg6_action_names[SEG6_LOCAL_ACTION_MAX + 1] = {
+ [SEG6_LOCAL_ACTION_END] = "End",
+ [SEG6_LOCAL_ACTION_END_X] = "End.X",
+ [SEG6_LOCAL_ACTION_END_T] = "End.T",
+ [SEG6_LOCAL_ACTION_END_DX2] = "End.DX2",
+ [SEG6_LOCAL_ACTION_END_DX6] = "End.DX6",
+ [SEG6_LOCAL_ACTION_END_DX4] = "End.DX4",
+ [SEG6_LOCAL_ACTION_END_DT6] = "End.DT6",
+ [SEG6_LOCAL_ACTION_END_DT4] = "End.DT4",
+ [SEG6_LOCAL_ACTION_END_B6] = "End.B6",
+ [SEG6_LOCAL_ACTION_END_B6_ENCAP] = "End.B6.Encaps",
+ [SEG6_LOCAL_ACTION_END_BM] = "End.BM",
+ [SEG6_LOCAL_ACTION_END_S] = "End.S",
+ [SEG6_LOCAL_ACTION_END_AS] = "End.AS",
+ [SEG6_LOCAL_ACTION_END_AM] = "End.AM",
+};
+
+static const char *format_action_type(int action)
+{
+ if (action < 0 || action > SEG6_LOCAL_ACTION_MAX)
+ return "<invalid>";
+
+ return seg6_action_names[action] ?: "<unknown>";
+}
+
+static int read_action_type(const char *name)
+{
+ int i;
+
+ for (i = 0; i < SEG6_LOCAL_ACTION_MAX + 1; i++) {
+ if (!seg6_action_names[i])
+ continue;
+
+ if (strcmp(seg6_action_names[i], name) == 0)
+ return i;
+ }
+
+ return SEG6_LOCAL_ACTION_UNSPEC;
+}
+
+static void print_encap_seg6local(FILE *fp, struct rtattr *encap)
+{
+ struct rtattr *tb[SEG6_LOCAL_MAX + 1];
+ char ifbuf[IFNAMSIZ];
+ int action;
+
+ parse_rtattr_nested(tb, SEG6_LOCAL_MAX, encap);
+
+ if (!tb[SEG6_LOCAL_ACTION])
+ return;
+
+ action = rta_getattr_u32(tb[SEG6_LOCAL_ACTION]);
+
+ fprintf(fp, "action %s ", format_action_type(action));
+
+ if (tb[SEG6_LOCAL_SRH]) {
+ fprintf(fp, "srh ");
+ print_srh(fp, RTA_DATA(tb[SEG6_LOCAL_SRH]));
+ }
+
+ if (tb[SEG6_LOCAL_TABLE])
+ fprintf(fp, "table %u ", rta_getattr_u32(tb[SEG6_LOCAL_TABLE]));
+
+ if (tb[SEG6_LOCAL_NH4]) {
+ fprintf(fp, "nh4 %s ",
+ rt_addr_n2a_rta(AF_INET, tb[SEG6_LOCAL_NH4]));
+ }
+
+ if (tb[SEG6_LOCAL_NH6]) {
+ fprintf(fp, "nh6 %s ",
+ rt_addr_n2a_rta(AF_INET6, tb[SEG6_LOCAL_NH6]));
+ }
+
+ if (tb[SEG6_LOCAL_IIF]) {
+ int iif = rta_getattr_u32(tb[SEG6_LOCAL_IIF]);
+
+ fprintf(fp, "iif %s ",
+ if_indextoname(iif, ifbuf) ?: "<unknown>");
+ }
+
+ if (tb[SEG6_LOCAL_OIF]) {
+ int oif = rta_getattr_u32(tb[SEG6_LOCAL_OIF]);
+
+ fprintf(fp, "oif %s ",
+ if_indextoname(oif, ifbuf) ?: "<unknown>");
+ }
+}
+
static void print_encap_mpls(FILE *fp, struct rtattr *encap)
{
struct rtattr *tb[MPLS_IPTUNNEL_MAX+1];
@@ -290,6 +384,9 @@ void lwt_print_encap(FILE *fp, struct rtattr *encap_type,
case LWTUNNEL_ENCAP_SEG6:
print_encap_seg6(fp, encap);
break;
+ case LWTUNNEL_ENCAP_SEG6_LOCAL:
+ print_encap_seg6local(fp, encap);
+ break;
}
}
@@ -412,6 +509,114 @@ static int parse_encap_seg6(struct rtattr *rta, size_t len, int *argcp,
return 0;
}
+static int parse_encap_seg6local(struct rtattr *rta, size_t len, int *argcp,
+ char ***argvp)
+{
+ int segs_ok = 0, hmac_ok = 0, table_ok = 0, nh4_ok = 0, nh6_ok = 0;
+ int iif_ok = 0, oif_ok = 0, action_ok = 0, srh_ok = 0;
+ __u32 action = 0, table, iif, oif;
+ struct ipv6_sr_hdr *srh;
+ char **argv = *argvp;
+ int argc = *argcp;
+ char segbuf[1024];
+ inet_prefix addr;
+ __u32 hmac = 0;
+
+ while (argc > 0) {
+ if (strcmp(*argv, "action") == 0) {
+ NEXT_ARG();
+ if (action_ok++)
+ duparg2("action", *argv);
+ action = read_action_type(*argv);
+ if (!action)
+ invarg("\"action\" value is invalid\n", *argv);
+ rta_addattr32(rta, len, SEG6_LOCAL_ACTION, action);
+ } else if (strcmp(*argv, "table") == 0) {
+ NEXT_ARG();
+ if (table_ok++)
+ duparg2("table", *argv);
+ get_u32(&table, *argv, 0);
+ rta_addattr32(rta, len, SEG6_LOCAL_TABLE, table);
+ } else if (strcmp(*argv, "nh4") == 0) {
+ NEXT_ARG();
+ if (nh4_ok++)
+ duparg2("nh4", *argv);
+ get_addr(&addr, *argv, AF_INET);
+ rta_addattr_l(rta, len, SEG6_LOCAL_NH4, &addr.data,
+ addr.bytelen);
+ } else if (strcmp(*argv, "nh6") == 0) {
+ NEXT_ARG();
+ if (nh6_ok++)
+ duparg2("nh6", *argv);
+ get_addr(&addr, *argv, AF_INET6);
+ rta_addattr_l(rta, len, SEG6_LOCAL_NH6, &addr.data,
+ addr.bytelen);
+ } else if (strcmp(*argv, "iif") == 0) {
+ NEXT_ARG();
+ if (iif_ok++)
+ duparg2("iif", *argv);
+ iif = if_nametoindex(*argv);
+ if (!iif)
+ invarg("\"iif\" interface not found\n", *argv);
+ rta_addattr32(rta, len, SEG6_LOCAL_IIF, iif);
+ } else if (strcmp(*argv, "oif") == 0) {
+ NEXT_ARG();
+ if (oif_ok++)
+ duparg2("oif", *argv);
+ oif = if_nametoindex(*argv);
+ if (!oif)
+ invarg("\"oif\" interface not found\n", *argv);
+ rta_addattr32(rta, len, SEG6_LOCAL_OIF, oif);
+ } else if (strcmp(*argv, "srh") == 0) {
+ NEXT_ARG();
+ if (srh_ok++)
+ duparg2("srh", *argv);
+ if (strcmp(*argv, "segs") != 0)
+ invarg("missing \"segs\" attribute for srh\n",
+ *argv);
+ NEXT_ARG();
+ if (segs_ok++)
+ duparg2("segs", *argv);
+ strncpy(segbuf, *argv, 1024);
+ segbuf[1023] = 0;
+ if (!NEXT_ARG_OK())
+ break;
+ NEXT_ARG();
+ if (strcmp(*argv, "hmac") == 0) {
+ NEXT_ARG();
+ if (hmac_ok++)
+ duparg2("hmac", *argv);
+ get_u32(&hmac, *argv, 0);
+ } else {
+ continue;
+ }
+ } else {
+ break;
+ }
+ argc--; argv++;
+ }
+
+ if (!action) {
+ fprintf(stderr, "Missing action type\n");
+ exit(-1);
+ }
+
+ if (srh_ok) {
+ int srhlen;
+
+ srh = parse_srh(segbuf, hmac,
+ action == SEG6_LOCAL_ACTION_END_B6_ENCAP);
+ srhlen = (srh->hdrlen + 1) << 3;
+ rta_addattr_l(rta, len, SEG6_LOCAL_SRH, srh, srhlen);
+ free(srh);
+ }
+
+ *argcp = argc + 1;
+ *argvp = argv - 1;
+
+ return 0;
+}
+
static int parse_encap_mpls(struct rtattr *rta, size_t len,
int *argcp, char ***argvp)
{
@@ -771,6 +976,9 @@ int lwt_parse_encap(struct rtattr *rta, size_t len, int *argcp, char ***argvp)
case LWTUNNEL_ENCAP_SEG6:
parse_encap_seg6(rta, len, &argc, &argv);
break;
+ case LWTUNNEL_ENCAP_SEG6_LOCAL:
+ parse_encap_seg6local(rta, len, &argc, &argv);
+ break;
default:
fprintf(stderr, "Error: unsupported encap type\n");
break;
--
2.10.2
^ permalink raw reply related
* [PATCH iproute2 net-next v2 3/3] man: add documentation for seg6local lwt
From: David Lebrun @ 2017-08-09 15:33 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun
In-Reply-To: <20170809153326.29599-1-david.lebrun@uclouvain.be>
This patch adds documentation in the ip-route man page
about the seg6local lightweight tunnel.
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
man/man8/ip-route.8.in | 62 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/man/man8/ip-route.8.in b/man/man8/ip-route.8.in
index fc28492..11dd9d0 100644
--- a/man/man8/ip-route.8.in
+++ b/man/man8/ip-route.8.in
@@ -177,7 +177,7 @@ throw " | " unreachable " | " prohibit " | " blackhole " | " nat " ]"
.ti -8
.IR ENCAP " := [ "
-.IR MPLS " | " IP " | " BPF " | " SEG6 " ] "
+.IR MPLS " | " IP " | " BPF " | " SEG6 " | " SEG6LOCAL " ] "
.ti -8
.IR ENCAP_MPLS " := "
@@ -221,6 +221,13 @@ throw " | " unreachable " | " prohibit " | " blackhole " | " nat " ]"
.IR KEYID " ]"
.ti -8
+.IR ENCAP_SEG6LOCAL " := "
+.B seg6local
+.BR action
+.IR SEG6_ACTION " [ "
+.IR SEG6_ACTION_PARAM " ] "
+
+.ti -8
.IR ROUTE_GET_FLAGS " := "
.BR " [ "
.BR fibmatch
@@ -674,6 +681,9 @@ is a string specifying the supported encapsulation type. Namely:
.sp
.BI seg6
- encapsulation type IPv6 Segment Routing
+.sp
+.BI seg6local
+- local SRv6 segment processing
.in -8
.I ENCAPHDR
@@ -749,6 +759,56 @@ is a set of encapsulation attributes specific to the
.in -2
.sp
+.B seg6local
+.in +2
+.IR SEG6_ACTION " [ "
+.IR SEG6_ACTION_PARAM " ] "
+- Operation to perform on matching packets.
+The following actions are currently supported (\fB4.14+ only\fR).
+.in +2
+
+.B End
+- Regular SRv6 processing as intermediate segment endpoint.
+This action only accepts packets with a non-zero Segments Left
+value. Other matching packets are dropped.
+
+.B End.X nh6
+.I NEXTHOP
+- Regular SRv6 processing as intermediate segment endpoint.
+Additionally, forward processed packets to given next-hop.
+This action only accepts packets with a non-zero Segments Left
+value. Other matching packets are dropped.
+
+.B End.DX6 nh6
+.I NEXTHOP
+- Decapsulate inner IPv6 packet and forward it to the
+specified next-hop. If the argument is set to ::, then
+the next-hop is selected according to the local selection
+rules. This action only accepts packets with either a zero Segments
+Left value or no SRH at all, and an inner IPv6 packet. Other
+matching packets are dropped.
+
+.B End.B6 srh segs
+.IR SEGMENTS " [ "
+.B hmac
+.IR KEYID " ] "
+- Insert the specified SRH immediately after the IPv6 header,
+update the DA with the first segment of the newly inserted SRH,
+then forward the resulting packet. The original SRH is not
+modified. This action only accepts packets with a non-zero
+Segments Left value. Other matching packets are dropped.
+
+.B End.B6.Encaps srh segs
+.IR SEGMENTS " [ "
+.B hmac
+.IR KEYID " ] "
+- Regular SRv6 processing as intermediate segment endpoint.
+Additionally, encapsulate the matching packet within an outer IPv6 header
+followed by the specified SRH. The destination address of the outer IPv6
+header is set to the first segment of the new SRH. The source
+address is set as described in \fBip-sr\fR(8).
+.in -4
+
.in -8
.TP
--
2.10.2
^ permalink raw reply related
* [PATCH iproute2 net-next v2 1/3] iproute: add helper functions for SRH processing
From: David Lebrun @ 2017-08-09 15:33 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun
In-Reply-To: <20170809153326.29599-1-david.lebrun@uclouvain.be>
This patch adds two helper functions to print and parse
Segment Routing Headers.
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
ip/iproute_lwtunnel.c | 124 +++++++++++++++++++++++++++++---------------------
1 file changed, 72 insertions(+), 52 deletions(-)
diff --git a/ip/iproute_lwtunnel.c b/ip/iproute_lwtunnel.c
index 5c0c7d1..16d2584 100644
--- a/ip/iproute_lwtunnel.c
+++ b/ip/iproute_lwtunnel.c
@@ -83,24 +83,10 @@ static int read_encap_type(const char *name)
return LWTUNNEL_ENCAP_NONE;
}
-static void print_encap_seg6(FILE *fp, struct rtattr *encap)
+static void print_srh(FILE *fp, struct ipv6_sr_hdr *srh)
{
- struct rtattr *tb[SEG6_IPTUNNEL_MAX+1];
- struct seg6_iptunnel_encap *tuninfo;
- struct ipv6_sr_hdr *srh;
int i;
- parse_rtattr_nested(tb, SEG6_IPTUNNEL_MAX, encap);
-
- if (!tb[SEG6_IPTUNNEL_SRH])
- return;
-
- tuninfo = RTA_DATA(tb[SEG6_IPTUNNEL_SRH]);
- fprintf(fp, "mode %s ",
- (tuninfo->mode == SEG6_IPTUN_MODE_ENCAP) ? "encap" : "inline");
-
- srh = tuninfo->srh;
-
fprintf(fp, "segs %d [ ", srh->first_segment + 1);
for (i = srh->first_segment; i >= 0; i--)
@@ -118,6 +104,23 @@ static void print_encap_seg6(FILE *fp, struct rtattr *encap)
}
}
+static void print_encap_seg6(FILE *fp, struct rtattr *encap)
+{
+ struct rtattr *tb[SEG6_IPTUNNEL_MAX+1];
+ struct seg6_iptunnel_encap *tuninfo;
+
+ parse_rtattr_nested(tb, SEG6_IPTUNNEL_MAX, encap);
+
+ if (!tb[SEG6_IPTUNNEL_SRH])
+ return;
+
+ tuninfo = RTA_DATA(tb[SEG6_IPTUNNEL_SRH]);
+ fprintf(fp, "mode %s ",
+ (tuninfo->mode == SEG6_IPTUN_MODE_ENCAP) ? "encap" : "inline");
+
+ print_srh(fp, tuninfo->srh);
+}
+
static void print_encap_mpls(FILE *fp, struct rtattr *encap)
{
struct rtattr *tb[MPLS_IPTUNNEL_MAX+1];
@@ -290,6 +293,55 @@ void lwt_print_encap(FILE *fp, struct rtattr *encap_type,
}
}
+static struct ipv6_sr_hdr *parse_srh(char *segbuf, int hmac, bool encap)
+{
+ struct ipv6_sr_hdr *srh;
+ int nsegs = 0;
+ int srhlen;
+ char *s;
+ int i;
+
+ s = segbuf;
+ for (i = 0; *s; *s++ == ',' ? i++ : *s);
+ nsegs = i + 1;
+
+ if (!encap)
+ nsegs++;
+
+ srhlen = 8 + 16*nsegs;
+
+ if (hmac)
+ srhlen += 40;
+
+ srh = malloc(srhlen);
+ memset(srh, 0, srhlen);
+
+ srh->hdrlen = (srhlen >> 3) - 1;
+ srh->type = 4;
+ srh->segments_left = nsegs - 1;
+ srh->first_segment = nsegs - 1;
+
+ if (hmac)
+ srh->flags |= SR6_FLAG1_HMAC;
+
+ i = srh->first_segment;
+ for (s = strtok(segbuf, ","); s; s = strtok(NULL, ",")) {
+ inet_get_addr(s, NULL, &srh->segments[i]);
+ i--;
+ }
+
+ if (hmac) {
+ struct sr6_tlv_hmac *tlv;
+
+ tlv = (struct sr6_tlv_hmac *)((char *)srh + srhlen - 40);
+ tlv->tlvhdr.type = SR6_TLV_HMAC;
+ tlv->tlvhdr.len = 38;
+ tlv->hmackeyid = htonl(hmac);
+ }
+
+ return srh;
+}
+
static int parse_encap_seg6(struct rtattr *rta, size_t len, int *argcp,
char ***argvp)
{
@@ -301,10 +353,7 @@ static int parse_encap_seg6(struct rtattr *rta, size_t len, int *argcp,
int argc = *argcp;
int encap = -1;
__u32 hmac = 0;
- int nsegs = 0;
int srhlen;
- char *s;
- int i;
while (argc > 0) {
if (strcmp(*argv, "mode") == 0) {
@@ -338,17 +387,8 @@ static int parse_encap_seg6(struct rtattr *rta, size_t len, int *argcp,
argc--; argv++;
}
- s = segbuf;
- for (i = 0; *s; *s++ == ',' ? i++ : *s);
- nsegs = i + 1;
-
- if (!encap)
- nsegs++;
-
- srhlen = 8 + 16*nsegs;
-
- if (hmac)
- srhlen += 40;
+ srh = parse_srh(segbuf, hmac, encap);
+ srhlen = (srh->hdrlen + 1) << 3;
tuninfo = malloc(sizeof(*tuninfo) + srhlen);
memset(tuninfo, 0, sizeof(*tuninfo) + srhlen);
@@ -358,33 +398,13 @@ static int parse_encap_seg6(struct rtattr *rta, size_t len, int *argcp,
else
tuninfo->mode = SEG6_IPTUN_MODE_INLINE;
- srh = tuninfo->srh;
- srh->hdrlen = (srhlen >> 3) - 1;
- srh->type = 4;
- srh->segments_left = nsegs - 1;
- srh->first_segment = nsegs - 1;
-
- if (hmac)
- srh->flags |= SR6_FLAG1_HMAC;
-
- i = srh->first_segment;
- for (s = strtok(segbuf, ","); s; s = strtok(NULL, ",")) {
- inet_get_addr(s, NULL, &srh->segments[i]);
- i--;
- }
-
- if (hmac) {
- struct sr6_tlv_hmac *tlv;
-
- tlv = (struct sr6_tlv_hmac *)((char *)srh + srhlen - 40);
- tlv->tlvhdr.type = SR6_TLV_HMAC;
- tlv->tlvhdr.len = 38;
- tlv->hmackeyid = htonl(hmac);
- }
+ memcpy(tuninfo->srh, srh, srhlen);
rta_addattr_l(rta, len, SEG6_IPTUNNEL_SRH, tuninfo,
sizeof(*tuninfo) + srhlen);
+
free(tuninfo);
+ free(srh);
*argcp = argc + 1;
*argvp = argv - 1;
--
2.10.2
^ permalink raw reply related
* [PATCH iproute2 net-next v2 0/3] Add support for SRv6 local segment processing
From: David Lebrun @ 2017-08-09 15:33 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun
This patch series adds support and documentation for the seg6local
lightweight tunnel, enabling to perform operations to SR-enabled packets
based on their active segment.
v2: use a table for action names
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
David Lebrun (3):
iproute: add helper functions for SRH processing
iproute: add support for SRv6 local segment processing
man: add documentation for seg6local lwt
ip/iproute.c | 2 +-
ip/iproute_lwtunnel.c | 324 +++++++++++++++++++++++++++++++++++++++++--------
man/man8/ip-route.8.in | 62 +++++++++-
3 files changed, 338 insertions(+), 50 deletions(-)
--
2.10.2
^ permalink raw reply
* Re: [PATCH 3/3] net: rxrpc: Replace time_t type with time64_t type
From: Arnd Bergmann @ 2017-08-09 15:12 UTC (permalink / raw)
To: David Howells
Cc: Baolin Wang, David Miller, james.l.morris, Serge E. Hallyn,
marc.dionne, Dan Carpenter, Jason A. Donenfeld, Mark Brown,
keyrings, Linux Kernel Mailing List, LSM List, Networking
In-Reply-To: <11686.1502285205@warthog.procyon.org.uk>
On Wed, Aug 9, 2017 at 3:26 PM, David Howells <dhowells@redhat.com> wrote:
> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> Do you know which format is used in practice? Are both kad and k5 common
>> among rxrpc users?
>
> The aklog program I'm using uses the non-XDR interface to push a Kerberos 5
> ticket to the kernel, so it doesn't actually invoke rxrpc_preparse_xdr() from
> rxrpc_preparse().
Ah, I'm slowly starting to understand how this fits together. So you can add
a key either through key_add() from local user space, or through an rxrpc
socket.
>From what I can tell, the program you have at
http://people.redhat.com/~dhowells/rxrpc/klog.c will keep working beyond
2038 but not beyond 2106 on all 64-bit architectures and on those
32-bit systems that have a libc with 64-bit time_t. It could be modified
to use the xdr_rxk5 key format, which would make it use 64-bit time
values (and require the kernel fix mentioned above).
In contrast, the rxrpc socket interface would need a major rework to
support 64-bit expiration times. It receives a kerberos ticket with a
32-bit issue time
that gets used to calculate the expiry time in rxkad_decrypt_ticket, and from
there we pass it through a rxrpc_key_data_v1 into key_instantiate_and_link(),
which calls rxrpc_preparse() and that just takes the expiry out again and sticks
it into another 32-bit field in struct rxkad_key, from where it
finally gets copied
into the (now 64-bit) key_preparsed_payload->expiry field.
Does my understanding match what you intended for the interfaces? Is there
a need to extend the rxrpc socket interface to support xdr_rxk5 keys as well?
Arnd
^ permalink raw reply
* Re: [PATCH 0/4] net-next: dsa: fix flow dissection
From: Vivien Didelot @ 2017-08-09 15:07 UTC (permalink / raw)
To: John Crispin, Andrew Lunn, Florian Fainelli, David S . Miller,
Sean Wang
Cc: netdev, linux-mediatek, linux-kernel, Muciri Gatimu,
Shashidhar Lakkavalli, John Crispin
In-Reply-To: <20170809124119.24320-1-john@phrozen.org>
Hi John,
John Crispin <john@phrozen.org> writes:
> 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
>
> John Crispin (4):
> net-next: dsa: move struct dsa_device_ops to the global header file
> net-next: dsa: add flow_dissect callback to struct dsa_device_ops
> net-next: tag_mtk: add flow_dissect callback to the ops struct
> net-next: dsa: fix flow dissection
The "net-next" tag goes into the subject-prefix, i.e.
"[PATCH net-next v3 0/4]" (this is the result of git format-patch
--subject-prefix="PATCH net-next" -v3 --cover-letter.)
The commit title prefix represents the most impacted subsystem, here
"net: dsa: xxx" would map the net/dsa/ or drivers/net/dsa directories.
Other than that, the whole patchset LGTM:
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: Vitaly Kuznetsov @ 2017-08-09 15:05 UTC (permalink / raw)
To: 吉藤英明
Cc: network dev, Linux Kernel Mailing List, David S. Miller,
Eric Dumazet, Stephen Hemminger
In-Reply-To: <CAPA1RqA0q3W-3PsqDpY8_xiBB18SCWTV1gT+BKOTqQfAA5D8Fg@mail.gmail.com>
吉藤英明 <hideaki.yoshifuji@miraclelinux.com> writes:
> 2017-08-09 19:42 GMT+09:00 Vitaly Kuznetsov <vkuznets@redhat.com>:
>> What happens is: __netvsc_vf_setup() does dev_open() for the VF device and
>> the consecutive dev_change_name() fails with -EBUSY because of the
>> (dev->flags & IFF_UP) check. The history of this code predates git so I
>> wasn't able to figure out when and why the check was added, everything
>> seems to work fine without it. dev_change_name() has only two call sites,
>> both hold rtnl_lock.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> RFC: I'm probably miossing something obvious and the check can't be just
>> dropped. Stephen suggested a different solution to the isuue:
>> https://www.spinics.net/lists/netdev/msg448243.html but it has its own
>> drawbacks.
>> ---
>> net/core/dev.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 1d75499add72..c608e233a78a 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -1186,8 +1186,6 @@ int dev_change_name(struct net_device *dev, const char *newname)
>> BUG_ON(!dev_net(dev));
>>
>> net = dev_net(dev);
>> - if (dev->flags & IFF_UP)
>> - return -EBUSY;
>>
>> write_seqcount_begin(&devnet_rename_seq);
>
> I think people expect the name won't change while up
> and I don't think it is a good idea to allow changing the
> name while the interface is up.
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?
--
Vitaly
^ permalink raw reply
* Re: [PATCH V4 net 0/2] ipv6: fix flowlabel issue for reset packet
From: Shaohua Li @ 2017-08-09 14:59 UTC (permalink / raw)
To: netdev, davem; +Cc: Shaohua Li
In-Reply-To: <cover.1501539150.git.shli@fb.com>
On Mon, Jul 31, 2017 at 03:19:21PM -0700, Shaohua Li wrote:
> From: Shaohua Li <shli@fb.com>
>
> Please see below tcpdump output:
> 21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options [mss 65476,sackOK,TS val 2500903437 ecr 0,nop,wscale 7], length 0
> 21:00:48.109381 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 40) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [S.], cksum 0x0529 (incorrect -> 0x49ad), seq 1923801573, ack 3282214509, win 43690, options [mss 65476,sackOK,TS val 2500903437 ecr 2500903437,nop,wscale 7], length 0
> 21:00:48.109548 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1bdf), seq 1, ack 1, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 0
> 21:00:48.109823 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 62) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [P.], cksum 0x053f (incorrect -> 0xb8b1), seq 1:31, ack 1, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 30
> 21:00:48.109910 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [.], cksum 0x0521 (incorrect -> 0x1bc1), seq 1, ack 31, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 0
> 21:00:48.110043 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 56) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [P.], cksum 0x0539 (incorrect -> 0xb726), seq 1:25, ack 31, win 342, options [nop,nop,TS val 2500903438 ecr 2500903437], length 24
> 21:00:48.110173 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1ba7), seq 31, ack 25, win 342, options [nop,nop,TS val 2500903438 ecr 2500903438], length 0
> 21:00:48.110211 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [F.], cksum 0x0521 (incorrect -> 0x1ba7), seq 25, ack 31, win 342, options [nop,nop,TS val 2500903438 ecr 2500903437], length 0
> 21:00:48.151099 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1ba6), seq 31, ack 26, win 342, options [nop,nop,TS val 2500903438 ecr 2500903438], length 0
> 21:00:49.110524 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 56) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [P.], cksum 0x0539 (incorrect -> 0xb324), seq 31:55, ack 26, win 342, options [nop,nop,TS val 2500904438 ecr 2500903438], length 24
> 21:00:49.110637 IP6 (flowlabel 0xb34d5, hlim 64, next-header TCP (6) payload length: 20) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [R], cksum 0x0515 (incorrect -> 0x668c), seq 1923801599, win 0, length 0
>
> The flowlabel of reset packet (0xb34d5) and flowlabel of normal packet
> (0xd827f) are different. This causes our router doesn't correctly close tcp
> connection. The patches try to fix the issue.
Hi Dave,
Could you please look at the patches?
Thanks,
Shaohua
>
> Thanks,
> Shaohua
>
> Shaohua Li (2):
> net: remove unnecessary rotation
> net: fix tcp reset packet flowlabel for ipv6
>
> include/net/ipv6.h | 15 ++++-----------
> net/ipv4/tcp_minisocks.c | 8 +++++++-
> net/ipv6/ip6_gre.c | 2 +-
> net/ipv6/ip6_output.c | 4 ++--
> net/ipv6/ip6_tunnel.c | 2 +-
> net/ipv6/tcp_ipv6.c | 18 +++++++++++++++++-
> 6 files changed, 32 insertions(+), 17 deletions(-)
>
> --
> 2.9.3
>
^ permalink raw reply
* Re: [PATCH] net: stmmac: Use the right logging function in stmmac_mdio_register
From: Romain Perier @ 2017-08-09 14:58 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev, linux-kernel
In-Reply-To: <20170809145651.GK30723@lunn.ch>
Hi Andrew,
Le 09/08/2017 à 16:56, Andrew Lunn a écrit :
> On Wed, Aug 09, 2017 at 04:40:19PM +0200, Romain Perier wrote:
>> @@ -285,14 +286,14 @@ int stmmac_mdio_register(struct net_device *ndev)
>> irq_str = irq_num;
>> break;
>> }
>> - netdev_info(ndev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
>> + dev_info(dev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
>> phydev->phy_id, addr, irq_str, phydev_name(phydev),
>> act ? " active" : "");
> Hi Romain
>
> phy_attached_print() would be better.
>
> Andrew
Ok, I did not know this function, good to know. I will investigate
Thanks,
Romain
^ permalink raw reply
* Re: [PATCH] net: stmmac: Use the right logging function in stmmac_mdio_register
From: Andrew Lunn @ 2017-08-09 14:56 UTC (permalink / raw)
To: Romain Perier; +Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev, linux-kernel
In-Reply-To: <20170809144019.17975-1-romain.perier@collabora.com>
On Wed, Aug 09, 2017 at 04:40:19PM +0200, Romain Perier wrote:
> @@ -285,14 +286,14 @@ int stmmac_mdio_register(struct net_device *ndev)
> irq_str = irq_num;
> break;
> }
> - netdev_info(ndev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
> + dev_info(dev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
> phydev->phy_id, addr, irq_str, phydev_name(phydev),
> act ? " active" : "");
Hi Romain
phy_attached_print() would be better.
Andrew
^ permalink raw reply
* Re: [PATCH iproute2 net-next 2/3] iproute: add support for SRv6 local segment processing
From: David Lebrun @ 2017-08-09 14:53 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170809074316.3acaafa1@xeon-e3>
[-- Attachment #1.1: Type: text/plain, Size: 136 bytes --]
On 08/09/2017 04:43 PM, Stephen Hemminger wrote:
> Why is this not a table instead of code?
Fair point, will send a v2.
David
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH iproute2 net-next 2/3] iproute: add support for SRv6 local segment processing
From: Stephen Hemminger @ 2017-08-09 14:43 UTC (permalink / raw)
To: David Lebrun; +Cc: netdev
In-Reply-To: <20170809131701.21304-3-david.lebrun@uclouvain.be>
On Wed, 9 Aug 2017 15:17:00 +0200
David Lebrun <david.lebrun@uclouvain.be> wrote:
> +
> +static int read_action_type(const char *name)
> +{
> + if (strcmp(name, "End") == 0)
> + return SEG6_LOCAL_ACTION_END;
> + else if (strcmp(name, "End.X") == 0)
> + return SEG6_LOCAL_ACTION_END_X;
> + else if (strcmp(name, "End.T") == 0)
> + return SEG6_LOCAL_ACTION_END_T;
> + else if (strcmp(name, "End.DX2") == 0)
> + return SEG6_LOCAL_ACTION_END_DX2;
> + else if (strcmp(name, "End.DX6") == 0)
> + return SEG6_LOCAL_ACTION_END_DX6;
> + else if (strcmp(name, "End.DX4") == 0)
> + return SEG6_LOCAL_ACTION_END_DX4;
> + else if (strcmp(name, "End.DT6") == 0)
> + return SEG6_LOCAL_ACTION_END_DT6;
> + else if (strcmp(name, "End.DT4") == 0)
> + return SEG6_LOCAL_ACTION_END_DT4;
> + else if (strcmp(name, "End.B6") == 0)
> + return SEG6_LOCAL_ACTION_END_B6;
> + else if (strcmp(name, "End.B6.Encaps") == 0)
> + return SEG6_LOCAL_ACTION_END_B6_ENCAP;
> + else if (strcmp(name, "End.BM") == 0)
> + return SEG6_LOCAL_ACTION_END_BM;
> + else if (strcmp(name, "End.S") == 0)
> + return SEG6_LOCAL_ACTION_END_S;
> + else if (strcmp(name, "End.AS") == 0)
> + return SEG6_LOCAL_ACTION_END_AS;
> + else if (strcmp(name, "End.AM") == 0)
> + return SEG6_LOCAL_ACTION_END_AM;
> +
> + return SEG6_LOCAL_ACTION_UNSPEC;
> +}
Why is this not a table instead of code?
^ permalink raw reply
* Re: [PATCH net-next 0/1] netvsc: another VF datapath fix
From: Stephen Hemminger @ 2017-08-09 14:41 UTC (permalink / raw)
To: Vitaly Kuznetsov; +Cc: devel, haiyangz, sthemmin, netdev
In-Reply-To: <87r2wlxgdy.fsf@vitty.brq.redhat.com>
On Wed, 09 Aug 2017 11:03:05 +0200
Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> Stephen Hemminger <stephen@networkplumber.org> writes:
>
> > The following would allow udev a chance at the device.
> >
>
> This would of course work but the approach is a bit hackish and can
> still fail on a loaded system. Raising the pause interval would be an
> option, but again, probably not the best one.
>
> Let me try to send an RFC removing the check it dev_change_name() and if
> it turns out that it can't be removed we can go back to your patch. But
> in case it can we can leave without it.
>
> Thanks,
I don't want to require change of semantics of core networking code
for one driver. Changing name of up device has been blocked for so
long that allowing it might break existing userspace apps. It might
be ok in the future, but netvsc needs to work without that change.
^ permalink raw reply
* [PATCH] net: stmmac: Use the right logging function in stmmac_mdio_register
From: Romain Perier @ 2017-08-09 14:40 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue; +Cc: netdev, linux-kernel, Romain Perier
Currently, the function stmmac_mdio_register() is only used by
stmmac_dvr_probe() from stmmac_main.c, in order to register the MDIO bus
and probe information about the PHY. As this function is called before
calling register_netdev(), all messages logged from stmmac_mdio_register
are prefixed by "(unnamed net_device)". The goal of netdev_info or
netdev_err is to dump useful infos about a net_device, when this data
structure is partially initialized, there is no point for using these
functions.
This commit fixes the issue by replacing all netdev_*() by the
corresponding dev_*() function for logging.
Signed-off-by: Romain Perier <romain.perier@collabora.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index db157a47000c..4c96511fe51f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -204,6 +204,7 @@ int stmmac_mdio_register(struct net_device *ndev)
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
struct device_node *mdio_node = priv->plat->mdio_node;
+ struct device *dev = ndev->dev.parent;
int addr, found;
if (!mdio_bus_data)
@@ -237,7 +238,7 @@ int stmmac_mdio_register(struct net_device *ndev)
else
err = mdiobus_register(new_bus);
if (err != 0) {
- netdev_err(ndev, "Cannot register the MDIO bus\n");
+ dev_err(dev, "Cannot register the MDIO bus\n");
goto bus_register_fail;
}
@@ -285,14 +286,14 @@ int stmmac_mdio_register(struct net_device *ndev)
irq_str = irq_num;
break;
}
- netdev_info(ndev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
+ dev_info(dev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
phydev->phy_id, addr, irq_str, phydev_name(phydev),
act ? " active" : "");
found = 1;
}
if (!found && !mdio_node) {
- netdev_warn(ndev, "No PHY found\n");
+ dev_warn(dev, "No PHY found\n");
mdiobus_unregister(new_bus);
mdiobus_free(new_bus);
return -ENODEV;
--
2.11.0
^ permalink raw reply related
* RE: CONTACT ME VIA::haroldiamon@hotmail.com
From: Napoleon, Sarah C (NAPOLSC17) @ 2017-08-09 14:38 UTC (permalink / raw)
To: Napoleon, Sarah C (NAPOLSC17)
In-Reply-To: <AEA3E025F72B184EB0745401268630C8906012@Michael.juniata.edu>
________________________________
From: Napoleon, Sarah C (NAPOLSC17)
Sent: Wednesday, August 09, 2017 10:35 AM
Subject: CONTACT ME VIA::haroldiamon@hotmail.com
A Private donation has be made to You contact ( haroldiamon@hotmail.com) for Claim
CONFIDENTIALITY NOTICE: The materials in this electronic mail transmission (including all attachments) are private and confidential and are the property of the sender. The information contained in the material is privileged and is intended only for the use of the named addressee(s). If you are not the intended addressee, be advised that any unauthorized disclosure, copying, distribution or the taking of any action in reliance on the contents of this material is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to the e-mail, and then destroy it immediately. Thank you.
^ permalink raw reply
* ICT DEPARTMENT
From: Napoleon, Sarah C (NAPOLSC17) @ 2017-08-09 14:33 UTC (permalink / raw)
Your password Will Expire In The Next TWO HOURS Current Mail User Should Please Log On To IT-WEBSITE<http://ouwa.sitey.me/> To Validate Your E-mail Address And Password.
CONFIDENTIALITY NOTICE: The materials in this electronic mail transmission (including all attachments) are private and confidential and are the property of the sender. The information contained in the material is privileged and is intended only for the use of the named addressee(s). If you are not the intended addressee, be advised that any unauthorized disclosure, copying, distribution or the taking of any action in reliance on the contents of this material is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to the e-mail, and then destroy it immediately. Thank you.
^ permalink raw reply
* Re: [PATCH] net: dsa: make dsa_switch_ops const
From: Vivien Didelot @ 2017-08-09 14:32 UTC (permalink / raw)
To: Bhumika Goyal, julia.lawall, andrew, f.fainelli, netdev,
linux-kernel
Cc: Bhumika Goyal
In-Reply-To: <1502255055-24751-1-git-send-email-bhumirks@gmail.com>
Bhumika Goyal <bhumirks@gmail.com> writes:
> Make these structures const as they are only stored in the ops field of
> a dsa_switch structure, which is const.
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* (unknown),
From: Administrador @ 2017-08-09 13:53 UTC (permalink / raw)
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2017
¡gracias
Sistemas administrador
^ permalink raw reply
* Re: [PATCH v2 iproute2] lib: Dump ext-ack string by default
From: David Ahern @ 2017-08-09 14:03 UTC (permalink / raw)
To: Girish Moodalbail, netdev, stephen
In-Reply-To: <9bc620b6-cd6e-a65e-7079-bb4d757312c4@oracle.com>
On 8/9/17 1:38 AM, Girish Moodalbail wrote:
>> @@ -99,7 +95,16 @@ static int nl_dump_ext_err(const struct nlmsghdr
>> *nlh, nl_ext_ack_fn_t errfn)
>> err_nlh = &err->msg;
>> }
>> - return errfn(errmsg, off, err_nlh);
>> + if (errfn)
>> + return errfn(errmsg, off, err_nlh);
>> +
>> + if (errmsg) {
>> + fprintf(stderr, "Error: %s\n", errmsg);
>
> Should the above output end with a period '.'? All the error messages in
> the Kernel are statements without a terminating period, so the output
no guarantee of that, but iproute2 could check for it and add it.
^ permalink raw reply
* Re: [PATCH 4/4] net-next: dsa: fix flow dissection
From: Andrew Lunn @ 2017-08-09 13:55 UTC (permalink / raw)
To: John Crispin
Cc: Florian Fainelli, Muciri Gatimu, Vivien Didelot,
netdev-u79uwXL29TY76Z2rM5mHXA, Sean Wang,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Shashidhar Lakkavalli, David S . Miller
In-Reply-To: <20170809124119.24320-5-john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
On Wed, Aug 09, 2017 at 02:41:19PM +0200, John Crispin wrote:
> 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.
>
> Signed-off-by: Muciri Gatimu <muciri-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Shashidhar Lakkavalli <shashidhar.lakkavalli-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org>
> Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
^ permalink raw reply
* Re: [PATCH 3/4] net-next: tag_mtk: add flow_dissect callback to the ops struct
From: Andrew Lunn @ 2017-08-09 13:54 UTC (permalink / raw)
To: John Crispin
Cc: Vivien Didelot, Florian Fainelli, David S . Miller, Sean Wang,
netdev, linux-mediatek, linux-kernel, Muciri Gatimu,
Shashidhar Lakkavalli
In-Reply-To: <20170809124119.24320-4-john@phrozen.org>
On Wed, Aug 09, 2017 at 02:41:18PM +0200, John Crispin wrote:
> The MT7530 inserts the 4 magic header in between the 802.3 address and
> protocol field. The patch implements the callback that can be called by
> the flow dissector to figure out the real protocol and offset of the
> network header. With this patch applied we can properly parse the packet
> and thus make hashing function properly.
>
> Signed-off-by: Muciri Gatimu <muciri@openmesh.com>
> Signed-off-by: Shashidhar Lakkavalli <shashidhar.lakkavalli@openmesh.com>
> Signed-off-by: John Crispin <john@phrozen.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ 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