* pull-request: bpf 2018-09-16
From: Daniel Borkmann @ 2018-09-16 0:36 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix end boundary calculation in BTF for the type section, from Martin.
2) Fix and revert subtraction of pointers that was accidentally allowed
for unprivileged programs, from Alexei.
3) Fix bpf_msg_pull_data() helper by using __GFP_COMP in order to avoid
a warning in linearizing sg pages into a single one for large allocs,
from Tushar.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit cc4dfb7f70a344f24c1c71e298deea0771dadcb2:
rds: fix two RCU related problems (2018-09-12 00:09:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to 4c3d795cb012a378855543a775408fba1ccff6f2:
bpf: use __GFP_COMP while allocating page (2018-09-12 23:47:28 +0200)
----------------------------------------------------------------
Alexei Starovoitov (1):
bpf/verifier: disallow pointer subtraction
Martin KaFai Lau (1):
bpf: btf: Fix end boundary calculation for type section
Tushar Dave (1):
bpf: use __GFP_COMP while allocating page
kernel/bpf/btf.c | 2 +-
kernel/bpf/verifier.c | 2 +-
net/core/filter.c | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
^ permalink raw reply
* Job Offer
From: PineCone Research LLC @ 2018-09-16 0:43 UTC (permalink / raw)
To: netdev
EMPLOYMENT TITLE: PAYROLL COORDINATOR
EMPLOYMENT TYPE: PART-TIME (Work From Home)
SALARY: $4500.00 Monthly
PineCone Research is pleased to extend this offer of employment for the position of a Payroll Coordinator.
POSITION SUMMARY:
As a Payroll Coordinator, you will process all aspects of payroll for an assigned client base and report directly to the HR Manager in order to ensure effective, efficient and accurate operations. This position requires efficiency and flexibility in performing detailed tasks.
ESSENTIAL DUTIES & RESPONSIBILITIES:
-Compile payroll data, in order to balance the payroll and maintain payroll records
-Research client inquiries concerning paychecks or payroll in general
-Maintain client files in a confidential and secure manner
-Other duties as assigned.
MINIMUM QUALIFICATIONS:
-Detail oriented, well organized; high degree of accuracy
-Proficient in Microsoft Office (Word, Excel, Outlook)
-Professional, driven, motivated self-starter
-Reliable and dependable.
SALARY:
Your initial compensation includes a monthly salary of $4500.00
APPLY now:
Complete the sign up form below:
-Full Name:
-Mailing Address:
-Phone Number (Cell):
-Work Experience/Resume:
We look forward to a long lasting and mutually beneficial relationship and are confident your abilities will play a key role in our company. Please let me know if you have any questions.
Sincerely,
PineCone Research LLC
250 E 5th St 9th Fl
Cincinnati, Oh 45202
Attn: Richard Scott (HR Manager)
P: (513) 666-7709
^ permalink raw reply
* Re: mlx5_core: null pointer dereference in mlx5_accel_tls_device_caps() (net-next kernel)
From: Saeed Mahameed @ 2018-09-16 5:04 UTC (permalink / raw)
To: mkubecek; +Cc: Linux Netdev List, Saeed Mahameed, Leon Romanovsky
In-Reply-To: <20180914212021.GD3876@unicorn.suse.cz>
On Fri, Sep 14, 2018 at 2:20 PM Michal Kubecek <mkubecek@suse.cz> wrote:
>
> I just encountered a null pointer dereference on mlx5_core module
> initialization while booting net-next kernel (based on commit
> ee4fccbee7d3) on an aarch64 machine:
>
Hi Michal, the issue was introduced last kernel cycle, due to
790af90c00d2 ("net/mlx5e: TLS, build TLS netdev from capabilities")
they should have checked for device TLS presence before reading TLS
capabilities.
I am preparing a fix already,
Thanks a lot for the report.
> [ 12.021971] iommu: Adding device 0000:01:00.0 to group 3
> [ 12.022925] mlx5_core 0000:01:00.0: firmware version: 12.17.2020
> [ 12.022954] mlx5_core 0000:01:00.0: 63.008 Gb/s available PCIe bandwidth (8 GT/s x8 link)
> [ 12.068709] Adding 98830144k swap on /dev/sda4. Priority:-2 extents:1 across:98830144k FS
> [ 12.347571] (0000:01:00.0): E-Switch: Total vports 9, per vport: max uc(1024) max mc(16384)
> [ 12.351962] mlx5_core 0000:01:00.0: Port module event: module 0, Cable plugged
> [ 12.366306] mlx5_core 0000:01:00.0: MLX5E: StrdRq(0) RqSz(1024) StrdSz(128) RxCqeCmprss(0)
> [ 12.366741] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050
> [ 12.374603] Mem abort info:
> [ 12.377368] ESR = 0x96000004
> [ 12.380406] Exception class = DABT (current EL), IL = 32 bits
> [ 12.386357] SET = 0, FnV = 0
> [ 12.389347] EA = 0, S1PTW = 0
> [ 12.392471] Data abort info:
> [ 12.395343] ISV = 0, ISS = 0x00000004
> [ 12.399156] CM = 0, WnR = 0
> [ 12.402108] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
> [ 12.408711] [0000000000000050] pgd=0000000000000000
> [ 12.413567] Internal error: Oops: 96000004 [#1] SMP
> [ 12.418427] Modules linked in: fat mlx5_core(+) ipmi_ssif(+) aes_ce_blk crypto_simd cryptd aes_ce_cipher crc32_ce crct10dif_ce ghash_ce aes_arm64 sha2_ce sha256_arm64 sha1_ce ipmi_devintf ipmi_msghandler sbsa_gwdt tls mlxfw devlink at803x qcom_emac btrfs libcrc32c xor zlib_deflate raid6_pq ahci_platform libahci_platform hdma hdma_mgmt i2c_qup sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs
> [ 12.454800] CPU: 40 PID: 742 Comm: systemd-udevd Not tainted 4.19.0-rc3-ethnl.15-default #1
> [ 12.463131] Hardware name: To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M., BIOS 5.13 12/12/2012
> [ 12.473722] pstate: 60400005 (nZCv daif +PAN -UAO)
> [ 12.478559] pc : mlx5_accel_tls_device_caps+0x28/0x38 [mlx5_core]
> [ 12.484598] lr : mlx5e_tls_build_netdev+0x24/0x98 [mlx5_core]
> [ 12.490301] sp : ffff000021873a30
> [ 12.493599] x29: ffff000021873a30 x28: ffff2a72560a7940
> [ 12.498895] x27: ffff2a7256df6000 x26: ffff2a71a0fed650
> [ 12.504190] x25: 0000000000000000 x24: ffff92c7f2b988c0
> [ 12.509485] x23: ffff92c7fe01c0c0 x22: ffff2a71a0fcfa70
> [ 12.514780] x21: ffff92c7f2b808c0 x20: ffff92c7f741c110
> [ 12.520075] x19: ffff92c7f2b988c0 x18: ffff0000218739b0
> [ 12.525370] x17: 0000000000000000 x16: ffff2a725625ade0
> [ 12.530665] x15: 0000000029818ed4 x14: 00000000d47aab07
> [ 12.535961] x13: 8a24000000000000 x12: 0000000000000000
> [ 12.541256] x11: 0000000000000000 x10: 0000000000000000
> [ 12.546551] x9 : 0000000000000000 x8 : 0000000000000000
> [ 12.551846] x7 : 0000000000000000 x6 : ffff92c8159dc910
> [ 12.557141] x5 : 0000000000000400 x4 : ffff7e4b205a20c7
> [ 12.562436] x3 : 0000000000000000 x2 : ffff2a725625ae1c
> [ 12.567731] x1 : 00000000ab078a24 x0 : 0000000000000000
> [ 12.573027] Process systemd-udevd (pid: 742, stack limit = 0x(____ptrval____))
> [ 12.580232] Call trace:
> [ 12.582688] mlx5_accel_tls_device_caps+0x28/0x38 [mlx5_core]
> [ 12.588419] mlx5e_build_nic_netdev+0x27c/0x348 [mlx5_core]
> [ 12.593974] mlx5e_nic_init+0x1a0/0x258 [mlx5_core]
> [ 12.598835] mlx5e_create_netdev+0x74/0x118 [mlx5_core]
> [ 12.604043] mlx5e_add+0xf0/0x2c0 [mlx5_core]
> [ 12.608384] mlx5_add_device+0x88/0x1a8 [mlx5_core]
> [ 12.613246] mlx5_register_interface+0x78/0xb0 [mlx5_core]
> [ 12.618713] mlx5e_init+0x24/0x30 [mlx5_core]
> [ 12.623052] init+0x88/0xa0 [mlx5_core]
> [ 12.626850] do_one_initcall+0x54/0x200
> [ 12.630667] do_init_module+0x64/0x1d8
> [ 12.634401] load_module+0x1480/0x1510
> [ 12.638132] __se_sys_finit_module+0xc8/0xd8
> [ 12.642385] __arm64_sys_finit_module+0x24/0x30
> [ 12.646901] el0_svc_common+0x7c/0x118
> [ 12.650631] el0_svc_handler+0x38/0x78
> [ 12.654364] el0_svc+0x8/0xc
> [ 12.657229] Code: d503201f f97c7e60 f9400bf3 a8c27bfd (f9402800)
> [ 12.663306] ---[ end trace 57e772dd3cf718f1 ]---
>
> The function looks like this:
>
> ------------------------------------------------------------------------
> drivers/net/ethernet/mellanox/mlx5/core/accel/tls.c:
> 68 {
> 0x0000000000058230 <+0>: stp x29, x30, [sp, #-32]!
> 0x0000000000058234 <+4>: mov x29, sp
> 0x0000000000058238 <+8>: str x19, [sp, #16]
> 0x000000000005823c <+12>: mov x19, x0
> 0x0000000000058240 <+16>: mov x0, x30
>
> drivers/net/ethernet/mellanox/mlx5/core/fpga/tls.h:
> 68 return mdev->fpga->tls->caps;
> 0x0000000000058244 <+20>: add x19, x19, #0x38, lsl #12
>
> drivers/net/ethernet/mellanox/mlx5/core/accel/tls.c:
> 68 {
> 0x0000000000058248 <+24>: bl 0x58248
> <mlx5_accel_tls_device_caps+24>
>
> drivers/net/ethernet/mellanox/mlx5/core/fpga/tls.h:
> 68 return mdev->fpga->tls->caps;
> 0x000000000005824c <+28>: ldr x0, [x19, #30968]
>
> drivers/net/ethernet/mellanox/mlx5/core/accel/tls.c:
> 70 }
> 0x0000000000058250 <+32>: ldr x19, [sp, #16]
> 0x0000000000058254 <+36>: ldp x29, x30, [sp], #32
>
> drivers/net/ethernet/mellanox/mlx5/core/fpga/tls.h:
> 68 return mdev->fpga->tls->caps;
> 0x0000000000058258 <+40>: ldr x0, [x0, #80]
>
> drivers/net/ethernet/mellanox/mlx5/core/accel/tls.c:
> 70 }
> 0x000000000005825c <+44>: ldr w0, [x0, #20]
> 0x0000000000058260 <+48>: ret
> ------------------------------------------------------------------------
>
> so IIUC mdev->fpga is null (offset of tls in struct mlx5_fpga_device is
> indeed 80 = 0x50).
>
> The NIC is
>
> Model: "Mellanox MT27700 Family [ConnectX-4]"
> Vendor: pci 0x15b3 "Mellanox Technologies"
> Device: pci 0x1013 "MT27700 Family [ConnectX-4]"
> SubVendor: pci 0x15b3 "Mellanox Technologies"
> SubDevice: pci 0x0003
>
> Michal Kubecek
^ permalink raw reply
* KMSAN: uninit-value in ip_rcv_core
From: syzbot @ 2018-09-16 11:03 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 42a037ca8d9d kmsan: update README.md to reference LLVM r34..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=1089adea400000
kernel config: https://syzkaller.appspot.com/x/.config?x=3431f03869413153
dashboard link: https://syzkaller.appspot.com/bug?extid=2e406a9ac75bb71d4b7a
compiler: clang version 8.0.0 (trunk 339414)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12d6d421400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13fdeb7a400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2e406a9ac75bb71d4b7a@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KMSAN: uninit-value in ip_rcv_core+0xabd/0x1160 net/ipv4/ip_input.c:464
CPU: 1 PID: 4270 Comm: syz-executor158 Not tainted 4.19.0-rc1+ #42
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x14b/0x190 lib/dump_stack.c:113
kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956
__msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645
ip_rcv_core+0xabd/0x1160 net/ipv4/ip_input.c:464
ip_rcv+0xbb/0x6d0 net/ipv4/ip_input.c:521
__netif_receive_skb_one_core net/core/dev.c:4892 [inline]
__netif_receive_skb net/core/dev.c:5002 [inline]
process_backlog+0x752/0x10b0 net/core/dev.c:5808
napi_poll net/core/dev.c:6228 [inline]
net_rx_action+0x723/0x19d0 net/core/dev.c:6294
__do_softirq+0x562/0x948 kernel/softirq.c:292
do_softirq_own_stack+0x49/0x80 arch/x86/entry/entry_64.S:1055
</IRQ>
do_softirq kernel/softirq.c:336 [inline]
__local_bh_enable_ip+0x119/0x150 kernel/softirq.c:189
local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
rcu_read_unlock_bh include/linux/rcupdate.h:723 [inline]
__dev_queue_xmit+0x35a8/0x3ab0 net/core/dev.c:3830
dev_queue_xmit+0x4b/0x60 net/core/dev.c:3836
packet_snd net/packet/af_packet.c:2925 [inline]
packet_sendmsg+0x80ff/0x8c60 net/packet/af_packet.c:2950
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
__sys_sendmsg net/socket.c:2152 [inline]
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x441149
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffebf721a18 EFLAGS: 00000286 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441149
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000003
RBP: 00000000006cc018 R08: 0000000000000100 R09: 0000000000000100
R10: 0000000000000100 R11: 0000000000000286 R12: 00000000004020b0
R13: 0000000000402140 R14: 0000000000000000 R15: 0000000000000000
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:271 [inline]
kmsan_internal_chain_origin+0x128/0x210 mm/kmsan/kmsan.c:573
__msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:482
iptunnel_xmit+0xa3c/0xd50 net/ipv4/ip_tunnel_core.c:85
ip_tunnel_xmit+0x33e1/0x3750 net/ipv4/ip_tunnel.c:778
__gre_xmit net/ipv4/ip_gre.c:449 [inline]
ipgre_xmit+0xdcf/0xeb0 net/ipv4/ip_gre.c:703
__netdev_start_xmit include/linux/netdevice.h:4287 [inline]
netdev_start_xmit include/linux/netdevice.h:4296 [inline]
xmit_one net/core/dev.c:3217 [inline]
dev_hard_start_xmit+0x5df/0xc20 net/core/dev.c:3233
__dev_queue_xmit+0x2f35/0x3ab0 net/core/dev.c:3803
dev_queue_xmit+0x4b/0x60 net/core/dev.c:3836
packet_snd net/packet/af_packet.c:2925 [inline]
packet_sendmsg+0x80ff/0x8c60 net/packet/af_packet.c:2950
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
__sys_sendmsg net/socket.c:2152 [inline]
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:181
kmsan_kmalloc+0x98/0x100 mm/kmsan/kmsan_hooks.c:91
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan_hooks.c:100
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2719 [inline]
__kmalloc_node_track_caller+0x9e7/0x1160 mm/slub.c:4352
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2f5/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:996 [inline]
alloc_skb_with_frags+0x1d0/0xac0 net/core/skbuff.c:5276
sock_alloc_send_pskb+0xb47/0x1170 net/core/sock.c:2082
packet_alloc_skb net/packet/af_packet.c:2779 [inline]
packet_snd net/packet/af_packet.c:2870 [inline]
packet_sendmsg+0x6599/0x8c60 net/packet/af_packet.c:2950
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
__sys_sendmsg net/socket.c:2152 [inline]
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: kernel 4.18.5 Realtek 8111G network adapter stops responding under high system load
From: David Arendt @ 2018-09-16 12:38 UTC (permalink / raw)
To: Maciej S. Szmigiero; +Cc: linux-kernel, nic_swsd, netdev
In-Reply-To: <6c14f6d0-ea61-b8e6-57a2-940d32330ed2@maciej.szmigiero.name>
Hi,
I have applied the patch one hour ago. So far there are no problems but
because sometimes the problems only appeared after a few hours, I will
only definitively know tomorrow if the patch helped or not.
If not, I will try bisecting the problem.
For information here the differences from ethtool between the working
driver from 4.17.14 and the patched one fom 4.18.8:
--- working.txt 2018-09-16 14:14:00.544376935 +0200
+++ patched.txt 2018-09-16 14:20:09.445660915 +0200
@@ -5,2 +5,2 @@
-0x10: Dump Tally Counter Command 0xf900c000 0x00000007
-0x20: Tx Normal Priority Ring Addr 0xf3aa7000 0x00000007
+0x10: Dump Tally Counter Command 0xf9260000 0x00000007
+0x20: Tx Normal Priority Ring Addr 0xebb73000 0x00000007
@@ -17 +17 @@
-0x40: Tx Configuration 0x4f000f80
+0x40: Tx Configuration 0x4f000f00
@@ -31,2 +31,2 @@
-0x64: TBI control and status 0x17ffff01
-0x68: TBI Autonegotiation advertisement (ANAR) 0xf70c
+0x64: TBI control and status 0x00000000
+0x68: TBI Autonegotiation advertisement (ANAR) 0x0000
@@ -35 +35 @@
-0x84: PM wakeup frame 0 0x04000000 0x7c5b5c95
+0x84: PM wakeup frame 0 0x04000000 0x710b8deb
@@ -57 +57 @@
-0xE4: Rx Ring Addr 0xf3b64000 0x00000007
+0xE4: Rx Ring Addr 0xef9f0000 0x00000007
Thanks in advance,
David Arendt
On 9/16/18 1:54 AM, Maciej S. Szmigiero wrote:
> [ I've added Realtek Linux NIC and netdev mailing lists to CC ]
>
> Hi David,
>
> On 15.09.2018 23:23, David Arendt wrote:
>> Hi,
>>
>> just a follow up:
>>
>> In kernel 4.18.8 the behaviour is different.
>>
>> The network is not reachable a number of times, but restarting to be
>> reachable by itself before it finally is no longer reachable at all.
>>
>> Here the logging output:
>>
>> Sep 15 17:44:43 server kernel: NETDEV WATCHDOG: enp3s0 (r8169): transmit
>> queue 0 timed out
>> Sep 15 17:44:43 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:10:26 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:12:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:13:19 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:14:48 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:20:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:34:19 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:43:43 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 18:46:26 server kernel: r8169 0000:03:00.0 enp3s0: link up
>> Sep 15 19:00:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
>>
>> From 17:44 ro 18:46 the network is recovering automatically. After the
>> up from 19:00, the network is no longer reachable without any additional
>> message.
>>
>> If looking at ifconfig, the counter for TX packets is incrementing, the
>> counter for RX packets not.
>>
>> Here again the driver from 4.17.14 is working flawlessly.
> Could you please try this patch on top of 4.18.8:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f74dd480cf4e31e12971c58a1d832044db945670
>
> In my case the problem fixed by the above commit was only limited to
> bad TX performance but my r8169 NIC models were different from what
> you have.
>
> If this does not help then try bisecting the issue
> (maybe limited to drivers/net/ethernet/realtek/r8169.c to save time).
> If the NIC dies after a heavy load it might be possible to generate
> such load quickly by in-kernel pktgen.
>
> If that's not possible then at please least compare NIC register
> values displayed by "ethtool -d enp3s0" between working and
> non-working kernels.
>
>> Thanks in advance,
>> David Arendt
> Maciej
>
>>
>> On 9/4/18 8:19 AM, David Arendt wrote:
>>> Hi,
>>>
>>> When using kernel 4.18.5 the Realtek 8111G network adapter stops
>>> responding under high system load.
>>>
>>> Dmesg is showing no errors.
>>>
>>> Sometimes an ifconfig enp3s0 down followed by an ifconfig enp3s0 up is
>>> enough for the network adapter to restart responding. Sometimes a reboot
>>> is necessary.
>>>
>>> When copying r8169.c from 4.17.14 to the 4.18.5 kernel, networking works
>>> perfectly stable on 4.18.5 so the problem seems r8169.c related.
>>>
>>> Here the output from lshw:
>>>
>>> *-pci:2
>>> description: PCI bridge
>>> product: 8 Series/C220 Series Chipset Family PCI Express
>>> Root Port #3
>>> vendor: Intel Corporation
>>> physical id: 1c.2
>>> bus info: pci@0000:00:1c.2
>>> version: d5
>>> width: 32 bits
>>> clock: 33MHz
>>> capabilities: pci pciexpress msi pm normal_decode
>>> bus_master cap_list
>>> configuration: driver=pcieport
>>> resources: irq:18 ioport:d000(size=4096)
>>> memory:f7300000-f73fffff ioport:f2100000(size=1048576)
>>> *-network
>>> description: Ethernet interface
>>> product: RTL8111/8168/8411 PCI Express Gigabit Ethernet
>>> Controller
>>> vendor: Realtek Semiconductor Co., Ltd.
>>> physical id: 0
>>> bus info: pci@0000:03:00.0
>>> logical name: enp3s0
>>> version: 0c
>>> serial: <hidden>
>>> size: 1Gbit/s
>>> capacity: 1Gbit/s
>>> width: 64 bits
>>> clock: 33MHz
>>> capabilities: pm msi pciexpress msix vpd bus_master
>>> cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt
>>> 1000bt-fd autonegotiation
>>> configuration: autonegotiation=on broadcast=yes
>>> driver=r8169 driverversion=2.3LK-NAPI duplex=full
>>> firmware=rtl8168g-2_0.0.1 02/06/13 latency=0 link=yes multicast=yes
>>> port=MII speed=1Gbit/s
>>> resources: irq:18 ioport:d000(size=256)
>>> memory:f7300000-f7300fff memory:f2100000-f2103fff
>>>
>>> Thanks in advance for looking into this,
>>>
>>> David Arendt
>>>
>>>
^ permalink raw reply
* [PATCH] net: usb: remove redundant null pointer check before of_node_put
From: zhong jiang @ 2018-09-16 13:20 UTC (permalink / raw)
To: davem; +Cc: woojung.huh, UNGLinuxDriver, netdev, linux-usb, linux-kernel
of_node_put has taken the null pointer check into account. So it is
safe to remove the duplicated check before of_node_put.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/usb/lan78xx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 3ce3c66..34ca0ee 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1835,8 +1835,7 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev)
node = of_get_child_by_name(dev->udev->dev.of_node, "mdio");
ret = of_mdiobus_register(dev->mdiobus, node);
- if (node)
- of_node_put(node);
+ of_node_put(node);
if (ret) {
netdev_err(dev->net, "can't register MDIO bus\n");
goto exit1;
--
1.7.12.4
^ permalink raw reply related
* [PATCH] net: dsa: remove redundant null pointer check before of_node_put
From: zhong jiang @ 2018-09-16 13:22 UTC (permalink / raw)
To: davem; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
of_node_put has taken the null pointer check into account. So it is
safe to remove the duplicated check before of_node_put.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/dsa/bcm_sf2.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index e0066ad..1fc27e1 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -465,8 +465,7 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)
static void bcm_sf2_mdio_unregister(struct bcm_sf2_priv *priv)
{
mdiobus_unregister(priv->slave_mii_bus);
- if (priv->master_mii_dn)
- of_node_put(priv->master_mii_dn);
+ of_node_put(priv->master_mii_dn);
}
static u32 bcm_sf2_sw_get_phy_flags(struct dsa_switch *ds, int port)
--
1.7.12.4
^ permalink raw reply related
* [PATCH] net: dsa: remove redundant null pointer check before put_device
From: zhong jiang @ 2018-09-16 13:45 UTC (permalink / raw)
To: davem, f.fainelli, andrew; +Cc: vivien.didelot, netdev, linux-kernel
put_device has taken the null pinter check into account. So it is
safe to remove the duplicated check before put_device.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/dsa/legacy.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/dsa/legacy.c b/net/dsa/legacy.c
index 42a7b85..8aa92b0 100644
--- a/net/dsa/legacy.c
+++ b/net/dsa/legacy.c
@@ -392,8 +392,7 @@ static void dsa_of_free_platform_data(struct dsa_platform_data *pd)
}
/* Drop our reference to the MDIO bus device */
- if (pd->chip[i].host_dev)
- put_device(pd->chip[i].host_dev);
+ put_device(pd->chip[i].host_dev);
}
kfree(pd->chip);
}
--
1.7.12.4
^ permalink raw reply related
* Re: [RFC PATCH iproute2-next] man: Add devlink health man page
From: Eran Ben Elisha @ 2018-09-16 9:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Jiri Pirko, Andy Gospodarek, Michael Chan, Jakub Kicinski,
Simon Horman, Alexander Duyck, Florian Fainelli, Tal Alon,
Ariel Almog
In-Reply-To: <20180913151252.GC23892@lunn.ch>
On 9/13/2018 6:12 PM, Andrew Lunn wrote:
>>>>>> devlink health sensor set pci/0000:01:00.0 name TX_COMP_ERROR action reset off action dump on
>>>>>> Sets TX_COMP_ERROR sensor parameters for a specific device.
>
>>>> This is what I had in mind:
>>>> 1. command interface error
>>>> 2. command interface timeout
>>>> 3. stuck TX queue (like tx_timeout)
>>>> 4. stuck TX completion queue (driver did not process packets in a reasonable
>>>> time period)
>>>> 5. stuck RX queue
>>>> 6. RX completion error
>>>> 7. TX completion error
>>>> 8. HW / FW catastrophic error report
>>>> 9. completion queue overrun
>
>> Such issues do exist in production environment, and need to be handled even
>> if root cause is a bug which will be fixed in latest release. My feature
>> should help developers / administrator to control and recover their live
>> systems, by auto correction and logging support.
>> Goal is:
>> - Provide alert debug information
>> - Self healing
>> - If problem needs vendor support, provide a way to gather all needed
>> debugging information.
>
> So maybe you have the wrong name for this. Health is nice in terms of
> Marketing, but we are actually talking about bug recovery.
The way I see it, this feature is responsible for the health of the
system from the pci/xxxx perspective.
I though about devlink-recover for example, but I really wouldn't like
to limit the feature to be called after one of its actions. The same for
devlink-bug, which highlights only part of the range of capabilities
(sensor).
My work is currently focused on error reporting and recovery, but I
wouldn't like to see the API limited for "bugs" only.
Eran
>
> devlink bug sensor set pci/0000:01:00.0 name command_interface_error action reset off action dump on
> devlink bug sensor set pci/0000:01:00.0 name command_interface_timeout action reset off action dump on
> devlink bug sensor set pci/0000:01:00.0 name transmit_completion_error action reset off action dump on
> devlink bug sensor set pci/0000:01:00.0 name completion_queue_overrun action reset off action dump on
>
> seems a lot more understandable than:
>
> devlink health set pci/0000:01:00.0 name TX_COMP_ERROR action reset off action dump on
>
> Andrew
>
^ permalink raw reply
* Re: [RFC PATCH iproute2-next] System specification health API
From: Eran Ben Elisha @ 2018-09-16 10:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Jiri Pirko, Andy Gospodarek, Michael Chan, Simon Horman,
Alexander Duyck, Andrew Lunn, Florian Fainelli, Tal Alon,
Ariel Almog
In-Reply-To: <20180913103604.0ef868f4@cakuba.netronome.com>
On 9/13/2018 8:36 PM, Jakub Kicinski wrote:
> On Thu, 13 Sep 2018 11:18:15 +0300, Eran Ben Elisha wrote:
>> The health spec is targeted for Real Time Alerting, in order to know when
>> something bad had happened to a PCI device
>
> By spec you mean some standards body spec you implement or this
> proposal is a spec?
This proposal is a spec
>
>> - Provide alert debug information
>> - Self healing
>> - If problem needs vendor support, provide a way to gather all needed debugging
>> information.
>>
>> The health contains sensors which sense for malfunction. Once sensor triggered,
>> actions such as logs and correction can be taken.
>> Sensors are sensing the health state and can trigger correction action.
>>
>> The sensors are divided into the following groups
>> - Hardware sensor - a sensor which is triggered by the device due to
>> malfunction.
>> - Software sensor - a sensor which is triggered by the software due to
>> malfunction.
>> Both group of sensors can be triggered due to error event or due to a periodic check.
>>
>> Actions are the way to handle sensor events. Action can be in one of the
>> following groups:
>> - Dump - SW trace, SW dump, HW trace, HW dump
>> - Reset - Surgical correction (e.g. modify Q, flush Q, reset of device, etc)
>> Actions can be performed by SW or HW.
>>
>> User is allowed to enable or disable sensors and sensor2action mapping.
>>
>> This RFC man page patch describes the suggested API of devlink-health in order
>> to control sensors and actions.
>
> I like the idea of configuring response to events like this, although
> I'm not sure the name sensor is appropriate here - perhaps exception or
> error would be better?
I was trying to avoid the negativity description. Have it called sensor
to avoid restricting the API for errors / exceptions only. I got the
same type of comment from Andrew as well devlink-health->devlink-bug.
But if other vendors driver developers don't see it can be expanded to
sensor which are not errors, then I guess we can refactor the names.
Are there going to be values reported?
It depends on the sensor. If it has data that would help in the debug,
then I assume yes, via the dumps.
>
> I'm not so sure about HW sensors in relation to existing HWMON
> infrastructure... I assume you're targeting things like say some HW
> engine/block reporting it encountered an error? Sounds good, too.
yes, exactly.
>
> Are the actions all envisioned to be performed by the driver?
> Firmware? Hardware? I guess that distinction can be added later.
> For FW/HW actions we would go back to the problem of persistence of
> the setting since it was only implemented for params :S
The problem is not with FW action, the problem is when you try to set
sensor2action mapping for the FW/HW. this will need persistence
configuration mode. Sensor2action in SW shall be run-time mode (at least
as a start).
But it sound as this need some more tuning, to make it clear.
>
> Is the dump option going to tie back into region snapshots?
>
no necessarily, dumping SW objects as well can be helpful
^ permalink raw reply
* [PATCH] net: ethernet: remove redundant null pointer check before of_node_put
From: zhong jiang @ 2018-09-16 13:13 UTC (permalink / raw)
To: davem; +Cc: fugang.duan, netdev, linux-kernel
of_node_put has taken the null pinter check into account. So it is
safe to remove the duplicated check before of_node_put.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ethernet/freescale/fec_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 2708297..67d6c9d 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2055,8 +2055,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
node = of_get_child_by_name(pdev->dev.of_node, "mdio");
err = of_mdiobus_register(fep->mii_bus, node);
- if (node)
- of_node_put(node);
+ of_node_put(node);
if (err)
goto err_out_free_mdiobus;
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH v2 02/17] compat_ioctl: move drivers to generic_compat_ioctl_ptrarg
From: Jarkko Sakkinen @ 2018-09-16 19:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kvm, Alexander Shishkin, virtualization, Benjamin Tissoires,
linux-mtd, Peter Huewe, linux1394-devel, devel, Jason Gunthorpe,
Marek Vasut, linux-input, Tomas Winkler, Jiri Kosina,
Alex Williamson, viro, OGAWA Hirofumi, Artem Bityutskiy,
Greg Kroah-Hartman, linux-usb, linux-kernel, Sudip Mukherjee,
Stefan Richter, netdev, linux-fsdevel
In-Reply-To: <20180912150142.157913-2-arnd@arndb.de>
On Wed, Sep 12, 2018 at 05:01:03PM +0200, Arnd Bergmann wrote:
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c b/drivers/char/tpm/tpm_vtpm_proxy.c
> index 87a0ce47f201..a170f5ca7416 100644
> --- a/drivers/char/tpm/tpm_vtpm_proxy.c
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -678,20 +678,10 @@ static long vtpmx_fops_ioctl(struct file *f, unsigned int ioctl,
> }
> }
>
> -#ifdef CONFIG_COMPAT
> -static long vtpmx_fops_compat_ioctl(struct file *f, unsigned int ioctl,
> - unsigned long arg)
> -{
> - return vtpmx_fops_ioctl(f, ioctl, (unsigned long)compat_ptr(arg));
> -}
> -#endif
> -
> static const struct file_operations vtpmx_fops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = vtpmx_fops_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = vtpmx_fops_compat_ioctl,
> -#endif
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> .llseek = noop_llseek,
> };
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
/Jarkko
^ permalink raw reply
* (unknown),
From: iluminati @ 2018-09-16 13:39 UTC (permalink / raw)
--
join the Illuminati secret brotherhood and get $3,000,000.00
^ permalink raw reply
* Re: [PATH RFC net-next 7/8] net: phy: Replace phy driver features u32 with link_mode bitmap
From: Florian Fainelli @ 2018-09-16 16:20 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20180915223053.GA6038@lunn.ch>
Hi Andrew,
On September 15, 2018 3:30:53 PM PDT, Andrew Lunn <andrew@lunn.ch> wrote:
>On Sat, Sep 15, 2018 at 02:31:14PM -0700, Florian Fainelli wrote:
>>
>>
>> On 09/14/18 14:38, Andrew Lunn wrote:
>> > This is one step in allowing phylib to make use of link_mode
>bitmaps,
>> > instead of u32 for supported and advertised features. Convert the
>phy
>> > drivers to use bitmaps to indicates the features they support. This
>> > requires some macro magic in order to construct constant bitmaps
>used
>> > to initialise the driver structures.
>> >
>> > Some new PHY_*_FEATURES are added, to indicate FIBRE is supported,
>and
>> > that all media ports are supported. This is done since bitmaps
>cannot
>> > be ORed together at compile time.
>> >
>> > Within phylib, the features bitmap is currently turned back into a
>> > u32. The MAC API to phylib needs to be cleaned up before the core
>of
>> > phylib can be converted to using bitmaps instead of u32.
>>
>> Nice!
>
>Hi Florian
>
>This is the patch i don't like. I'm hoping somebody can think of a
>better way to initialise a bitmap.
By that you mean having to determine whether you overflow the capacity of an unsigned long storage type and having to put the bits in either unsigned long [0] or [1]? Being able to eliminate the duplication would also be nice, but I cannot think about a smart solution at compile time that would avoid doing that.
--
Florian
^ permalink raw reply
* Re: [PATCH] stmmac: fix valid numbers of unicast filter entries
From: David Miller @ 2018-09-16 22:24 UTC (permalink / raw)
To: neidhard.kim
Cc: linux-kernel, netdev, peppe.cavallaro, alexandre.torgue, joabreu,
chanho.min
In-Reply-To: <1536831141-25757-1-git-send-email-neidhard.kim@lge.com>
From: Jongsung Kim <neidhard.kim@lge.com>
Date: Thu, 13 Sep 2018 18:32:21 +0900
> Synopsys DWC Ethernet MAC can be configured to have 1..32, 64, or
> 128 unicast filter entries. (Table 7-8 MAC Address Registers from
> databook) Fix dwmac1000_validate_ucast_entries() to accept values
> between 1 and 32 in addition.
>
> Signed-off-by: Jongsung Kim <neidhard.kim@lge.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: et011c: Remove incorrect PHY_POLL flags
From: David Miller @ 2018-09-16 22:32 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, linux-kernel
In-Reply-To: <20180913183630.32584-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 13 Sep 2018 11:36:30 -0700
> PHY_POLL is defined as -1 which means that we would be setting all flags of the
> PHY driver, this is also not a valid flag to tell PHYLIB about, just remove it.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3,net-next 1/2] ip_gre: fix parsing gre header in ipgre_err
From: David Miller @ 2018-09-16 22:34 UTC (permalink / raw)
To: yanhaishuang; +Cc: kuznet, jbenc, netdev, linux-kernel
In-Reply-To: <1536899208-2958-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Fri, 14 Sep 2018 12:26:47 +0800
> gre_parse_header stops parsing when csum_err is encountered, which means
> tpi->key is undefined and ip_tunnel_lookup will return NULL improperly.
>
> This patch introduce a NULL pointer as csum_err parameter. Even when
> csum_err is encountered, it won't return error and continue parsing gre
> header as expected.
>
> Fixes: 9f57c67c379d ("gre: Remove support for sharing GRE protocol hook.")
> Reported-by: Jiri Benc <jbenc@redhat.com>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>
> ---
> Changes since v3:
> * skb_checksum_simple_validate need to be performed in csum_err case.
Applied.
^ permalink raw reply
* [PATCH iproute2-next] rdma: Fix representation of PortInfo CapabilityMask
From: Leon Romanovsky @ 2018-09-16 17:28 UTC (permalink / raw)
To: David Ahern; +Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
From: Leon Romanovsky <leonro@mellanox.com>
The port capability mask represents IBTA PortInfo specification,
but as it is written in description of kernel commit 2f944c0fbf58
("RDMA: Fix storage of PortInfo CapabilityMask in the kernel"),
the bit 26 was mistakenly overwritten.
The rdmatool followed it too and mislead users by presenting wrong
value. Since it never showed proper value, we update the whole
port_cap_mask to comply with IBTA and show real HW values.
Fixes: da990ab40a92 ("rdma: Add link object")
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
rdma/link.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/rdma/link.c b/rdma/link.c
index 7e914c87..7a6d4b7e 100644
--- a/rdma/link.c
+++ b/rdma/link.c
@@ -20,6 +20,7 @@ static int link_help(struct rd *rd)
static const char *caps_to_str(uint32_t idx)
{
#define RDMA_PORT_FLAGS(x) \
+ x(RESERVED, 0) \
x(SM, 1) \
x(NOTICE, 2) \
x(TRAP, 3) \
@@ -32,7 +33,9 @@ static const char *caps_to_str(uint32_t idx)
x(SM_DISABLED, 10) \
x(SYS_IMAGE_GUID, 11) \
x(PKEY_SW_EXT_PORT_TRAP, 12) \
+ x(CABLE_INFO, 13) \
x(EXTENDED_SPEEDS, 14) \
+ x(CAP_MASK2, 15) \
x(CM, 16) \
x(SNMP_TUNNEL, 17) \
x(REINIT, 18) \
@@ -43,7 +46,12 @@ static const char *caps_to_str(uint32_t idx)
x(BOOT_MGMT, 23) \
x(LINK_LATENCY, 24) \
x(CLIENT_REG, 25) \
- x(IP_BASED_GIDS, 26)
+ x(OTHER_LOCAL_CHANGES, 26) \
+ x(LINK_SPPED_WIDTH, 27) \
+ x(VENDOR_SPECIFIC_MADS, 28) \
+ x(MULT_PKER_TRAP, 29) \
+ x(MULT_FDB, 30) \
+ x(HIERARCHY_INFO, 31)
enum { RDMA_PORT_FLAGS(RDMA_BITMAP_ENUM) };
@@ -51,9 +59,7 @@ static const char *caps_to_str(uint32_t idx)
rdma_port_names[] = { RDMA_PORT_FLAGS(RDMA_BITMAP_NAMES) };
#undef RDMA_PORT_FLAGS
- if (idx < ARRAY_SIZE(rdma_port_names) && rdma_port_names[idx])
- return rdma_port_names[idx];
- return "UNKNOWN";
+ return rdma_port_names[idx];
}
static void link_print_caps(struct rd *rd, struct nlattr **tb)
--
2.14.4
^ permalink raw reply related
* Re: [PATH RFC net-next 7/8] net: phy: Replace phy driver features u32 with link_mode bitmap
From: Andrew Lunn @ 2018-09-16 17:59 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <B2A80E09-BDE8-4D36-B4A7-B79493210161@gmail.com>
> By that you mean having to determine whether you overflow the
> capacity of an unsigned long storage type and having to put the bits
> in either unsigned long [0] or [1]? Being able to eliminate the
> duplication would also be nice, but I cannot think about a smart
> solution at compile time that would avoid doing that.
Hi Florian
I've given up on doing it at compile time. I'm working on a run-time
solution at the moment, which i think looks better. I will probably
split the patchset. Post for merging all but the last two patches, and
then an RFC for replacing this patch.
Andrew
^ permalink raw reply
* Re: [PATCH net-next RFC 7/8] udp: gro behind static key
From: Willem de Bruijn @ 2018-09-16 18:10 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan
Cc: Network Development, Paolo Abeni, steffen.klassert, David Miller,
Willem de Bruijn
In-Reply-To: <d2d549af137b9ec0b62d6ac7c6b7f97a@codeaurora.org>
On Fri, Sep 14, 2018 at 11:37 PM Subash Abhinov Kasiviswanathan
<subashab@codeaurora.org> wrote:
>
> On 2018-09-14 11:59, Willem de Bruijn wrote:
> > From: Willem de Bruijn <willemb@google.com>
> >
> > Avoid the socket lookup cost in udp_gro_receive if no socket has a
> > gro callback configured.
> >
> > Signed-off-by: Willem de Bruijn <willemb@google.com>
> > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> > index 4f6aa95a9b12..f44fe328aa0f 100644
> > --- a/net/ipv4/udp_offload.c
> > +++ b/net/ipv4/udp_offload.c
> > @@ -405,7 +405,7 @@ static struct sk_buff *udp4_gro_receive(struct
> > list_head *head,
> > {
> > struct udphdr *uh = udp_gro_udphdr(skb);
> >
> > - if (unlikely(!uh))
> > + if (unlikely(!uh) ||
> > !static_branch_unlikely(&udp_encap_needed_key))
> > goto flush;
> >
>
> Hi Willem
>
> Does this need to be
>
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 6dd3f0a..fcd5589 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -407,7 +407,7 @@ static struct sk_buff *udp4_gro_receive(struct
> list_head *head,
> {
> struct udphdr *uh = udp_gro_udphdr(skb);
>
> - if (unlikely(!uh) ||
> !static_branch_unlikely(&udp_encap_needed_key))
> + if (unlikely(!uh) ||
> static_branch_unlikely(&udp_encap_needed_key))
> goto flush;
>
> /* Don't bother verifying checksum if we're going to flush
> anyway. */
>
> I tried setting UDP_GRO socket option and I had to make this change to
> exercise the udp_gro_receive_cb code path.
Thanks for trying it out, Subash.
The static_branch logic is correct as is. It skips the gro logic if
the static key is not enabled.
But there is indeed a bug. the UDP_GRO setsockopt has to enable
the static key. A full patch is more complete, but this should fix it for
now:
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2506,6 +2506,7 @@ int udp_lib_setsockopt(struct sock *sk, int
level, int optname,
if (!udp_sk(sk)->gro_receive) {
udp_sk(sk)->gro_complete = udp_gro_complete_cb;
udp_sk(sk)->gro_receive = udp_gro_receive_cb;
+ udp_encap_enable();
sorry about that. I had tested the two patches independently, but
apparently not on top of each other.
Independent of udp gro, I tested the static key by running udp_rr
with perf record -a -g and looking for __udp4_lib_lookup. With the
patch, all calls are from __udp4_lib_rcv else udp_gro_receive also
shows up. I had to stress the porttable by opening ~32K ports.
Also, the simple patch to udpgso_bench_rx.c that I used to test
gro:
diff --git a/tools/testing/selftests/net/udpgso_bench_rx.c
b/tools/testing/selftests/net/udpgso_bench_rx.c
index 727cf67a3f75..35ba8567fc56 100644
--- a/tools/testing/selftests/net/udpgso_bench_rx.c
+++ b/tools/testing/selftests/net/udpgso_bench_rx.c
@@ -31,6 +31,11 @@
#include <sys/wait.h>
#include <unistd.h>
+#ifndef UDP_GRO
+#define UDP_GRO 104
+#endif
+
+static bool cfg_do_gro;
static int cfg_port = 8000;
static bool cfg_tcp;
static bool cfg_verify;
@@ -89,6 +94,11 @@ static int do_socket(bool do_tcp)
if (setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &val, sizeof(val)))
error(1, errno, "setsockopt reuseport");
+ if (cfg_do_gro) {
+ if (setsockopt(fd, SOL_UDP, UDP_GRO, &val, sizeof(val)))
+ error(1, errno, "setsockopt gro");
+ }
+
addr.sin6_family = PF_INET6;
addr.sin6_port = htons(cfg_port);
addr.sin6_addr = in6addr_any;
@@ -199,8 +209,11 @@ static void parse_opts(int argc, char **argv)
{
int c;
- while ((c = getopt(argc, argv, "ptv")) != -1) {
+ while ((c = getopt(argc, argv, "gptv")) != -1) {
switch (c) {
+ case 'g':
+ cfg_do_gro = true;
+ break;
case 'p':
cfg_port = htons(strtoul(optarg, NULL, 0));
break;
^ permalink raw reply related
* Re: [PATCH net-next RFC 5/8] net: deconstify net_offload
From: Willem de Bruijn @ 2018-09-16 18:12 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan
Cc: Network Development, Paolo Abeni, steffen.klassert, David Miller,
Willem de Bruijn
In-Reply-To: <55c49b73544397757ad2cf22598519b1@codeaurora.org>
On Fri, Sep 14, 2018 at 11:30 PM Subash Abhinov Kasiviswanathan
<subashab@codeaurora.org> wrote:
>
> On 2018-09-14 11:59, Willem de Bruijn wrote:
> > From: Willem de Bruijn <willemb@google.com>
> >
> > With configurable gro, the flags field in net_offloads may be changed.
> >
> > Remove the const keyword. This is a noop otherwise.
> >
> > Signed-off-by: Willem de Bruijn <willemb@google.com>
> > diff --git a/net/sctp/offload.c b/net/sctp/offload.c
> > index 123e9f2dc226..ad504b83245d 100644
> > --- a/net/sctp/offload.c
> > +++ b/net/sctp/offload.c
> > @@ -90,7 +90,7 @@ static struct sk_buff *sctp_gso_segment(struct
> > sk_buff
> > *skb,
> > return segs;
> > }
> >
> > -static const struct net_offload sctp_offload = {
> > +static struct net_offload sctp_offload = {
> > .callbacks = {
> > .gso_segment = sctp_gso_segment,
> > },
>
> Hi Willem
>
> sctp6 also needs to be deconstified.
>
> diff --git a/net/sctp/offload.c b/net/sctp/offload.c
> index ad504b8..4be7794 100644
> --- a/net/sctp/offload.c
> +++ b/net/sctp/offload.c
> @@ -96,7 +96,7 @@ static struct sk_buff *sctp_gso_segment(struct sk_buff
> *skb,
> },
> };
>
> -static const struct net_offload sctp6_offload = {
> +static struct net_offload sctp6_offload = {
> .callbacks = {
> .gso_segment = sctp_gso_segment,
> },
Thanks! I'll update that.
^ permalink raw reply
* Re: [RFC PATCH 2/4] net: enable UDP gro on demand.
From: Willem de Bruijn @ 2018-09-16 18:23 UTC (permalink / raw)
To: Paolo Abeni
Cc: Network Development, David Miller, Willem de Bruijn,
steffen.klassert
In-Reply-To: <CAF=yD-JQtW7MW8UZHbNqB5zrYL+f4q1b1CiPnL0oy94_gopUcA@mail.gmail.com>
On Fri, Sep 14, 2018 at 1:16 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Fri, Sep 14, 2018 at 11:47 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > Currently, the UDP GRO callback is always invoked, regardless of
> > the existence of any actual user (e.g. a UDP tunnel). With retpoline
> > enabled, this causes measurable overhead.
> >
> > This changeset introduces explicit accounting of the sockets requiring
> > UDP GRO and updates the UDP offloads at runtime accordingly, so that
> > the GRO callback is present (and invoked) only when there is at least
> > one socket requiring it.
>
> I have a difference solution both to the UDP socket lookup avoidance
> and configurable GRO in general.
>
> I've been sitting on it for too long. Let me slightly clean it up and
> send it out for discussion sake..
http://patchwork.ozlabs.org/project/netdev/list/?series=65763
That udp gro implementation is clearly less complete than yours in
this patchset. The point I wanted to bring up for discussion is not the
protocol implementation, but the infrastructure for enabling it
conditionally.
Assuming cycle cost is comparable, what do you think of using the
existing sk offload callbacks to enable this on a per-socket basis?
As for the protocol-wide knob, I do strongly prefer something that can
work for all protocols, not just UDP. I also implemented a version that
atomically swaps the struct ptr instead of the flag based approach I sent
for review. I'm fairly agnostic about that point. One subtle issue is that I
believe we need to keep the gro_complete callbacks enabled, as gro
packets may be queued for completion when gro_receive gets disabled.
^ permalink raw reply
* Re: [PATH RFC net-next 1/8] net: phy: Move linkmode helpers to somewhere public
From: Andrew Lunn @ 2018-09-16 19:18 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <a896ca76-d585-5f12-faca-e6ad5f386d4e@gmail.com>
> Good idea, I wonder if we should create a more specific directory within
> include/linux/ that can host a variety of PHYLIB, PHYLINK and what not
> header files, but this could be solved later on.
I'm leaving it for later.
We would also need to figure out a name for this directory. phy is
already used by the generic phy subsystem. So i guess we would have to
use something like ethernet-phy.
Andrew
^ permalink raw reply
* Re: [RFC PATCH iproute2-next] System specification health API
From: Stephen Hemminger @ 2018-09-16 19:29 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Eran Ben Elisha, netdev, Jiri Pirko, Andy Gospodarek,
Michael Chan, Simon Horman, Alexander Duyck, Andrew Lunn,
Florian Fainelli, Tal Alon, Ariel Almog
In-Reply-To: <20180913103604.0ef868f4@cakuba.netronome.com>
On Thu, 13 Sep 2018 10:36:04 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> On Thu, 13 Sep 2018 11:18:15 +0300, Eran Ben Elisha wrote:
> > The health spec is targeted for Real Time Alerting, in order to know when
> > something bad had happened to a PCI device
>
> By spec you mean some standards body spec you implement or this
> proposal is a spec?
>
> > - Provide alert debug information
> > - Self healing
> > - If problem needs vendor support, provide a way to gather all needed debugging
> > information.
> >
> > The health contains sensors which sense for malfunction. Once sensor triggered,
> > actions such as logs and correction can be taken.
> > Sensors are sensing the health state and can trigger correction action.
> >
> > The sensors are divided into the following groups
> > - Hardware sensor - a sensor which is triggered by the device due to
> > malfunction.
> > - Software sensor - a sensor which is triggered by the software due to
> > malfunction.
> > Both group of sensors can be triggered due to error event or due to a periodic check.
> >
> > Actions are the way to handle sensor events. Action can be in one of the
> > following groups:
> > - Dump - SW trace, SW dump, HW trace, HW dump
> > - Reset - Surgical correction (e.g. modify Q, flush Q, reset of device, etc)
> > Actions can be performed by SW or HW.
> >
> > User is allowed to enable or disable sensors and sensor2action mapping.
> >
> > This RFC man page patch describes the suggested API of devlink-health in order
> > to control sensors and actions.
>
> I like the idea of configuring response to events like this, although
> I'm not sure the name sensor is appropriate here - perhaps exception or
> error would be better? Are there going to be values reported?
>
> I'm not so sure about HW sensors in relation to existing HWMON
> infrastructure... I assume you're targeting things like say some HW
> engine/block reporting it encountered an error? Sounds good, too.
>
> Are the actions all envisioned to be performed by the driver?
> Firmware? Hardware? I guess that distinction can be added later.
> For FW/HW actions we would go back to the problem of persistence of
> the setting since it was only implemented for params :S
>
> Is the dump option going to tie back into region snapshots?
Why is this going under iproute rather than using one of the existing sensor API's.
For example Intel NIC's have thermal sensors etc.
^ permalink raw reply
* Re: [PATCH net-next v4 18/20] crypto: port ChaCha20 to Zinc
From: Martin Willi @ 2018-09-16 19:51 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: linux-kernel, netdev, linux-crypto, davem, gregkh, Samuel Neves,
Andy Lutomirski, Jean-Philippe Aumasson, Eric Biggers
In-Reply-To: <20180914162240.7925-19-Jason@zx2c4.com>
Hi Jason,
> Now that ChaCha20 is in Zinc, we can have the crypto API code simply
> call into it.
> delete mode 100644 arch/x86/crypto/chacha20-avx2-x86_64.S
> delete mode 100644 arch/x86/crypto/chacha20-ssse3-x86_64.S
I did some trivial benchmarking with tcrypt for the ChaCha20Poly1305
AEAD as used by IPsec. This is on a box with AVX2, which is probably
the configuration mostly used these days. With Zinc I get:
> testing speed of rfc7539esp(chacha20,poly1305) (rfc7539esp(chacha20-software,poly1305-software)) decryption
> test 0 (288 bit key, 16 byte blocks): 743510 operations in 1 seconds (11896160 bytes)
> test 1 (288 bit key, 64 byte blocks): 743190 operations in 1 seconds (47564160 bytes)
> test 2 (288 bit key, 256 byte blocks): 701461 operations in 1 seconds (179574016 bytes)
> test 3 (288 bit key, 512 byte blocks): 681567 operations in 1 seconds (348962304 bytes)
> test 4 (288 bit key, 1024 byte blocks): 572854 operations in 1 seconds (586602496 bytes)
> test 5 (288 bit key, 2048 byte blocks): 434477 operations in 1 seconds (889808896 bytes)
> test 6 (288 bit key, 4096 byte blocks): 293553 operations in 1 seconds (1202393088 bytes)
> test 7 (288 bit key, 8192 byte blocks): 173351 operations in 1 seconds (1420091392 bytes)
Using the existing implementation, this was:
> testing speed of rfc7539esp(chacha20,poly1305) (rfc7539esp(chacha20-simd,poly1305-simd)) decryption
> test 0 (288 bit key, 16 byte blocks): 1064524 operations in 1 seconds (17032384 bytes)
> test 1 (288 bit key, 64 byte blocks): 1016046 operations in 1 seconds (65026944 bytes)
> test 2 (288 bit key, 256 byte blocks): 829566 operations in 1 seconds (212368896 bytes)
> test 3 (288 bit key, 512 byte blocks): 778912 operations in 1 seconds (398802944 bytes)
> test 4 (288 bit key, 1024 byte blocks): 622331 operations in 1 seconds (637266944 bytes)
> test 5 (288 bit key, 2048 byte blocks): 441790 operations in 1 seconds (904785920 bytes)
> test 6 (288 bit key, 4096 byte blocks): 280616 operations in 1 seconds (1149403136 bytes)
> test 7 (288 bit key, 8192 byte blocks): 158800 operations in 1 seconds (1300889600 bytes)
I've also experimented with the SIMD context save/restore amortization
from patch one on the existing implementation:
> testing speed of rfc7539esp(chacha20,poly1305) (rfc7539esp(chacha20-simd,poly1305-simd)) decryption
> test 0 (288 bit key, 16 byte blocks): 1088215 operations in 1 seconds (17411440 bytes)
> test 1 (288 bit key, 64 byte blocks): 1001788 operations in 1 seconds (64114432 bytes)
> test 2 (288 bit key, 256 byte blocks): 870193 operations in 1 seconds (222769408 bytes)
> test 3 (288 bit key, 512 byte blocks): 822149 operations in 1 seconds (420940288 bytes)
> test 4 (288 bit key, 1024 byte blocks): 647447 operations in 1 seconds (662985728 bytes)
> test 5 (288 bit key, 2048 byte blocks): 454734 operations in 1 seconds (931295232 bytes)
> test 6 (288 bit key, 4096 byte blocks): 286995 operations in 1 seconds (1175531520 bytes)
> test 7 (288 bit key, 8192 byte blocks): 162028 operations in 1 seconds (1327333376 bytes)
For large blocks your implementation is faster; for typical IPsec MTUs
this degrades performance by ~10% and more.
Martin
^ 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