1. 05 2月, 2020 7 次提交
    • H
      net: macb: Remove unnecessary alignment check for TSO · 41c1ef97
      Harini Katakam 提交于
      The IP TSO implementation does NOT require the length to be a
      multiple of 8. That is only a requirement for UFO as per IP
      documentation. Hence, exit macb_features_check function in the
      beginning if the protocol is not UDP. Only when it is UDP,
      proceed further to the alignment checks. Update comments to
      reflect the same. Also remove dead code checking for protocol
      TCP when calculating header length.
      
      Fixes: 1629dd4f ("cadence: Add LSO support.")
      Signed-off-by: NHarini Katakam <harini.katakam@xilinx.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      41c1ef97
    • E
      bonding/alb: properly access headers in bond_alb_xmit() · 38f88c45
      Eric Dumazet 提交于
      syzbot managed to send an IPX packet through bond_alb_xmit()
      and af_packet and triggered a use-after-free.
      
      First, bond_alb_xmit() was using ipx_hdr() helper to reach
      the IPX header, but ipx_hdr() was using the transport offset
      instead of the network offset. In the particular syzbot
      report transport offset was 0xFFFF
      
      This patch removes ipx_hdr() since it was only (mis)used from bonding.
      
      Then we need to make sure IPv4/IPv6/IPX headers are pulled
      in skb->head before dereferencing anything.
      
      BUG: KASAN: use-after-free in bond_alb_xmit+0x153a/0x1590 drivers/net/bonding/bond_alb.c:1452
      Read of size 2 at addr ffff8801ce56dfff by task syz-executor.2/18108
       (if (ipx_hdr(skb)->ipx_checksum != IPX_NO_CHECKSUM) ...)
      
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       [<ffffffff8441fc42>] __dump_stack lib/dump_stack.c:17 [inline]
       [<ffffffff8441fc42>] dump_stack+0x14d/0x20b lib/dump_stack.c:53
       [<ffffffff81a7dec4>] print_address_description+0x6f/0x20b mm/kasan/report.c:282
       [<ffffffff81a7e0ec>] kasan_report_error mm/kasan/report.c:380 [inline]
       [<ffffffff81a7e0ec>] kasan_report mm/kasan/report.c:438 [inline]
       [<ffffffff81a7e0ec>] kasan_report.cold+0x8c/0x2a0 mm/kasan/report.c:422
       [<ffffffff81a7dc4f>] __asan_report_load_n_noabort+0xf/0x20 mm/kasan/report.c:469
       [<ffffffff82c8c00a>] bond_alb_xmit+0x153a/0x1590 drivers/net/bonding/bond_alb.c:1452
       [<ffffffff82c60c74>] __bond_start_xmit drivers/net/bonding/bond_main.c:4199 [inline]
       [<ffffffff82c60c74>] bond_start_xmit+0x4f4/0x1570 drivers/net/bonding/bond_main.c:4224
       [<ffffffff83baa558>] __netdev_start_xmit include/linux/netdevice.h:4525 [inline]
       [<ffffffff83baa558>] netdev_start_xmit include/linux/netdevice.h:4539 [inline]
       [<ffffffff83baa558>] xmit_one net/core/dev.c:3611 [inline]
       [<ffffffff83baa558>] dev_hard_start_xmit+0x168/0x910 net/core/dev.c:3627
       [<ffffffff83bacf35>] __dev_queue_xmit+0x1f55/0x33b0 net/core/dev.c:4238
       [<ffffffff83bae3a8>] dev_queue_xmit+0x18/0x20 net/core/dev.c:4278
       [<ffffffff84339189>] packet_snd net/packet/af_packet.c:3226 [inline]
       [<ffffffff84339189>] packet_sendmsg+0x4919/0x70b0 net/packet/af_packet.c:3252
       [<ffffffff83b1ac0c>] sock_sendmsg_nosec net/socket.c:673 [inline]
       [<ffffffff83b1ac0c>] sock_sendmsg+0x12c/0x160 net/socket.c:684
       [<ffffffff83b1f5a2>] __sys_sendto+0x262/0x380 net/socket.c:1996
       [<ffffffff83b1f700>] SYSC_sendto net/socket.c:2008 [inline]
       [<ffffffff83b1f700>] SyS_sendto+0x40/0x60 net/socket.c:2004
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Jay Vosburgh <j.vosburgh@gmail.com>
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38f88c45
    • M
      net: ethernet: dec: tulip: Fix length mask in receive length calculation · 33e2b32b
      Moritz Fischer 提交于
      The receive frame length calculation uses a wrong mask to calculate the
      length of the received frames.
      
      Per spec table 4-1 the length is contained in the FL (Frame Length)
      field in bits 30:16.
      
      This didn't show up as an issue so far since frames were limited to
      1500 bytes which falls within the 11 bit window.
      Signed-off-by: NMoritz Fischer <mdf@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      33e2b32b
    • J
      wireguard: noise: reject peers with low order public keys · ec31c267
      Jason A. Donenfeld 提交于
      Our static-static calculation returns a failure if the public key is of
      low order. We check for this when peers are added, and don't allow them
      to be added if they're low order, except in the case where we haven't
      yet been given a private key. In that case, we would defer the removal
      of the peer until we're given a private key, since at that point we're
      doing new static-static calculations which incur failures we can act on.
      This meant, however, that we wound up removing peers rather late in the
      configuration flow.
      
      Syzkaller points out that peer_remove calls flush_workqueue, which in
      turn might then wait for sending a handshake initiation to complete.
      Since handshake initiation needs the static identity lock, holding the
      static identity lock while calling peer_remove can result in a rare
      deadlock. We have precisely this case in this situation of late-stage
      peer removal based on an invalid public key. We can't drop the lock when
      removing, because then incoming handshakes might interact with a bogus
      static-static calculation.
      
      While the band-aid patch for this would involve breaking up the peer
      removal into two steps like wg_peer_remove_all does, in order to solve
      the locking issue, there's actually a much more elegant way of fixing
      this:
      
      If the static-static calculation succeeds with one private key, it
      *must* succeed with all others, because all 32-byte strings map to valid
      private keys, thanks to clamping. That means we can get rid of this
      silly dance and locking headaches of removing peers late in the
      configuration flow, and instead just reject them early on, regardless of
      whether the device has yet been assigned a private key. For the case
      where the device doesn't yet have a private key, we safely use zeros
      just for the purposes of checking for low order points by way of
      checking the output of the calculation.
      
      The following PoC will trigger the deadlock:
      
      ip link add wg0 type wireguard
      ip addr add 10.0.0.1/24 dev wg0
      ip link set wg0 up
      ping -f 10.0.0.2 &
      while true; do
              wg set wg0 private-key /dev/null peer AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= allowed-ips 10.0.0.0/24 endpoint 10.0.0.3:1234
              wg set wg0 private-key <(echo AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=)
      done
      
      [    0.949105] ======================================================
      [    0.949550] WARNING: possible circular locking dependency detected
      [    0.950143] 5.5.0-debug+ #18 Not tainted
      [    0.950431] ------------------------------------------------------
      [    0.950959] wg/89 is trying to acquire lock:
      [    0.951252] ffff8880333e2128 ((wq_completion)wg-kex-wg0){+.+.}, at: flush_workqueue+0xe3/0x12f0
      [    0.951865]
      [    0.951865] but task is already holding lock:
      [    0.952280] ffff888032819bc0 (&wg->static_identity.lock){++++}, at: wg_set_device+0x95d/0xcc0
      [    0.953011]
      [    0.953011] which lock already depends on the new lock.
      [    0.953011]
      [    0.953651]
      [    0.953651] the existing dependency chain (in reverse order) is:
      [    0.954292]
      [    0.954292] -> #2 (&wg->static_identity.lock){++++}:
      [    0.954804]        lock_acquire+0x127/0x350
      [    0.955133]        down_read+0x83/0x410
      [    0.955428]        wg_noise_handshake_create_initiation+0x97/0x700
      [    0.955885]        wg_packet_send_handshake_initiation+0x13a/0x280
      [    0.956401]        wg_packet_handshake_send_worker+0x10/0x20
      [    0.956841]        process_one_work+0x806/0x1500
      [    0.957167]        worker_thread+0x8c/0xcb0
      [    0.957549]        kthread+0x2ee/0x3b0
      [    0.957792]        ret_from_fork+0x24/0x30
      [    0.958234]
      [    0.958234] -> #1 ((work_completion)(&peer->transmit_handshake_work)){+.+.}:
      [    0.958808]        lock_acquire+0x127/0x350
      [    0.959075]        process_one_work+0x7ab/0x1500
      [    0.959369]        worker_thread+0x8c/0xcb0
      [    0.959639]        kthread+0x2ee/0x3b0
      [    0.959896]        ret_from_fork+0x24/0x30
      [    0.960346]
      [    0.960346] -> #0 ((wq_completion)wg-kex-wg0){+.+.}:
      [    0.960945]        check_prev_add+0x167/0x1e20
      [    0.961351]        __lock_acquire+0x2012/0x3170
      [    0.961725]        lock_acquire+0x127/0x350
      [    0.961990]        flush_workqueue+0x106/0x12f0
      [    0.962280]        peer_remove_after_dead+0x160/0x220
      [    0.962600]        wg_set_device+0xa24/0xcc0
      [    0.962994]        genl_rcv_msg+0x52f/0xe90
      [    0.963298]        netlink_rcv_skb+0x111/0x320
      [    0.963618]        genl_rcv+0x1f/0x30
      [    0.963853]        netlink_unicast+0x3f6/0x610
      [    0.964245]        netlink_sendmsg+0x700/0xb80
      [    0.964586]        __sys_sendto+0x1dd/0x2c0
      [    0.964854]        __x64_sys_sendto+0xd8/0x1b0
      [    0.965141]        do_syscall_64+0x90/0xd9a
      [    0.965408]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [    0.965769]
      [    0.965769] other info that might help us debug this:
      [    0.965769]
      [    0.966337] Chain exists of:
      [    0.966337]   (wq_completion)wg-kex-wg0 --> (work_completion)(&peer->transmit_handshake_work) --> &wg->static_identity.lock
      [    0.966337]
      [    0.967417]  Possible unsafe locking scenario:
      [    0.967417]
      [    0.967836]        CPU0                    CPU1
      [    0.968155]        ----                    ----
      [    0.968497]   lock(&wg->static_identity.lock);
      [    0.968779]                                lock((work_completion)(&peer->transmit_handshake_work));
      [    0.969345]                                lock(&wg->static_identity.lock);
      [    0.969809]   lock((wq_completion)wg-kex-wg0);
      [    0.970146]
      [    0.970146]  *** DEADLOCK ***
      [    0.970146]
      [    0.970531] 5 locks held by wg/89:
      [    0.970908]  #0: ffffffff827433c8 (cb_lock){++++}, at: genl_rcv+0x10/0x30
      [    0.971400]  #1: ffffffff82743480 (genl_mutex){+.+.}, at: genl_rcv_msg+0x642/0xe90
      [    0.971924]  #2: ffffffff827160c0 (rtnl_mutex){+.+.}, at: wg_set_device+0x9f/0xcc0
      [    0.972488]  #3: ffff888032819de0 (&wg->device_update_lock){+.+.}, at: wg_set_device+0xb0/0xcc0
      [    0.973095]  #4: ffff888032819bc0 (&wg->static_identity.lock){++++}, at: wg_set_device+0x95d/0xcc0
      [    0.973653]
      [    0.973653] stack backtrace:
      [    0.973932] CPU: 1 PID: 89 Comm: wg Not tainted 5.5.0-debug+ #18
      [    0.974476] Call Trace:
      [    0.974638]  dump_stack+0x97/0xe0
      [    0.974869]  check_noncircular+0x312/0x3e0
      [    0.975132]  ? print_circular_bug+0x1f0/0x1f0
      [    0.975410]  ? __kernel_text_address+0x9/0x30
      [    0.975727]  ? unwind_get_return_address+0x51/0x90
      [    0.976024]  check_prev_add+0x167/0x1e20
      [    0.976367]  ? graph_lock+0x70/0x160
      [    0.976682]  __lock_acquire+0x2012/0x3170
      [    0.976998]  ? register_lock_class+0x1140/0x1140
      [    0.977323]  lock_acquire+0x127/0x350
      [    0.977627]  ? flush_workqueue+0xe3/0x12f0
      [    0.977890]  flush_workqueue+0x106/0x12f0
      [    0.978147]  ? flush_workqueue+0xe3/0x12f0
      [    0.978410]  ? find_held_lock+0x2c/0x110
      [    0.978662]  ? lock_downgrade+0x6e0/0x6e0
      [    0.978919]  ? queue_rcu_work+0x60/0x60
      [    0.979166]  ? netif_napi_del+0x151/0x3b0
      [    0.979501]  ? peer_remove_after_dead+0x160/0x220
      [    0.979871]  peer_remove_after_dead+0x160/0x220
      [    0.980232]  wg_set_device+0xa24/0xcc0
      [    0.980516]  ? deref_stack_reg+0x8e/0xc0
      [    0.980801]  ? set_peer+0xe10/0xe10
      [    0.981040]  ? __ww_mutex_check_waiters+0x150/0x150
      [    0.981430]  ? __nla_validate_parse+0x163/0x270
      [    0.981719]  ? genl_family_rcv_msg_attrs_parse+0x13f/0x310
      [    0.982078]  genl_rcv_msg+0x52f/0xe90
      [    0.982348]  ? genl_family_rcv_msg_attrs_parse+0x310/0x310
      [    0.982690]  ? register_lock_class+0x1140/0x1140
      [    0.983049]  netlink_rcv_skb+0x111/0x320
      [    0.983298]  ? genl_family_rcv_msg_attrs_parse+0x310/0x310
      [    0.983645]  ? netlink_ack+0x880/0x880
      [    0.983888]  genl_rcv+0x1f/0x30
      [    0.984168]  netlink_unicast+0x3f6/0x610
      [    0.984443]  ? netlink_detachskb+0x60/0x60
      [    0.984729]  ? find_held_lock+0x2c/0x110
      [    0.984976]  netlink_sendmsg+0x700/0xb80
      [    0.985220]  ? netlink_broadcast_filtered+0xa60/0xa60
      [    0.985533]  __sys_sendto+0x1dd/0x2c0
      [    0.985763]  ? __x64_sys_getpeername+0xb0/0xb0
      [    0.986039]  ? sockfd_lookup_light+0x17/0x160
      [    0.986397]  ? __sys_recvmsg+0x8c/0xf0
      [    0.986711]  ? __sys_recvmsg_sock+0xd0/0xd0
      [    0.987018]  __x64_sys_sendto+0xd8/0x1b0
      [    0.987283]  ? lockdep_hardirqs_on+0x39b/0x5a0
      [    0.987666]  do_syscall_64+0x90/0xd9a
      [    0.987903]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [    0.988223] RIP: 0033:0x7fe77c12003e
      [    0.988508] Code: c3 8b 07 85 c0 75 24 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 4
      [    0.989666] RSP: 002b:00007fffada2ed58 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      [    0.990137] RAX: ffffffffffffffda RBX: 00007fe77c159d48 RCX: 00007fe77c12003e
      [    0.990583] RDX: 0000000000000040 RSI: 000055fd1d38e020 RDI: 0000000000000004
      [    0.991091] RBP: 000055fd1d38e020 R08: 000055fd1cb63358 R09: 000000000000000c
      [    0.991568] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000002c
      [    0.992014] R13: 0000000000000004 R14: 000055fd1d38e020 R15: 0000000000000001
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec31c267
    • E
      wireguard: allowedips: fix use-after-free in root_remove_peer_lists · 9981159f
      Eric Dumazet 提交于
      In the unlikely case a new node could not be allocated, we need to
      remove @newnode from @peer->allowedips_list before freeing it.
      
      syzbot reported:
      
      BUG: KASAN: use-after-free in __list_del_entry_valid+0xdc/0xf5 lib/list_debug.c:54
      Read of size 8 at addr ffff88809881a538 by task syz-executor.4/30133
      
      CPU: 0 PID: 30133 Comm: syz-executor.4 Not tainted 5.5.0-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x197/0x210 lib/dump_stack.c:118
       print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
       __kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506
       kasan_report+0x12/0x20 mm/kasan/common.c:639
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
       __list_del_entry_valid+0xdc/0xf5 lib/list_debug.c:54
       __list_del_entry include/linux/list.h:132 [inline]
       list_del include/linux/list.h:146 [inline]
       root_remove_peer_lists+0x24f/0x4b0 drivers/net/wireguard/allowedips.c:65
       wg_allowedips_free+0x232/0x390 drivers/net/wireguard/allowedips.c:300
       wg_peer_remove_all+0xd5/0x620 drivers/net/wireguard/peer.c:187
       wg_set_device+0xd01/0x1350 drivers/net/wireguard/netlink.c:542
       genl_family_rcv_msg_doit net/netlink/genetlink.c:672 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:717 [inline]
       genl_rcv_msg+0x67d/0xea0 net/netlink/genetlink.c:734
       netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
       genl_rcv+0x29/0x40 net/netlink/genetlink.c:745
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0x59e/0x7e0 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:672
       ____sys_sendmsg+0x753/0x880 net/socket.c:2343
       ___sys_sendmsg+0x100/0x170 net/socket.c:2397
       __sys_sendmsg+0x105/0x1d0 net/socket.c:2430
       __do_sys_sendmsg net/socket.c:2439 [inline]
       __se_sys_sendmsg net/socket.c:2437 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2437
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x45b399
      Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f99a9bcdc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f99a9bce6d4 RCX: 000000000045b399
      RDX: 0000000000000000 RSI: 0000000020001340 RDI: 0000000000000003
      RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004
      R13: 00000000000009ba R14: 00000000004cb2b8 R15: 0000000000000009
      
      Allocated by task 30103:
       save_stack+0x23/0x90 mm/kasan/common.c:72
       set_track mm/kasan/common.c:80 [inline]
       __kasan_kmalloc mm/kasan/common.c:513 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:486
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:527
       kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3551
       kmalloc include/linux/slab.h:556 [inline]
       kzalloc include/linux/slab.h:670 [inline]
       add+0x70a/0x1970 drivers/net/wireguard/allowedips.c:236
       wg_allowedips_insert_v4+0xf6/0x160 drivers/net/wireguard/allowedips.c:320
       set_allowedip drivers/net/wireguard/netlink.c:343 [inline]
       set_peer+0xfb9/0x1150 drivers/net/wireguard/netlink.c:468
       wg_set_device+0xbd4/0x1350 drivers/net/wireguard/netlink.c:591
       genl_family_rcv_msg_doit net/netlink/genetlink.c:672 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:717 [inline]
       genl_rcv_msg+0x67d/0xea0 net/netlink/genetlink.c:734
       netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
       genl_rcv+0x29/0x40 net/netlink/genetlink.c:745
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0x59e/0x7e0 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:672
       ____sys_sendmsg+0x753/0x880 net/socket.c:2343
       ___sys_sendmsg+0x100/0x170 net/socket.c:2397
       __sys_sendmsg+0x105/0x1d0 net/socket.c:2430
       __do_sys_sendmsg net/socket.c:2439 [inline]
       __se_sys_sendmsg net/socket.c:2437 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2437
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 30103:
       save_stack+0x23/0x90 mm/kasan/common.c:72
       set_track mm/kasan/common.c:80 [inline]
       kasan_set_free_info mm/kasan/common.c:335 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:474
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:483
       __cache_free mm/slab.c:3426 [inline]
       kfree+0x10a/0x2c0 mm/slab.c:3757
       add+0x12d2/0x1970 drivers/net/wireguard/allowedips.c:266
       wg_allowedips_insert_v4+0xf6/0x160 drivers/net/wireguard/allowedips.c:320
       set_allowedip drivers/net/wireguard/netlink.c:343 [inline]
       set_peer+0xfb9/0x1150 drivers/net/wireguard/netlink.c:468
       wg_set_device+0xbd4/0x1350 drivers/net/wireguard/netlink.c:591
       genl_family_rcv_msg_doit net/netlink/genetlink.c:672 [inline]
       genl_family_rcv_msg net/netlink/genetlink.c:717 [inline]
       genl_rcv_msg+0x67d/0xea0 net/netlink/genetlink.c:734
       netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
       genl_rcv+0x29/0x40 net/netlink/genetlink.c:745
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0x59e/0x7e0 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:672
       ____sys_sendmsg+0x753/0x880 net/socket.c:2343
       ___sys_sendmsg+0x100/0x170 net/socket.c:2397
       __sys_sendmsg+0x105/0x1d0 net/socket.c:2430
       __do_sys_sendmsg net/socket.c:2439 [inline]
       __se_sys_sendmsg net/socket.c:2437 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2437
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff88809881a500
       which belongs to the cache kmalloc-64 of size 64
      The buggy address is located 56 bytes inside of
       64-byte region [ffff88809881a500, ffff88809881a540)
      The buggy address belongs to the page:
      page:ffffea0002620680 refcount:1 mapcount:0 mapping:ffff8880aa400380 index:0x0
      raw: 00fffe0000000200 ffffea000250b748 ffffea000254bac8 ffff8880aa400380
      raw: 0000000000000000 ffff88809881a000 0000000100000020 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88809881a400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff88809881a480: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
      >ffff88809881a500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
                                              ^
       ffff88809881a580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff88809881a600: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
      
      Fixes: e7096c13 ("net: WireGuard secure network tunnel")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Jason A. Donenfeld <Jason@zx2c4.com>
      Cc: wireguard@lists.zx2c4.com
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9981159f
    • K
      netdevsim: fix ptr_ret.cocci warnings · 34611e69
      kbuild test robot 提交于
      drivers/net/netdevsim/dev.c:937:1-3: WARNING: PTR_ERR_OR_ZERO can be used
      
       Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
      
      Generated by: scripts/coccinelle/api/ptr_ret.cocci
      
      Fixes: 6556ff32 ("netdevsim: use IS_ERR instead of IS_ERR_OR_NULL for debugfs")
      CC: Taehee Yoo <ap420073@gmail.com>
      Signed-off-by: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      34611e69
    • T
      net: sgi: ioc3-eth: Remove leftover free_irq() · 9784e619
      Thomas Bogendoerfer 提交于
      Commit 0ce5ebd2 ("mfd: ioc3: Add driver for SGI IOC3 chip") moved
      request_irq() from ioc3_open into probe function, but forgot to remove
      free_irq() from ioc3_close.
      
      Fixes: 0ce5ebd2 ("mfd: ioc3: Add driver for SGI IOC3 chip")
      Signed-off-by: NThomas Bogendoerfer <tbogendoerfer@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9784e619
  2. 04 2月, 2020 16 次提交
    • T
      gtp: use __GFP_NOWARN to avoid memalloc warning · bd5cd35b
      Taehee Yoo 提交于
      gtp hashtable size is received by user-space.
      So, this hashtable size could be too large. If so, kmalloc will internally
      print a warning message.
      This warning message is actually not necessary for the gtp module.
      So, this patch adds __GFP_NOWARN to avoid this message.
      
      Splat looks like:
      [ 2171.200049][ T1860] WARNING: CPU: 1 PID: 1860 at mm/page_alloc.c:4713 __alloc_pages_nodemask+0x2f3/0x740
      [ 2171.238885][ T1860] Modules linked in: gtp veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv]
      [ 2171.262680][ T1860] CPU: 1 PID: 1860 Comm: gtp-link Not tainted 5.5.0+ #321
      [ 2171.263567][ T1860] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [ 2171.264681][ T1860] RIP: 0010:__alloc_pages_nodemask+0x2f3/0x740
      [ 2171.265332][ T1860] Code: 64 fe ff ff 65 48 8b 04 25 c0 0f 02 00 48 05 f0 12 00 00 41 be 01 00 00 00 49 89 47 0
      [ 2171.267301][ T1860] RSP: 0018:ffff8880b51af1f0 EFLAGS: 00010246
      [ 2171.268320][ T1860] RAX: ffffed1016a35e43 RBX: 0000000000000000 RCX: 0000000000000000
      [ 2171.269517][ T1860] RDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000000000
      [ 2171.270305][ T1860] RBP: 0000000000040cc0 R08: ffffed1018893109 R09: dffffc0000000000
      [ 2171.275973][ T1860] R10: 0000000000000001 R11: ffffed1018893108 R12: 1ffff11016a35e43
      [ 2171.291039][ T1860] R13: 000000000000000b R14: 000000000000000b R15: 00000000000f4240
      [ 2171.292328][ T1860] FS:  00007f53cbc83740(0000) GS:ffff8880da000000(0000) knlGS:0000000000000000
      [ 2171.293409][ T1860] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 2171.294586][ T1860] CR2: 000055f540014508 CR3: 00000000b49f2004 CR4: 00000000000606e0
      [ 2171.295424][ T1860] Call Trace:
      [ 2171.295756][ T1860]  ? mark_held_locks+0xa5/0xe0
      [ 2171.296659][ T1860]  ? __alloc_pages_slowpath+0x21b0/0x21b0
      [ 2171.298283][ T1860]  ? gtp_encap_enable_socket+0x13e/0x400 [gtp]
      [ 2171.298962][ T1860]  ? alloc_pages_current+0xc1/0x1a0
      [ 2171.299475][ T1860]  kmalloc_order+0x22/0x80
      [ 2171.299936][ T1860]  kmalloc_order_trace+0x1d/0x140
      [ 2171.300437][ T1860]  __kmalloc+0x302/0x3a0
      [ 2171.300896][ T1860]  gtp_newlink+0x293/0xba0 [gtp]
      [ ... ]
      
      Fixes: 459aa660 ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd5cd35b
    • K
      r8152: Add MAC passthrough support to new device · b4b771fd
      Kai-Heng Feng 提交于
      Device 0xa387 also supports MAC passthrough, therefore add it to the
      whitelst.
      
      BugLink: https://bugs.launchpad.net/bugs/1827961/comments/30Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4b771fd
    • Y
      qed: Remove set but not used variable 'p_link' · 83b43045
      YueHaibing 提交于
      Fixes gcc '-Wunused-but-set-variable' warning:
      
      drivers/net/ethernet/qlogic/qed/qed_cxt.c: In function 'qed_qm_init_pf':
      drivers/net/ethernet/qlogic/qed/qed_cxt.c:1401:29: warning:
       variable 'p_link' set but not used [-Wunused-but-set-variable]
      
      commit 92fae6fb ("qed: FW 8.42.2.0 Queue Manager changes")
      leave behind this unused variable.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83b43045
    • A
      proc: convert everything to "struct proc_ops" · 97a32539
      Alexey Dobriyan 提交于
      The most notable change is DEFINE_SHOW_ATTRIBUTE macro split in
      seq_file.h.
      
      Conversion rule is:
      
      	llseek		=> proc_lseek
      	unlocked_ioctl	=> proc_ioctl
      
      	xxx		=> proc_xxx
      
      	delete ".owner = THIS_MODULE" line
      
      [akpm@linux-foundation.org: fix drivers/isdn/capi/kcapi_proc.c]
      [sfr@canb.auug.org.au: fix kernel/sched/psi.c]
        Link: http://lkml.kernel.org/r/20200122180545.36222f50@canb.auug.org.au
      Link: http://lkml.kernel.org/r/20191225172546.GB13378@avx2Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      97a32539
    • T
      netdevsim: remove unused sdev code · 24531163
      Taehee Yoo 提交于
      sdev.c code is merged into dev.c and is not used anymore.
      it would be removed.
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      24531163
    • T
      netdevsim: use __GFP_NOWARN to avoid memalloc warning · 83cf4213
      Taehee Yoo 提交于
      vfnum buffer size and binary_len buffer size is received by user-space.
      So, this buffer size could be too large. If so, kmalloc will internally
      print a warning message.
      This warning message is actually not necessary for the netdevsim module.
      So, this patch adds __GFP_NOWARN.
      
      Test commands:
          modprobe netdevsim
          echo 1 > /sys/bus/netdevsim/new_device
          echo 1000000000 > /sys/devices/netdevsim1/sriov_numvfs
      
      Splat looks like:
      [  357.847266][ T1000] WARNING: CPU: 0 PID: 1000 at mm/page_alloc.c:4738 __alloc_pages_nodemask+0x2f3/0x740
      [  357.850273][ T1000] Modules linked in: netdevsim veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrx
      [  357.852989][ T1000] CPU: 0 PID: 1000 Comm: bash Tainted: G    B             5.5.0-rc5+ #270
      [  357.854334][ T1000] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  357.855703][ T1000] RIP: 0010:__alloc_pages_nodemask+0x2f3/0x740
      [  357.856669][ T1000] Code: 64 fe ff ff 65 48 8b 04 25 c0 0f 02 00 48 05 f0 12 00 00 41 be 01 00 00 00 49 89 47 0
      [  357.860272][ T1000] RSP: 0018:ffff8880b7f47bd8 EFLAGS: 00010246
      [  357.861009][ T1000] RAX: ffffed1016fe8f80 RBX: 1ffff11016fe8fae RCX: 0000000000000000
      [  357.861843][ T1000] RDX: 0000000000000000 RSI: 0000000000000017 RDI: 0000000000000000
      [  357.862661][ T1000] RBP: 0000000000040dc0 R08: 1ffff11016fe8f67 R09: dffffc0000000000
      [  357.863509][ T1000] R10: ffff8880b7f47d68 R11: fffffbfff2798180 R12: 1ffff11016fe8f80
      [  357.864355][ T1000] R13: 0000000000000017 R14: 0000000000000017 R15: ffff8880c2038d68
      [  357.865178][ T1000] FS:  00007fd9a5b8c740(0000) GS:ffff8880d9c00000(0000) knlGS:0000000000000000
      [  357.866248][ T1000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  357.867531][ T1000] CR2: 000055ce01ba8100 CR3: 00000000b7dbe005 CR4: 00000000000606f0
      [  357.868972][ T1000] Call Trace:
      [  357.869423][ T1000]  ? lock_contended+0xcd0/0xcd0
      [  357.870001][ T1000]  ? __alloc_pages_slowpath+0x21d0/0x21d0
      [  357.870673][ T1000]  ? _kstrtoull+0x76/0x160
      [  357.871148][ T1000]  ? alloc_pages_current+0xc1/0x1a0
      [  357.871704][ T1000]  kmalloc_order+0x22/0x80
      [  357.872184][ T1000]  kmalloc_order_trace+0x1d/0x140
      [  357.872733][ T1000]  __kmalloc+0x302/0x3a0
      [  357.873204][ T1000]  nsim_bus_dev_numvfs_store+0x1ab/0x260 [netdevsim]
      [  357.873919][ T1000]  ? kernfs_get_active+0x12c/0x180
      [  357.874459][ T1000]  ? new_device_store+0x450/0x450 [netdevsim]
      [  357.875111][ T1000]  ? kernfs_get_parent+0x70/0x70
      [  357.875632][ T1000]  ? sysfs_file_ops+0x160/0x160
      [  357.876152][ T1000]  kernfs_fop_write+0x276/0x410
      [  357.876680][ T1000]  ? __sb_start_write+0x1ba/0x2e0
      [  357.877225][ T1000]  vfs_write+0x197/0x4a0
      [  357.877671][ T1000]  ksys_write+0x141/0x1d0
      [ ... ]
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Fixes: 79579220 ("netdevsim: add SR-IOV functionality")
      Fixes: 82c93a87 ("netdevsim: implement couple of testing devlink health reporters")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      83cf4213
    • T
      netdevsim: use IS_ERR instead of IS_ERR_OR_NULL for debugfs · 6556ff32
      Taehee Yoo 提交于
      Debugfs APIs return valid pointer or error pointer. it doesn't return NULL.
      So, using IS_ERR is enough, not using IS_ERR_OR_NULL.
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      6556ff32
    • T
      netdevsim: fix stack-out-of-bounds in nsim_dev_debugfs_init() · 6fb8852b
      Taehee Yoo 提交于
      When netdevsim dev is being created, a debugfs directory is created.
      The variable "dev_ddir_name" is 16bytes device name pointer and device
      name is "netdevsim<dev id>".
      The maximum dev id length is 10.
      So, 16bytes for device name isn't enough.
      
      Test commands:
          modprobe netdevsim
          echo "1000000000 0" > /sys/bus/netdevsim/new_device
      
      Splat looks like:
      [  249.622710][  T900] BUG: KASAN: stack-out-of-bounds in number+0x824/0x880
      [  249.623658][  T900] Write of size 1 at addr ffff88804c527988 by task bash/900
      [  249.624521][  T900]
      [  249.624830][  T900] CPU: 1 PID: 900 Comm: bash Not tainted 5.5.0+ #322
      [  249.625691][  T900] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  249.626712][  T900] Call Trace:
      [  249.627103][  T900]  dump_stack+0x96/0xdb
      [  249.627639][  T900]  ? number+0x824/0x880
      [  249.628173][  T900]  print_address_description.constprop.5+0x1be/0x360
      [  249.629022][  T900]  ? number+0x824/0x880
      [  249.629569][  T900]  ? number+0x824/0x880
      [  249.630105][  T900]  __kasan_report+0x12a/0x170
      [  249.630717][  T900]  ? number+0x824/0x880
      [  249.631201][  T900]  kasan_report+0xe/0x20
      [  249.631723][  T900]  number+0x824/0x880
      [  249.632235][  T900]  ? put_dec+0xa0/0xa0
      [  249.632716][  T900]  ? rcu_read_lock_sched_held+0x90/0xc0
      [  249.633392][  T900]  vsnprintf+0x63c/0x10b0
      [  249.633983][  T900]  ? pointer+0x5b0/0x5b0
      [  249.634543][  T900]  ? mark_lock+0x11d/0xc40
      [  249.635200][  T900]  sprintf+0x9b/0xd0
      [  249.635750][  T900]  ? scnprintf+0xe0/0xe0
      [  249.636370][  T900]  nsim_dev_probe+0x63c/0xbf0 [netdevsim]
      [ ... ]
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Fixes: ab1d0cc0 ("netdevsim: change debugfs tree topology")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      6fb8852b
    • T
      netdevsim: fix panic in nsim_dev_take_snapshot_write() · 8526ad96
      Taehee Yoo 提交于
      nsim_dev_take_snapshot_write() uses nsim_dev and nsim_dev->dummy_region.
      So, during this function, these data shouldn't be removed.
      But there is no protecting stuff in this function.
      
      There are two similar cases.
      1. reload case
      reload could be called during nsim_dev_take_snapshot_write().
      When reload is being executed, nsim_dev_reload_down() is called and it
      calls nsim_dev_reload_destroy(). nsim_dev_reload_destroy() calls
      devlink_region_destroy() to destroy nsim_dev->dummy_region.
      So, during nsim_dev_take_snapshot_write(), nsim_dev->dummy_region()
      would be removed.
      At this point, snapshot_write() would access freed pointer.
      In order to fix this case, take_snapshot file will be removed before
      devlink_region_destroy().
      The take_snapshot file will be re-created by ->reload_up().
      
      2. del_device_store case
      del_device_store() also could call nsim_dev_reload_destroy()
      during nsim_dev_take_snapshot_write(). If so, panic would occur.
      This problem is actually the same problem with the first case.
      So, this problem will be fixed by the first case's solution.
      
      Test commands:
          modprobe netdevsim
          while :
          do
              echo 1 > /sys/bus/netdevsim/new_device &
              echo 1 > /sys/bus/netdevsim/del_device &
      	devlink dev reload netdevsim/netdevsim1 &
      	echo 1 > /sys/kernel/debug/netdevsim/netdevsim1/take_snapshot &
          done
      
      Splat looks like:
      [   45.564513][  T975] general protection fault, probably for non-canonical address 0xdffffc000000003a: 0000 [#1] SMP DEI
      [   45.566131][  T975] KASAN: null-ptr-deref in range [0x00000000000001d0-0x00000000000001d7]
      [   45.566135][  T975] CPU: 1 PID: 975 Comm: bash Not tainted 5.5.0+ #322
      [   45.569020][  T975] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   45.569026][  T975] RIP: 0010:__mutex_lock+0x10a/0x14b0
      [   45.570518][  T975] Code: 08 84 d2 0f 85 7f 12 00 00 44 8b 0d 10 23 65 02 45 85 c9 75 29 49 8d 7f 68 48 b8 00 00 00 0f
      [   45.570522][  T975] RSP: 0018:ffff888046ccfbf0 EFLAGS: 00010206
      [   45.572305][  T975] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [   45.572308][  T975] RDX: 000000000000003a RSI: ffffffffac926440 RDI: 00000000000001d0
      [   45.576843][  T975] RBP: ffff888046ccfd70 R08: ffffffffab610645 R09: 0000000000000000
      [   45.576847][  T975] R10: ffff888046ccfd90 R11: ffffed100d6360ad R12: 0000000000000000
      [   45.578471][  T975] R13: dffffc0000000000 R14: ffffffffae1976c0 R15: 0000000000000168
      [   45.578475][  T975] FS:  00007f614d6e7740(0000) GS:ffff88806c400000(0000) knlGS:0000000000000000
      [   45.581492][  T975] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   45.582942][  T975] CR2: 00005618677d1cf0 CR3: 000000005fb9c002 CR4: 00000000000606e0
      [   45.584543][  T975] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   45.586633][  T975] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   45.589889][  T975] Call Trace:
      [   45.591445][  T975]  ? devlink_region_snapshot_create+0x55/0x4a0
      [   45.601250][  T975]  ? mutex_lock_io_nested+0x1380/0x1380
      [   45.602817][  T975]  ? mutex_lock_io_nested+0x1380/0x1380
      [   45.603875][  T975]  ? mark_held_locks+0xa5/0xe0
      [   45.604769][  T975]  ? _raw_spin_unlock_irqrestore+0x2d/0x50
      [   45.606147][  T975]  ? __mutex_unlock_slowpath+0xd0/0x670
      [   45.607723][  T975]  ? crng_backtrack_protect+0x80/0x80
      [   45.613530][  T975]  ? wait_for_completion+0x390/0x390
      [   45.615152][  T975]  ? devlink_region_snapshot_create+0x55/0x4a0
      [   45.616834][  T975]  devlink_region_snapshot_create+0x55/0x4a0
      [ ... ]
      
      Fixes: 4418f862 ("netdevsim: implement support for devlink region and snapshots")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      8526ad96
    • T
      netdevsim: disable devlink reload when resources are being used · 6ab63366
      Taehee Yoo 提交于
      devlink reload destroys resources and allocates resources again.
      So, when devices and ports resources are being used, devlink reload
      function should not be executed. In order to avoid this race, a new
      lock is added and new_port() and del_port() call devlink_reload_disable()
      and devlink_reload_enable().
      
      Thread0                      Thread1
      {new/del}_port()             {new/del}_port()
      devlink_reload_disable()
                                   devlink_reload_disable()
      devlink_reload_enable()
                                   //here
                                   devlink_reload_enable()
      
      Before Thread1's devlink_reload_enable(), the devlink is already allowed
      to execute reload because Thread0 allows it. devlink reload disable/enable
      variable type is bool. So the above case would exist.
      So, disable/enable should be executed atomically.
      In order to do that, a new lock is used.
      
      Test commands:
          modprobe netdevsim
          echo 1 > /sys/bus/netdevsim/new_device
          while :
          do
              echo 1 > /sys/devices/netdevsim1/new_port &
              echo 1 > /sys/devices/netdevsim1/del_port &
              devlink dev reload netdevsim/netdevsim1 &
          done
      
      Splat looks like:
      [   23.342145][  T932] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock))
      [   23.342159][  T932] WARNING: CPU: 0 PID: 932 at kernel/locking/mutex-debug.c:103 mutex_destroy+0xc7/0xf0
      [   23.344182][  T932] Modules linked in: netdevsim openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_dx
      [   23.346485][  T932] CPU: 0 PID: 932 Comm: devlink Not tainted 5.5.0+ #322
      [   23.347696][  T932] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   23.348893][  T932] RIP: 0010:mutex_destroy+0xc7/0xf0
      [   23.349505][  T932] Code: e0 07 83 c0 03 38 d0 7c 04 84 d2 75 2e 8b 05 00 ac b0 02 85 c0 75 8b 48 c7 c6 00 5e 07 96 40
      [   23.351887][  T932] RSP: 0018:ffff88806208f810 EFLAGS: 00010286
      [   23.353963][  T932] RAX: dffffc0000000008 RBX: ffff888067f6f2c0 RCX: ffffffff942c4bd4
      [   23.355222][  T932] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff96dac5b4
      [   23.356169][  T932] RBP: ffff888067f6f000 R08: fffffbfff2d235a5 R09: fffffbfff2d235a5
      [   23.357160][  T932] R10: 0000000000000001 R11: fffffbfff2d235a4 R12: ffff888067f6f208
      [   23.358288][  T932] R13: ffff88806208fa70 R14: ffff888067f6f000 R15: ffff888069ce3800
      [   23.359307][  T932] FS:  00007fe2a3876740(0000) GS:ffff88806c000000(0000) knlGS:0000000000000000
      [   23.360473][  T932] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   23.361319][  T932] CR2: 00005561357aa000 CR3: 000000005227a006 CR4: 00000000000606f0
      [   23.362323][  T932] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   23.363417][  T932] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   23.364414][  T932] Call Trace:
      [   23.364828][  T932]  nsim_dev_reload_destroy+0x77/0xb0 [netdevsim]
      [   23.365655][  T932]  nsim_dev_reload_down+0x84/0xb0 [netdevsim]
      [   23.366433][  T932]  devlink_reload+0xb1/0x350
      [   23.367010][  T932]  genl_rcv_msg+0x580/0xe90
      
      [ ...]
      
      [   23.531729][ T1305] kernel BUG at lib/list_debug.c:53!
      [   23.532523][ T1305] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [   23.533467][ T1305] CPU: 2 PID: 1305 Comm: bash Tainted: G        W         5.5.0+ #322
      [   23.534962][ T1305] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   23.536503][ T1305] RIP: 0010:__list_del_entry_valid+0xe6/0x150
      [   23.538346][ T1305] Code: 89 ea 48 c7 c7 00 73 1e 96 e8 df f7 4c ff 0f 0b 48 c7 c7 60 73 1e 96 e8 d1 f7 4c ff 0f 0b 44
      [   23.541068][ T1305] RSP: 0018:ffff888047c27b58 EFLAGS: 00010282
      [   23.542001][ T1305] RAX: 0000000000000054 RBX: ffff888067f6f318 RCX: 0000000000000000
      [   23.543051][ T1305] RDX: 0000000000000054 RSI: 0000000000000008 RDI: ffffed1008f84f61
      [   23.544072][ T1305] RBP: ffff88804aa0fca0 R08: ffffed100d940539 R09: ffffed100d940539
      [   23.545085][ T1305] R10: 0000000000000001 R11: ffffed100d940538 R12: ffff888047c27cb0
      [   23.546422][ T1305] R13: ffff88806208b840 R14: ffffffff981976c0 R15: ffff888067f6f2c0
      [   23.547406][ T1305] FS:  00007f76c0431740(0000) GS:ffff88806c800000(0000) knlGS:0000000000000000
      [   23.548527][ T1305] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   23.549389][ T1305] CR2: 00007f5048f1a2f8 CR3: 000000004b310006 CR4: 00000000000606e0
      [   23.550636][ T1305] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   23.551578][ T1305] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   23.552597][ T1305] Call Trace:
      [   23.553004][ T1305]  mutex_remove_waiter+0x101/0x520
      [   23.553646][ T1305]  __mutex_lock+0xac7/0x14b0
      [   23.554218][ T1305]  ? nsim_dev_port_del+0x4e/0x140 [netdevsim]
      [   23.554908][ T1305]  ? mutex_lock_io_nested+0x1380/0x1380
      [   23.555570][ T1305]  ? _parse_integer+0xf0/0xf0
      [   23.556043][ T1305]  ? kstrtouint+0x86/0x110
      [   23.556504][ T1305]  ? nsim_dev_port_del+0x4e/0x140 [netdevsim]
      [   23.557133][ T1305]  nsim_dev_port_del+0x4e/0x140 [netdevsim]
      [   23.558024][ T1305]  del_port_store+0xcc/0xf0 [netdevsim]
      [ ... ]
      
      Fixes: 75ba029f ("netdevsim: implement proper devlink reload")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      6ab63366
    • T
      netdevsim: fix using uninitialized resources · f5cd2160
      Taehee Yoo 提交于
      When module is being initialized, __init() calls bus_register() and
      driver_register().
      These functions internally create various resources and sysfs files.
      The sysfs files are used for basic operations(add/del device).
      /sys/bus/netdevsim/new_device
      /sys/bus/netdevsim/del_device
      
      These sysfs files use netdevsim resources, they are mostly allocated
      and initialized in ->probe() function, which is nsim_dev_probe().
      But, sysfs files could be executed before ->probe() is finished.
      So, accessing uninitialized data would occur.
      
      Another problem is very similar.
      /sys/bus/netdevsim/new_device internally creates sysfs files.
      /sys/devices/netdevsim<id>/new_port
      /sys/devices/netdevsim<id>/del_port
      
      These sysfs files also use netdevsim resources, they are mostly allocated
      and initialized in creating device routine, which is nsim_bus_dev_new().
      But they also could be executed before nsim_bus_dev_new() is finished.
      So, accessing uninitialized data would occur.
      
      To fix these problems, this patch adds flags, which means whether the
      operation is finished or not.
      The flag variable 'nsim_bus_enable' means whether netdevsim bus was
      initialized or not.
      This is protected by nsim_bus_dev_list_lock.
      The flag variable 'nsim_bus_dev->init' means whether nsim_bus_dev was
      initialized or not.
      This could be used in {new/del}_port_store() with no lock.
      
      Test commands:
          #SHELL1
          modprobe netdevsim
          while :
          do
              echo "1 1" > /sys/bus/netdevsim/new_device
              echo "1 1" > /sys/bus/netdevsim/del_device
          done
      
          #SHELL2
          while :
          do
              echo 1 > /sys/devices/netdevsim1/new_port
              echo 1 > /sys/devices/netdevsim1/del_port
          done
      
      Splat looks like:
      [   47.508954][ T1008] general protection fault, probably for non-canonical address 0xdffffc0000000021: 0000 I
      [   47.510793][ T1008] KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]
      [   47.511963][ T1008] CPU: 2 PID: 1008 Comm: bash Not tainted 5.5.0+ #322
      [   47.512823][ T1008] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   47.514041][ T1008] RIP: 0010:__mutex_lock+0x10a/0x14b0
      [   47.514699][ T1008] Code: 08 84 d2 0f 85 7f 12 00 00 44 8b 0d 10 23 65 02 45 85 c9 75 29 49 8d 7f 68 48 b8 00 00 00 0f
      [   47.517163][ T1008] RSP: 0018:ffff888059b4fbb0 EFLAGS: 00010206
      [   47.517802][ T1008] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [   47.518941][ T1008] RDX: 0000000000000021 RSI: ffffffff85926440 RDI: 0000000000000108
      [   47.519732][ T1008] RBP: ffff888059b4fd30 R08: ffffffffc073fad0 R09: 0000000000000000
      [   47.520729][ T1008] R10: ffff888059b4fd50 R11: ffff88804bb38040 R12: 0000000000000000
      [   47.521702][ T1008] R13: dffffc0000000000 R14: ffffffff871976c0 R15: 00000000000000a0
      [   47.522760][ T1008] FS:  00007fd4be05a740(0000) GS:ffff88806c800000(0000) knlGS:0000000000000000
      [   47.523877][ T1008] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   47.524627][ T1008] CR2: 0000561c82b69cf0 CR3: 0000000065dd6004 CR4: 00000000000606e0
      [   47.527662][ T1008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   47.528604][ T1008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   47.529531][ T1008] Call Trace:
      [   47.529874][ T1008]  ? nsim_dev_port_add+0x50/0x150 [netdevsim]
      [   47.530470][ T1008]  ? mutex_lock_io_nested+0x1380/0x1380
      [   47.531018][ T1008]  ? _kstrtoull+0x76/0x160
      [   47.531449][ T1008]  ? _parse_integer+0xf0/0xf0
      [   47.531874][ T1008]  ? kernfs_fop_write+0x1cf/0x410
      [   47.532330][ T1008]  ? sysfs_file_ops+0x160/0x160
      [   47.532773][ T1008]  ? kstrtouint+0x86/0x110
      [   47.533168][ T1008]  ? nsim_dev_port_add+0x50/0x150 [netdevsim]
      [   47.533721][ T1008]  nsim_dev_port_add+0x50/0x150 [netdevsim]
      [   47.534336][ T1008]  ? sysfs_file_ops+0x160/0x160
      [   47.534858][ T1008]  new_port_store+0x99/0xb0 [netdevsim]
      [   47.535439][ T1008]  ? del_port_store+0xb0/0xb0 [netdevsim]
      [   47.536035][ T1008]  ? sysfs_file_ops+0x112/0x160
      [   47.536544][ T1008]  ? sysfs_kf_write+0x3b/0x180
      [   47.537029][ T1008]  kernfs_fop_write+0x276/0x410
      [   47.537548][ T1008]  ? __sb_start_write+0x215/0x2e0
      [   47.538110][ T1008]  vfs_write+0x197/0x4a0
      [ ... ]
      
      Fixes: f9d9db47 ("netdevsim: add bus attributes to add new and delete devices")
      Fixes: 794b2c05 ("netdevsim: extend device attrs to support port addition and deletion")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      f5cd2160
    • M
      bnxt_en: Fix TC queue mapping. · 18e4960c
      Michael Chan 提交于
      The driver currently only calls netdev_set_tc_queue when the number of
      TCs is greater than 1.  Instead, the comparison should be greater than
      or equal to 1.  Even with 1 TC, we need to set the queue mapping.
      
      This bug can cause warnings when the number of TCs is changed back to 1.
      
      Fixes: 7809592d ("bnxt_en: Enable MSIX early in bnxt_init_one().")
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      18e4960c
    • V
      bnxt_en: Fix logic that disables Bus Master during firmware reset. · d4073028
      Vasundhara Volam 提交于
      The current logic that calls pci_disable_device() in __bnxt_close_nic()
      during firmware reset is flawed.  If firmware is still alive, we're
      disabling the device too early, causing some firmware commands to
      not reach the firmware.
      
      Fix it by moving the logic to bnxt_reset_close().  If firmware is
      in fatal condition, we call pci_disable_device() before we free
      any of the rings to prevent DMA corruption of the freed rings.  If
      firmware is still alive, we call pci_disable_device() after the
      last firmware message has been sent.
      
      Fixes: 3bc7d4a3 ("bnxt_en: Add BNXT_STATE_IN_FW_RESET state.")
      Signed-off-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      d4073028
    • M
      bnxt_en: Fix RDMA driver failure with SRIOV after firmware reset. · 12de2ead
      Michael Chan 提交于
      bnxt_ulp_start() needs to be called before SRIOV is re-enabled after
      firmware reset.  Re-enabling SRIOV may consume all the resources and
      may cause the RDMA driver to fail to get MSIX and other resources.
      Fix it by calling bnxt_ulp_start() first before calling
      bnxt_reenable_sriov().
      
      We re-arrange the logic so that we call bnxt_ulp_start() and
      bnxt_reenable_sriov() in proper sequence in bnxt_fw_reset_task() and
      bnxt_open().  The former is the normal coordinated firmware reset sequence
      and the latter is firmware reset while the function is down.  This new
      logic is now more straight forward and will now fix both scenarios.
      
      Fixes: f3a6d206 ("bnxt_en: Call bnxt_ulp_stop()/bnxt_ulp_start() during error recovery.")
      Reported-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      12de2ead
    • M
      bnxt_en: Refactor logic to re-enable SRIOV after firmware reset detected. · c16d4ee0
      Michael Chan 提交于
      Put the current logic in bnxt_open() to re-enable SRIOV after detecting
      firmware reset into a new function bnxt_reenable_sriov().  This call
      needs to be invoked in the firmware reset path also in the next patch.
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      c16d4ee0
    • N
      net: stmmac: Delete txtimer in suspend() · 14b41a29
      Nicolin Chen 提交于
      When running v5.5 with a rootfs on NFS, memory abort may happen in
      the system resume stage:
       Unable to handle kernel paging request at virtual address dead00000000012a
       [dead00000000012a] address between user and kernel address ranges
       pc : run_timer_softirq+0x334/0x3d8
       lr : run_timer_softirq+0x244/0x3d8
       x1 : ffff800011cafe80 x0 : dead000000000122
       Call trace:
        run_timer_softirq+0x334/0x3d8
        efi_header_end+0x114/0x234
        irq_exit+0xd0/0xd8
        __handle_domain_irq+0x60/0xb0
        gic_handle_irq+0x58/0xa8
        el1_irq+0xb8/0x180
        arch_cpu_idle+0x10/0x18
        do_idle+0x1d8/0x2b0
        cpu_startup_entry+0x24/0x40
        secondary_start_kernel+0x1b4/0x208
       Code: f9000693 a9400660 f9000020 b4000040 (f9000401)
       ---[ end trace bb83ceeb4c482071 ]---
       Kernel panic - not syncing: Fatal exception in interrupt
       SMP: stopping secondary CPUs
       SMP: failed to stop secondary CPUs 2-3
       Kernel Offset: disabled
       CPU features: 0x00002,2300aa30
       Memory Limit: none
       ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
      
      It's found that stmmac_xmit() and stmmac_resume() sometimes might
      run concurrently, possibly resulting in a race condition between
      mod_timer() and setup_timer(), being called by stmmac_xmit() and
      stmmac_resume() respectively.
      
      Since the resume() runs setup_timer() every time, it'd be safer to
      have del_timer_sync() in the suspend() as the counterpart.
      Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      14b41a29
  3. 02 2月, 2020 2 次提交
  4. 01 2月, 2020 5 次提交
  5. 31 1月, 2020 2 次提交
  6. 29 1月, 2020 1 次提交
  7. 28 1月, 2020 1 次提交
  8. 27 1月, 2020 6 次提交