1. 19 8月, 2017 7 次提交
    • E
      tipc: fix use-after-free · 5bfd37b4
      Eric Dumazet 提交于
      syszkaller reported use-after-free in tipc [1]
      
      When msg->rep skb is freed, set the pointer to NULL,
      so that caller does not free it again.
      
      [1]
      
      ==================================================================
      BUG: KASAN: use-after-free in skb_push+0xd4/0xe0 net/core/skbuff.c:1466
      Read of size 8 at addr ffff8801c6e71e90 by task syz-executor5/4115
      
      CPU: 1 PID: 4115 Comm: syz-executor5 Not tainted 4.13.0-rc4+ #32
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:16 [inline]
       dump_stack+0x194/0x257 lib/dump_stack.c:52
       print_address_description+0x73/0x250 mm/kasan/report.c:252
       kasan_report_error mm/kasan/report.c:351 [inline]
       kasan_report+0x24e/0x340 mm/kasan/report.c:409
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
       skb_push+0xd4/0xe0 net/core/skbuff.c:1466
       tipc_nl_compat_recv+0x833/0x18f0 net/tipc/netlink_compat.c:1209
       genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:598
       genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:623
       netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2397
       genl_rcv+0x28/0x40 net/netlink/genetlink.c:634
       netlink_unicast_kernel net/netlink/af_netlink.c:1265 [inline]
       netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1291
       netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1854
       sock_sendmsg_nosec net/socket.c:633 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:643
       sock_write_iter+0x31a/0x5d0 net/socket.c:898
       call_write_iter include/linux/fs.h:1743 [inline]
       new_sync_write fs/read_write.c:457 [inline]
       __vfs_write+0x684/0x970 fs/read_write.c:470
       vfs_write+0x189/0x510 fs/read_write.c:518
       SYSC_write fs/read_write.c:565 [inline]
       SyS_write+0xef/0x220 fs/read_write.c:557
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      RIP: 0033:0x4512e9
      RSP: 002b:00007f3bc8184c08 EFLAGS: 00000216 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 00000000004512e9
      RDX: 0000000000000020 RSI: 0000000020fdb000 RDI: 0000000000000006
      RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000216 R12: 00000000004b5e76
      R13: 00007f3bc8184b48 R14: 00000000004b5e86 R15: 0000000000000000
      
      Allocated by task 4115:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
       kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
       kmem_cache_alloc_node+0x13d/0x750 mm/slab.c:3651
       __alloc_skb+0xf1/0x740 net/core/skbuff.c:219
       alloc_skb include/linux/skbuff.h:903 [inline]
       tipc_tlv_alloc+0x26/0xb0 net/tipc/netlink_compat.c:148
       tipc_nl_compat_dumpit+0xf2/0x3c0 net/tipc/netlink_compat.c:248
       tipc_nl_compat_handle net/tipc/netlink_compat.c:1130 [inline]
       tipc_nl_compat_recv+0x756/0x18f0 net/tipc/netlink_compat.c:1199
       genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:598
       genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:623
       netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2397
       genl_rcv+0x28/0x40 net/netlink/genetlink.c:634
       netlink_unicast_kernel net/netlink/af_netlink.c:1265 [inline]
       netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1291
       netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1854
       sock_sendmsg_nosec net/socket.c:633 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:643
       sock_write_iter+0x31a/0x5d0 net/socket.c:898
       call_write_iter include/linux/fs.h:1743 [inline]
       new_sync_write fs/read_write.c:457 [inline]
       __vfs_write+0x684/0x970 fs/read_write.c:470
       vfs_write+0x189/0x510 fs/read_write.c:518
       SYSC_write fs/read_write.c:565 [inline]
       SyS_write+0xef/0x220 fs/read_write.c:557
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      
      Freed by task 4115:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
       __cache_free mm/slab.c:3503 [inline]
       kmem_cache_free+0x77/0x280 mm/slab.c:3763
       kfree_skbmem+0x1a1/0x1d0 net/core/skbuff.c:622
       __kfree_skb net/core/skbuff.c:682 [inline]
       kfree_skb+0x165/0x4c0 net/core/skbuff.c:699
       tipc_nl_compat_dumpit+0x36a/0x3c0 net/tipc/netlink_compat.c:260
       tipc_nl_compat_handle net/tipc/netlink_compat.c:1130 [inline]
       tipc_nl_compat_recv+0x756/0x18f0 net/tipc/netlink_compat.c:1199
       genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:598
       genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:623
       netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2397
       genl_rcv+0x28/0x40 net/netlink/genetlink.c:634
       netlink_unicast_kernel net/netlink/af_netlink.c:1265 [inline]
       netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1291
       netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1854
       sock_sendmsg_nosec net/socket.c:633 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:643
       sock_write_iter+0x31a/0x5d0 net/socket.c:898
       call_write_iter include/linux/fs.h:1743 [inline]
       new_sync_write fs/read_write.c:457 [inline]
       __vfs_write+0x684/0x970 fs/read_write.c:470
       vfs_write+0x189/0x510 fs/read_write.c:518
       SYSC_write fs/read_write.c:565 [inline]
       SyS_write+0xef/0x220 fs/read_write.c:557
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      
      The buggy address belongs to the object at ffff8801c6e71dc0
       which belongs to the cache skbuff_head_cache of size 224
      The buggy address is located 208 bytes inside of
       224-byte region [ffff8801c6e71dc0, ffff8801c6e71ea0)
      The buggy address belongs to the page:
      page:ffffea00071b9c40 count:1 mapcount:0 mapping:ffff8801c6e71000 index:0x0
      flags: 0x200000000000100(slab)
      raw: 0200000000000100 ffff8801c6e71000 0000000000000000 000000010000000c
      raw: ffffea0007224a20 ffff8801d98caf48 ffff8801d9e79040 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8801c6e71d80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
       ffff8801c6e71e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff8801c6e71e80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
                               ^
       ffff8801c6e71f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff8801c6e71f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      ==================================================================
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NDmitry Vyukov  <dvyukov@google.com>
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      Cc: Ying Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5bfd37b4
    • E
      tun: handle register_netdevice() failures properly · ff244c6b
      Eric Dumazet 提交于
      syzkaller reported a double free [1], caused by the fact
      that tun driver was not updated properly when priv_destructor
      was added.
      
      When/if register_netdevice() fails, priv_destructor() must have been
      called already.
      
      [1]
      BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x15/0x20 security/selinux/hooks.c:5023
      
      CPU: 0 PID: 2919 Comm: syzkaller227220 Not tainted 4.13.0-rc4+ #23
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:16 [inline]
       dump_stack+0x194/0x257 lib/dump_stack.c:52
       print_address_description+0x7f/0x260 mm/kasan/report.c:252
       kasan_report_double_free+0x55/0x80 mm/kasan/report.c:333
       kasan_slab_free+0xa0/0xc0 mm/kasan/kasan.c:514
       __cache_free mm/slab.c:3503 [inline]
       kfree+0xd3/0x260 mm/slab.c:3820
       selinux_tun_dev_free_security+0x15/0x20 security/selinux/hooks.c:5023
       security_tun_dev_free_security+0x48/0x80 security/security.c:1512
       tun_set_iff drivers/net/tun.c:1884 [inline]
       __tun_chr_ioctl+0x2ce6/0x3d50 drivers/net/tun.c:2064
       tun_chr_ioctl+0x2a/0x40 drivers/net/tun.c:2309
       vfs_ioctl fs/ioctl.c:45 [inline]
       do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:685
       SYSC_ioctl fs/ioctl.c:700 [inline]
       SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      RIP: 0033:0x443ff9
      RSP: 002b:00007ffc34271f68 EFLAGS: 00000217 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00000000004002e0 RCX: 0000000000443ff9
      RDX: 0000000020533000 RSI: 00000000400454ca RDI: 0000000000000003
      RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000217 R12: 0000000000401ce0
      R13: 0000000000401d70 R14: 0000000000000000 R15: 0000000000000000
      
      Allocated by task 2919:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       kasan_kmalloc+0xaa/0xd0 mm/kasan/kasan.c:551
       kmem_cache_alloc_trace+0x101/0x6f0 mm/slab.c:3627
       kmalloc include/linux/slab.h:493 [inline]
       kzalloc include/linux/slab.h:666 [inline]
       selinux_tun_dev_alloc_security+0x49/0x170 security/selinux/hooks.c:5012
       security_tun_dev_alloc_security+0x6d/0xa0 security/security.c:1506
       tun_set_iff drivers/net/tun.c:1839 [inline]
       __tun_chr_ioctl+0x1730/0x3d50 drivers/net/tun.c:2064
       tun_chr_ioctl+0x2a/0x40 drivers/net/tun.c:2309
       vfs_ioctl fs/ioctl.c:45 [inline]
       do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:685
       SYSC_ioctl fs/ioctl.c:700 [inline]
       SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      
      Freed by task 2919:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       kasan_slab_free+0x6e/0xc0 mm/kasan/kasan.c:524
       __cache_free mm/slab.c:3503 [inline]
       kfree+0xd3/0x260 mm/slab.c:3820
       selinux_tun_dev_free_security+0x15/0x20 security/selinux/hooks.c:5023
       security_tun_dev_free_security+0x48/0x80 security/security.c:1512
       tun_free_netdev+0x13b/0x1b0 drivers/net/tun.c:1563
       register_netdevice+0x8d0/0xee0 net/core/dev.c:7605
       tun_set_iff drivers/net/tun.c:1859 [inline]
       __tun_chr_ioctl+0x1caf/0x3d50 drivers/net/tun.c:2064
       tun_chr_ioctl+0x2a/0x40 drivers/net/tun.c:2309
       vfs_ioctl fs/ioctl.c:45 [inline]
       do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:685
       SYSC_ioctl fs/ioctl.c:700 [inline]
       SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      
      The buggy address belongs to the object at ffff8801d2843b40
       which belongs to the cache kmalloc-32 of size 32
      The buggy address is located 0 bytes inside of
       32-byte region [ffff8801d2843b40, ffff8801d2843b60)
      The buggy address belongs to the page:
      page:ffffea000660cea8 count:1 mapcount:0 mapping:ffff8801d2843000 index:0xffff8801d2843fc1
      flags: 0x200000000000100(slab)
      raw: 0200000000000100 ffff8801d2843000 ffff8801d2843fc1 000000010000003f
      raw: ffffea0006626a40 ffffea00066141a0 ffff8801dbc00100
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8801d2843a00: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
       ffff8801d2843a80: 00 00 00 fc fc fc fc fc fb fb fb fb fc fc fc fc
      >ffff8801d2843b00: 00 00 00 00 fc fc fc fc fb fb fb fb fc fc fc fc
                                                 ^
       ffff8801d2843b80: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
       ffff8801d2843c00: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
      
      ==================================================================
      
      Fixes: cf124db5 ("net: Fix inconsistent teardown and release of private netdev state.")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff244c6b
    • M
      datagram: When peeking datagrams with offset < 0 don't skip empty skbs · a0917e0b
      Matthew Dawson 提交于
      Due to commit e6afc8ac ("udp: remove
      headers from UDP packets before queueing"), when udp packets are being
      peeked the requested extra offset is always 0 as there is no need to skip
      the udp header.  However, when the offset is 0 and the next skb is
      of length 0, it is only returned once.  The behaviour can be seen with
      the following python script:
      
      from socket import *;
      f=socket(AF_INET6, SOCK_DGRAM | SOCK_NONBLOCK, 0);
      g=socket(AF_INET6, SOCK_DGRAM | SOCK_NONBLOCK, 0);
      f.bind(('::', 0));
      addr=('::1', f.getsockname()[1]);
      g.sendto(b'', addr)
      g.sendto(b'b', addr)
      print(f.recvfrom(10, MSG_PEEK));
      print(f.recvfrom(10, MSG_PEEK));
      
      Where the expected output should be the empty string twice.
      
      Instead, make sk_peek_offset return negative values, and pass those values
      to __skb_try_recv_datagram/__skb_try_recv_from_queue.  If the passed offset
      to __skb_try_recv_from_queue is negative, the checked skb is never skipped.
      __skb_try_recv_from_queue will then ensure the offset is reset back to 0
      if a peek is requested without an offset, unless no packets are found.
      
      Also simplify the if condition in __skb_try_recv_from_queue.  If _off is
      greater then 0, and off is greater then or equal to skb->len, then
      (_off || skb->len) must always be true assuming skb->len >= 0 is always
      true.
      
      Also remove a redundant check around a call to sk_peek_offset in af_unix.c,
      as it double checked if MSG_PEEK was set in the flags.
      
      V2:
       - Moved the negative fixup into __skb_try_recv_from_queue, and remove now
      redundant checks
       - Fix peeking in udp{,v6}_recvmsg to report the right value when the
      offset is 0
      
      V3:
       - Marked new branch in __skb_try_recv_from_queue as unlikely.
      Signed-off-by: NMatthew Dawson <matthew@mjdsystems.ca>
      Acked-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0917e0b
    • D
      bpf, doc: improve sysctl knob description · 2110ba58
      Daniel Borkmann 提交于
      Current context speaking of tcpdump filters is out of date these
      days, so lets improve the sysctl description for the BPF knobs
      a bit.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2110ba58
    • C
      netxen: fix incorrect loop counter decrement · a120d9ab
      Colin Ian King 提交于
      The loop counter k is currently being decremented from zero which
      is incorrect. Fix this by incrementing k instead
      
      Detected by CoverityScan, CID#401847 ("Infinite loop")
      
      Fixes: 83f18a55 ("netxen_nic: fw dump support")
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a120d9ab
    • C
      nfp: fix infinite loop on umapping cleanup · eac2c68d
      Colin Ian King 提交于
      The while loop that performs the dma page unmapping never decrements
      index counter f and hence loops forever. Fix this with a pre-decrement
      on f.
      
      Detected by CoverityScan, CID#1357309 ("Infinite loop")
      
      Fixes: 4c352362 ("net: add driver for Netronome NFP4000/NFP6000 NIC VFs")
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Acked-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eac2c68d
    • J
      net: sched: fix p_filter_chain check in tcf_chain_flush · acc8b316
      Jiri Pirko 提交于
      The dereference before check is wrong and leads to an oops when
      p_filter_chain is NULL. The check needs to be done on the pointer to
      prevent NULL dereference.
      
      Fixes: f93e1cdc ("net/sched: fix filter flushing")
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Acked-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      acc8b316
  2. 18 8月, 2017 1 次提交
  3. 17 8月, 2017 5 次提交
    • E
      ipv4: better IP_MAX_MTU enforcement · c780a049
      Eric Dumazet 提交于
      While working on yet another syzkaller report, I found
      that our IP_MAX_MTU enforcements were not properly done.
      
      gcc seems to reload dev->mtu for min(dev->mtu, IP_MAX_MTU), and
      final result can be bigger than IP_MAX_MTU :/
      
      This is a problem because device mtu can be changed on other cpus or
      threads.
      
      While this patch does not fix the issue I am working on, it is
      probably worth addressing it.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c780a049
    • E
      ptr_ring: use kmalloc_array() · 81fbfe8a
      Eric Dumazet 提交于
      As found by syzkaller, malicious users can set whatever tx_queue_len
      on a tun device and eventually crash the kernel.
      
      Lets remove the ALIGN(XXX, SMP_CACHE_BYTES) thing since a small
      ring buffer is not fast anyway.
      
      Fixes: 2e0ab8ca ("ptr_ring: array based FIFO for pointers")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      81fbfe8a
    • E
      dccp: defer ccid_hc_tx_delete() at dismantle time · 120e9dab
      Eric Dumazet 提交于
      syszkaller team reported another problem in DCCP [1]
      
      Problem here is that the structure holding RTO timer
      (ccid2_hc_tx_rto_expire() handler) is freed too soon.
      
      We can not use del_timer_sync() to cancel the timer
      since this timer wants to grab socket lock (that would risk a dead lock)
      
      Solution is to defer the freeing of memory when all references to
      the socket were released. Socket timers do own a reference, so this
      should fix the issue.
      
      [1]
      
      ==================================================================
      BUG: KASAN: use-after-free in ccid2_hc_tx_rto_expire+0x51c/0x5c0 net/dccp/ccids/ccid2.c:144
      Read of size 4 at addr ffff8801d2660540 by task kworker/u4:7/3365
      
      CPU: 1 PID: 3365 Comm: kworker/u4:7 Not tainted 4.13.0-rc4+ #3
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: events_unbound call_usermodehelper_exec_work
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:16 [inline]
       dump_stack+0x194/0x257 lib/dump_stack.c:52
       print_address_description+0x73/0x250 mm/kasan/report.c:252
       kasan_report_error mm/kasan/report.c:351 [inline]
       kasan_report+0x24e/0x340 mm/kasan/report.c:409
       __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
       ccid2_hc_tx_rto_expire+0x51c/0x5c0 net/dccp/ccids/ccid2.c:144
       call_timer_fn+0x233/0x830 kernel/time/timer.c:1268
       expire_timers kernel/time/timer.c:1307 [inline]
       __run_timers+0x7fd/0xb90 kernel/time/timer.c:1601
       run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
       __do_softirq+0x2f5/0xba3 kernel/softirq.c:284
       invoke_softirq kernel/softirq.c:364 [inline]
       irq_exit+0x1cc/0x200 kernel/softirq.c:405
       exiting_irq arch/x86/include/asm/apic.h:638 [inline]
       smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:1044
       apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:702
      RIP: 0010:arch_local_irq_enable arch/x86/include/asm/paravirt.h:824 [inline]
      RIP: 0010:__raw_write_unlock_irq include/linux/rwlock_api_smp.h:267 [inline]
      RIP: 0010:_raw_write_unlock_irq+0x56/0x70 kernel/locking/spinlock.c:343
      RSP: 0018:ffff8801cd50eaa8 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff10
      RAX: dffffc0000000000 RBX: ffffffff85a090c0 RCX: 0000000000000006
      RDX: 1ffffffff0b595f3 RSI: 1ffff1003962f989 RDI: ffffffff85acaf98
      RBP: ffff8801cd50eab0 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801cc96ea60
      R13: dffffc0000000000 R14: ffff8801cc96e4c0 R15: ffff8801cc96e4c0
       </IRQ>
       release_task+0xe9e/0x1a40 kernel/exit.c:220
       wait_task_zombie kernel/exit.c:1162 [inline]
       wait_consider_task+0x29b8/0x33c0 kernel/exit.c:1389
       do_wait_thread kernel/exit.c:1452 [inline]
       do_wait+0x441/0xa90 kernel/exit.c:1523
       kernel_wait4+0x1f5/0x370 kernel/exit.c:1665
       SYSC_wait4+0x134/0x140 kernel/exit.c:1677
       SyS_wait4+0x2c/0x40 kernel/exit.c:1673
       call_usermodehelper_exec_sync kernel/kmod.c:286 [inline]
       call_usermodehelper_exec_work+0x1a0/0x2c0 kernel/kmod.c:323
       process_one_work+0xbf3/0x1bc0 kernel/workqueue.c:2097
       worker_thread+0x223/0x1860 kernel/workqueue.c:2231
       kthread+0x35e/0x430 kernel/kthread.c:231
       ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:425
      
      Allocated by task 21267:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
       kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
       kmem_cache_alloc+0x127/0x750 mm/slab.c:3561
       ccid_new+0x20e/0x390 net/dccp/ccid.c:151
       dccp_hdlr_ccid+0x27/0x140 net/dccp/feat.c:44
       __dccp_feat_activate+0x142/0x2a0 net/dccp/feat.c:344
       dccp_feat_activate_values+0x34e/0xa90 net/dccp/feat.c:1538
       dccp_rcv_request_sent_state_process net/dccp/input.c:472 [inline]
       dccp_rcv_state_process+0xed1/0x1620 net/dccp/input.c:677
       dccp_v4_do_rcv+0xeb/0x160 net/dccp/ipv4.c:679
       sk_backlog_rcv include/net/sock.h:911 [inline]
       __release_sock+0x124/0x360 net/core/sock.c:2269
       release_sock+0xa4/0x2a0 net/core/sock.c:2784
       inet_wait_for_connect net/ipv4/af_inet.c:557 [inline]
       __inet_stream_connect+0x671/0xf00 net/ipv4/af_inet.c:643
       inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:682
       SYSC_connect+0x204/0x470 net/socket.c:1642
       SyS_connect+0x24/0x30 net/socket.c:1623
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      
      Freed by task 3049:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
       __cache_free mm/slab.c:3503 [inline]
       kmem_cache_free+0x77/0x280 mm/slab.c:3763
       ccid_hc_tx_delete+0xc5/0x100 net/dccp/ccid.c:190
       dccp_destroy_sock+0x1d1/0x2b0 net/dccp/proto.c:225
       inet_csk_destroy_sock+0x166/0x3f0 net/ipv4/inet_connection_sock.c:833
       dccp_done+0xb7/0xd0 net/dccp/proto.c:145
       dccp_time_wait+0x13d/0x300 net/dccp/minisocks.c:72
       dccp_rcv_reset+0x1d1/0x5b0 net/dccp/input.c:160
       dccp_rcv_state_process+0x8fc/0x1620 net/dccp/input.c:663
       dccp_v4_do_rcv+0xeb/0x160 net/dccp/ipv4.c:679
       sk_backlog_rcv include/net/sock.h:911 [inline]
       __sk_receive_skb+0x33e/0xc00 net/core/sock.c:521
       dccp_v4_rcv+0xef1/0x1c00 net/dccp/ipv4.c:871
       ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216
       NF_HOOK include/linux/netfilter.h:248 [inline]
       ip_local_deliver+0x1ce/0x6d0 net/ipv4/ip_input.c:257
       dst_input include/net/dst.h:477 [inline]
       ip_rcv_finish+0x8db/0x19c0 net/ipv4/ip_input.c:397
       NF_HOOK include/linux/netfilter.h:248 [inline]
       ip_rcv+0xc3f/0x17d0 net/ipv4/ip_input.c:488
       __netif_receive_skb_core+0x19af/0x33d0 net/core/dev.c:4417
       __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4455
       process_backlog+0x203/0x740 net/core/dev.c:5130
       napi_poll net/core/dev.c:5527 [inline]
       net_rx_action+0x792/0x1910 net/core/dev.c:5593
       __do_softirq+0x2f5/0xba3 kernel/softirq.c:284
      
      The buggy address belongs to the object at ffff8801d2660100
       which belongs to the cache ccid2_hc_tx_sock of size 1240
      The buggy address is located 1088 bytes inside of
       1240-byte region [ffff8801d2660100, ffff8801d26605d8)
      The buggy address belongs to the page:
      page:ffffea0007499800 count:1 mapcount:0 mapping:ffff8801d2660100 index:0x0 compound_mapcount: 0
      flags: 0x200000000008100(slab|head)
      raw: 0200000000008100 ffff8801d2660100 0000000000000000 0000000100000005
      raw: ffffea00075271a0 ffffea0007538820 ffff8801d3aef9c0 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8801d2660400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8801d2660480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff8801d2660500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                 ^
       ffff8801d2660580: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
       ffff8801d2660600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      ==================================================================
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      120e9dab
    • L
      openvswitch: fix skb_panic due to the incorrect actions attrlen · 494bea39
      Liping Zhang 提交于
      For sw_flow_actions, the actions_len only represents the kernel part's
      size, and when we dump the actions to the userspace, we will do the
      convertions, so it's true size may become bigger than the actions_len.
      
      But unfortunately, for OVS_PACKET_ATTR_ACTIONS, we use the actions_len
      to alloc the skbuff, so the user_skb's size may become insufficient and
      oops will happen like this:
        skbuff: skb_over_panic: text:ffffffff8148fabf len:1749 put:157 head:
        ffff881300f39000 data:ffff881300f39000 tail:0x6d5 end:0x6c0 dev:<NULL>
        ------------[ cut here ]------------
        kernel BUG at net/core/skbuff.c:129!
        [...]
        Call Trace:
         <IRQ>
         [<ffffffff8148be82>] skb_put+0x43/0x44
         [<ffffffff8148fabf>] skb_zerocopy+0x6c/0x1f4
         [<ffffffffa0290d36>] queue_userspace_packet+0x3a3/0x448 [openvswitch]
         [<ffffffffa0292023>] ovs_dp_upcall+0x30/0x5c [openvswitch]
         [<ffffffffa028d435>] output_userspace+0x132/0x158 [openvswitch]
         [<ffffffffa01e6890>] ? ip6_rcv_finish+0x74/0x77 [ipv6]
         [<ffffffffa028e277>] do_execute_actions+0xcc1/0xdc8 [openvswitch]
         [<ffffffffa028e3f2>] ovs_execute_actions+0x74/0x106 [openvswitch]
         [<ffffffffa0292130>] ovs_dp_process_packet+0xe1/0xfd [openvswitch]
         [<ffffffffa0292b77>] ? key_extract+0x63c/0x8d5 [openvswitch]
         [<ffffffffa029848b>] ovs_vport_receive+0xa1/0xc3 [openvswitch]
        [...]
      
      Also we can find that the actions_len is much little than the orig_len:
        crash> struct sw_flow_actions 0xffff8812f539d000
        struct sw_flow_actions {
          rcu = {
            next = 0xffff8812f5398800,
            func = 0xffffe3b00035db32
          },
          orig_len = 1384,
          actions_len = 592,
          actions = 0xffff8812f539d01c
        }
      
      So as a quick fix, use the orig_len instead of the actions_len to alloc
      the user_skb.
      
      Last, this oops happened on our system running a relative old kernel, but
      the same risk still exists on the mainline, since we use the wrong
      actions_len from the beginning.
      
      Fixes: ccea7445 ("openvswitch: include datapath actions with sampled-packet upcall to userspace")
      Cc: Neil McKee <neil.mckee@inmon.com>
      Signed-off-by: NLiping Zhang <zlpnobody@gmail.com>
      Acked-by: NPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      494bea39
    • D
      net: igmp: Use ingress interface rather than vrf device · c7b725be
      David Ahern 提交于
      Anuradha reported that statically added groups for interfaces enslaved
      to a VRF device were not persisting. The problem is that igmp queries
      and reports need to use the data in the in_dev for the real ingress
      device rather than the VRF device. Update igmp_rcv accordingly.
      
      Fixes: e58e4159 ("net: Enable support for VRF with ipv4 multicast")
      Reported-by: NAnuradha Karuppiah <anuradhak@cumulusnetworks.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Reviewed-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7b725be
  4. 16 8月, 2017 12 次提交
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 510c8a89
      Linus Torvalds 提交于
      Pull networking fixes from David Miller:
      
       1) Fix TCP checksum offload handling in iwlwifi driver, from Emmanuel
          Grumbach.
      
       2) In ksz DSA tagging code, free SKB if skb_put_padto() fails. From
          Vivien Didelot.
      
       3) Fix two regressions with bonding on wireless, from Andreas Born.
      
       4) Fix build when busypoll is disabled, from Daniel Borkmann.
      
       5) Fix copy_linear_skb() wrt. SO_PEEK_OFF, from Eric Dumazet.
      
       6) Set SKB cached route properly in inet_rtm_getroute(), from Florian
          Westphal.
      
       7) Fix PCI-E relaxed ordering handling in cxgb4 driver, from Ding
          Tianhong.
      
       8) Fix module refcnt leak in ULP code, from Sabrina Dubroca.
      
       9) Fix use of GFP_KERNEL in atomic contexts in AF_KEY code, from Eric
          Dumazet.
      
      10) Need to purge socket write queue in dccp_destroy_sock(), also from
          Eric Dumazet.
      
      11) Make bpf_trace_printk() work properly on 32-bit architectures, from
          Daniel Borkmann.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (47 commits)
        bpf: fix bpf_trace_printk on 32 bit archs
        PCI: fix oops when try to find Root Port for a PCI device
        sfc: don't try and read ef10 data on non-ef10 NIC
        net_sched: remove warning from qdisc_hash_add
        net_sched/sfq: update hierarchical backlog when drop packet
        net_sched: reset pointers to tcf blocks in classful qdiscs' destructors
        ipv4: fix NULL dereference in free_fib_info_rcu()
        net: Fix a typo in comment about sock flags.
        ipv6: fix NULL dereference in ip6_route_dev_notify()
        tcp: fix possible deadlock in TCP stack vs BPF filter
        dccp: purge write queue in dccp_destroy_sock()
        udp: fix linear skb reception with PEEK_OFF
        ipv6: release rt6->rt6i_idev properly during ifdown
        af_key: do not use GFP_KERNEL in atomic contexts
        tcp: ulp: avoid module refcnt leak in tcp_set_ulp
        net/cxgb4vf: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
        net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
        PCI: Disable Relaxed Ordering Attributes for AMD A1100
        PCI: Disable Relaxed Ordering for some Intel processors
        PCI: Disable PCIe Relaxed Ordering if unsupported
        ...
      510c8a89
    • D
      bpf: fix bpf_trace_printk on 32 bit archs · 88a5c690
      Daniel Borkmann 提交于
      James reported that on MIPS32 bpf_trace_printk() is currently
      broken while MIPS64 works fine:
      
        bpf_trace_printk() uses conditional operators to attempt to
        pass different types to __trace_printk() depending on the
        format operators. This doesn't work as intended on 32-bit
        architectures where u32 and long are passed differently to
        u64, since the result of C conditional operators follows the
        "usual arithmetic conversions" rules, such that the values
        passed to __trace_printk() will always be u64 [causing issues
        later in the va_list handling for vscnprintf()].
      
        For example the samples/bpf/tracex5 test printed lines like
        below on MIPS32, where the fd and buf have come from the u64
        fd argument, and the size from the buf argument:
      
          [...] 1180.941542: 0x00000001: write(fd=1, buf=  (null), size=6258688)
      
        Instead of this:
      
          [...] 1625.616026: 0x00000001: write(fd=1, buf=009e4000, size=512)
      
      One way to get it working is to expand various combinations
      of argument types into 8 different combinations for 32 bit
      and 64 bit kernels. Fix tested by James on MIPS32 and MIPS64
      as well that it resolves the issue.
      
      Fixes: 9c959c86 ("tracing: Allow BPF programs to call bpf_trace_printk()")
      Reported-by: NJames Hogan <james.hogan@imgtec.com>
      Tested-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88a5c690
    • D
      PCI: fix oops when try to find Root Port for a PCI device · 0e405232
      dingtianhong 提交于
      Eric report a oops when booting the system after applying
      the commit a99b646a ("PCI: Disable PCIe Relaxed..."):
      
      [    4.241029] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
      [    4.247001] IP: pci_find_pcie_root_port+0x62/0x80
      [    4.253011] PGD 0
      [    4.253011] P4D 0
      [    4.253011]
      [    4.258013] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      [    4.262015] Modules linked in:
      [    4.265005] CPU: 31 PID: 1 Comm: swapper/0 Not tainted 4.13.0-dbx-DEV #316
      [    4.271002] Hardware name: Intel RML,PCH/Iota_QC_19, BIOS 2.40.0 06/22/2016
      [    4.279002] task: ffffa2ee38cfa040 task.stack: ffffa51ec0004000
      [    4.285001] RIP: 0010:pci_find_pcie_root_port+0x62/0x80
      [    4.290012] RSP: 0000:ffffa51ec0007ab8 EFLAGS: 00010246
      [    4.295003] RAX: 0000000000000000 RBX: ffffa2ee36bae000 RCX: 0000000000000006
      [    4.303002] RDX: 000000000000081c RSI: ffffa2ee38cfa8c8 RDI: ffffa2ee36bae000
      [    4.310013] RBP: ffffa51ec0007b58 R08: 0000000000000001 R09: 0000000000000000
      [    4.317001] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa51ec0007ad0
      [    4.324005] R13: ffffa2ee36bae098 R14: 0000000000000002 R15: ffffa2ee37204818
      [    4.331002] FS:  0000000000000000(0000) GS:ffffa2ee3fcc0000(0000) knlGS:0000000000000000
      [    4.339002] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    4.345001] CR2: 0000000000000050 CR3: 000000401000f000 CR4: 00000000001406e0
      [    4.351002] Call Trace:
      [    4.354012]  ? pci_configure_device+0x19f/0x570
      [    4.359002]  ? pci_conf1_read+0xb8/0xf0
      [    4.363002]  ? raw_pci_read+0x23/0x40
      [    4.366011]  ? pci_read+0x2c/0x30
      [    4.370014]  ? pci_read_config_word+0x67/0x70
      [    4.374012]  pci_device_add+0x28/0x230
      [    4.378012]  ? pci_vpd_f0_read+0x50/0x80
      [    4.382014]  pci_scan_single_device+0x96/0xc0
      [    4.386012]  pci_scan_slot+0x79/0xf0
      [    4.389001]  pci_scan_child_bus+0x31/0x180
      [    4.394014]  acpi_pci_root_create+0x1c6/0x240
      [    4.398013]  pci_acpi_scan_root+0x15f/0x1b0
      [    4.402012]  acpi_pci_root_add+0x2e6/0x400
      [    4.406012]  ? acpi_evaluate_integer+0x37/0x60
      [    4.411002]  acpi_bus_attach+0xdf/0x200
      [    4.415002]  acpi_bus_attach+0x6a/0x200
      [    4.418014]  acpi_bus_attach+0x6a/0x200
      [    4.422013]  acpi_bus_scan+0x38/0x70
      [    4.426011]  acpi_scan_init+0x10c/0x271
      [    4.429001]  acpi_init+0x2fa/0x348
      [    4.433004]  ? acpi_sleep_proc_init+0x2d/0x2d
      [    4.437001]  do_one_initcall+0x43/0x169
      [    4.441001]  kernel_init_freeable+0x1d0/0x258
      [    4.445003]  ? rest_init+0xe0/0xe0
      [    4.449001]  kernel_init+0xe/0x150
      
      ====================== cut here =============================
      
      It looks like the pci_find_pcie_root_port() was trying to
      find the Root Port for the PCI device which is the Root
      Port already, it will return NULL and trigger the problem,
      so check the highest_pcie_bridge to fix thie problem.
      
      Fixes: a99b646a ("PCI: Disable PCIe Relaxed Ordering if unsupported")
      Fixes: c56d4450 ("PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum")
      Reported-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e405232
    • B
      sfc: don't try and read ef10 data on non-ef10 NIC · 61deee96
      Bert Kenward 提交于
      The MAC stats command takes a port ID, which doesn't exist on
      pre-ef10 NICs (5000- and 6000- series). This is extracted from the
      NIC specific data; we misinterpret this as the ef10 data structure,
      causing us to read potentially unallocated data. With a KASAN kernel
      this can cause errors with:
         BUG: KASAN: slab-out-of-bounds in efx_mcdi_mac_stats
      
      Fixes: 0a2ab4d9 ("sfc: set the port-id when calling MC_CMD_MAC_STATS")
      Reported-by: NStefano Brivio <sbrivio@redhat.com>
      Tested-by: NStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: NBert Kenward <bkenward@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      61deee96
    • K
      net_sched: remove warning from qdisc_hash_add · c90e9514
      Konstantin Khlebnikov 提交于
      It was added in commit e57a784d ("pkt_sched: set root qdisc
      before change() in attach_default_qdiscs()") to hide duplicates
      from "tc qdisc show" for incative deivices.
      
      After 59cc1f61 ("net: sched: convert qdisc linked list to hashtable")
      it triggered when classful qdisc is added to inactive device because
      default qdiscs are added before switching root qdisc.
      
      Anyway after commit ea327469 ("net: sched: avoid duplicates in
      qdisc dump") duplicates are filtered right in dumper.
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c90e9514
    • K
      net_sched/sfq: update hierarchical backlog when drop packet · 325d5dc3
      Konstantin Khlebnikov 提交于
      When sfq_enqueue() drops head packet or packet from another queue it
      have to update backlog at upper qdiscs too.
      
      Fixes: 2ccccf5f ("net_sched: update hierarchical backlog too")
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      325d5dc3
    • K
      net_sched: reset pointers to tcf blocks in classful qdiscs' destructors · 89890422
      Konstantin Khlebnikov 提交于
      Traffic filters could keep direct pointers to classes in classful qdisc,
      thus qdisc destruction first removes all filters before freeing classes.
      Class destruction methods also tries to free attached filters but now
      this isn't safe because tcf_block_put() unlike to tcf_destroy_chain()
      cannot be called second time.
      
      This patch set class->block to NULL after first tcf_block_put() and
      turn second call into no-op.
      
      Fixes: 6529eaba ("net: sched: introduce tcf block infractructure")
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      89890422
    • E
      ipv4: fix NULL dereference in free_fib_info_rcu() · 187e5b3a
      Eric Dumazet 提交于
      If fi->fib_metrics could not be allocated in fib_create_info()
      we attempt to dereference a NULL pointer in free_fib_info_rcu() :
      
          m = fi->fib_metrics;
          if (m != &dst_default_metrics && atomic_dec_and_test(&m->refcnt))
                  kfree(m);
      
      Before my recent patch, we used to call kfree(NULL) and nothing wrong
      happened.
      
      Instead of using RCU to defer freeing while we are under memory stress,
      it seems better to take immediate action.
      
      This was reported by syzkaller team.
      
      Fixes: 3fb07daf ("ipv4: add reference counting to metrics")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      187e5b3a
    • T
      b3dc8f77
    • E
      ipv6: fix NULL dereference in ip6_route_dev_notify() · 12d94a80
      Eric Dumazet 提交于
      Based on a syzkaller report [1], I found that a per cpu allocation
      failure in snmp6_alloc_dev() would then lead to NULL dereference in
      ip6_route_dev_notify().
      
      It seems this is a very old bug, thus no Fixes tag in this submission.
      
      Let's add in6_dev_put_clear() helper, as we will probably use
      it elsewhere (once available/present in net-next)
      
      [1]
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Modules linked in:
      CPU: 1 PID: 17294 Comm: syz-executor6 Not tainted 4.13.0-rc2+ #10
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      task: ffff88019f456680 task.stack: ffff8801c6e58000
      RIP: 0010:__read_once_size include/linux/compiler.h:250 [inline]
      RIP: 0010:atomic_read arch/x86/include/asm/atomic.h:26 [inline]
      RIP: 0010:refcount_sub_and_test+0x7d/0x1b0 lib/refcount.c:178
      RSP: 0018:ffff8801c6e5f1b0 EFLAGS: 00010202
      RAX: 0000000000000037 RBX: dffffc0000000000 RCX: ffffc90005d25000
      RDX: ffff8801c6e5f218 RSI: ffffffff82342bbf RDI: 0000000000000001
      RBP: ffff8801c6e5f240 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff10038dcbe37
      R13: 0000000000000006 R14: 0000000000000001 R15: 00000000000001b8
      FS:  00007f21e0429700(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001ddbc22000 CR3: 00000001d632b000 CR4: 00000000001426e0
      DR0: 0000000020000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
      Call Trace:
       refcount_dec_and_test+0x1a/0x20 lib/refcount.c:211
       in6_dev_put include/net/addrconf.h:335 [inline]
       ip6_route_dev_notify+0x1c9/0x4a0 net/ipv6/route.c:3732
       notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1678
       call_netdevice_notifiers net/core/dev.c:1694 [inline]
       rollback_registered_many+0x91c/0xe80 net/core/dev.c:7107
       rollback_registered+0x1be/0x3c0 net/core/dev.c:7149
       register_netdevice+0xbcd/0xee0 net/core/dev.c:7587
       register_netdev+0x1a/0x30 net/core/dev.c:7669
       loopback_net_init+0x76/0x160 drivers/net/loopback.c:214
       ops_init+0x10a/0x570 net/core/net_namespace.c:118
       setup_net+0x313/0x710 net/core/net_namespace.c:294
       copy_net_ns+0x27c/0x580 net/core/net_namespace.c:418
       create_new_namespaces+0x425/0x880 kernel/nsproxy.c:107
       unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:206
       SYSC_unshare kernel/fork.c:2347 [inline]
       SyS_unshare+0x653/0xfa0 kernel/fork.c:2297
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      RIP: 0033:0x4512c9
      RSP: 002b:00007f21e0428c08 EFLAGS: 00000216 ORIG_RAX: 0000000000000110
      RAX: ffffffffffffffda RBX: 0000000000718150 RCX: 00000000004512c9
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000062020200
      RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000216 R12: 00000000004b973d
      R13: 00000000ffffffff R14: 000000002001d000 R15: 00000000000002dd
      Code: 50 2b 34 82 c7 00 f1 f1 f1 f1 c7 40 04 04 f2 f2 f2 c7 40 08 f3 f3
      f3 f3 e8 a1 43 39 ff 4c 89 f8 48 8b 95 70 ff ff ff 48 c1 e8 03 <0f> b6
      0c 18 4c 89 f8 83 e0 07 83 c0 03 38 c8 7c 08 84 c9 0f 85
      RIP: __read_once_size include/linux/compiler.h:250 [inline] RSP:
      ffff8801c6e5f1b0
      RIP: atomic_read arch/x86/include/asm/atomic.h:26 [inline] RSP:
      ffff8801c6e5f1b0
      RIP: refcount_sub_and_test+0x7d/0x1b0 lib/refcount.c:178 RSP:
      ffff8801c6e5f1b0
      ---[ end trace e441d046c6410d31 ]---
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12d94a80
    • L
      Merge tag 'linux-kselftest-4.13-rc6-fixes' of... · 40c6d1b9
      Linus Torvalds 提交于
      Merge tag 'linux-kselftest-4.13-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
      
      Pull kselftest fixes from Shuah Khan:
       "This update consists of important compile and run-time error fixes to
        timers/freq-step, kmod, and sysctl tests"
      
      * tag 'linux-kselftest-4.13-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
        selftests: timers: freq-step: fix compile error
        selftests: futex: fix run_tests target
        test_sysctl: fix sysctl.sh by making it executable
        test_kmod: fix kmod.sh by making it executable
      40c6d1b9
    • D
      Merge tag 'wireless-drivers-for-davem-2017-08-15' of... · 0a6f0418
      David S. Miller 提交于
      Merge tag 'wireless-drivers-for-davem-2017-08-15' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for 4.13
      
      This time quite a few fixes for iwlwifi and one major regression fix
      for brcmfmac. For the iwlwifi aggregation bug a small change was
      needed for mac80211, but as Johannes is still away the mac80211 patch
      is taken via wireless-drivers tree.
      
      brcmfmac
      
      * fix firmware crash (a recent regression in bcm4343{0,1,8}
      
      iwlwifi
      
      * Some simple PCI HW ID fix-ups and additions for family 9000
      
      * Remove a bogus warning message with new FWs (bug #196915)
      
      * Don't allow illegal channel options to be used (bug #195299)
      
      * A fix for checksum offload in family 9000
      
      * A fix serious throughput degradation in 11ac with multiple streams
      
      * An old bug in SMPS where the firmware was not aware of SMPS changes
      
      * Fix a memory leak in the SAR code
      
      * Fix a stuck queue case in AP mode;
      
      * Convert a WARN to a simple debug in a legitimate race case (from
        which we can recover)
      
      * Fix a severe throughput aggregation on 9000-family devices due to
        aggregation issues, needed a small change in mac80211
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a6f0418
  5. 15 8月, 2017 15 次提交
    • E
      tcp: fix possible deadlock in TCP stack vs BPF filter · d624d276
      Eric Dumazet 提交于
      Filtering the ACK packet was not put at the right place.
      
      At this place, we already allocated a child and put it
      into accept queue.
      
      We absolutely need to call tcp_child_process() to release
      its spinlock, or we will deadlock at accept() or close() time.
      
      Found by syzkaller team (Thanks a lot !)
      
      Fixes: 8fac365f ("tcp: Add a tcp_filter hook before handle ack packet")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: Chenbo Feng <fengc@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d624d276
    • E
      dccp: purge write queue in dccp_destroy_sock() · 7749d4ff
      Eric Dumazet 提交于
      syzkaller reported that DCCP could have a non empty
      write queue at dismantle time.
      
      WARNING: CPU: 1 PID: 2953 at net/core/stream.c:199 sk_stream_kill_queues+0x3ce/0x520 net/core/stream.c:199
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 1 PID: 2953 Comm: syz-executor0 Not tainted 4.13.0-rc4+ #2
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:16 [inline]
       dump_stack+0x194/0x257 lib/dump_stack.c:52
       panic+0x1e4/0x417 kernel/panic.c:180
       __warn+0x1c4/0x1d9 kernel/panic.c:541
       report_bug+0x211/0x2d0 lib/bug.c:183
       fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:190
       do_trap_no_signal arch/x86/kernel/traps.c:224 [inline]
       do_trap+0x260/0x390 arch/x86/kernel/traps.c:273
       do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:310
       do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:323
       invalid_op+0x1e/0x30 arch/x86/entry/entry_64.S:846
      RIP: 0010:sk_stream_kill_queues+0x3ce/0x520 net/core/stream.c:199
      RSP: 0018:ffff8801d182f108 EFLAGS: 00010297
      RAX: ffff8801d1144140 RBX: ffff8801d13cb280 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: ffffffff85137b00 RDI: ffff8801d13cb280
      RBP: ffff8801d182f148 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801d13cb4d0
      R13: ffff8801d13cb3b8 R14: ffff8801d13cb300 R15: ffff8801d13cb3b8
       inet_csk_destroy_sock+0x175/0x3f0 net/ipv4/inet_connection_sock.c:835
       dccp_close+0x84d/0xc10 net/dccp/proto.c:1067
       inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
       sock_release+0x8d/0x1e0 net/socket.c:597
       sock_close+0x16/0x20 net/socket.c:1126
       __fput+0x327/0x7e0 fs/file_table.c:210
       ____fput+0x15/0x20 fs/file_table.c:246
       task_work_run+0x18a/0x260 kernel/task_work.c:116
       exit_task_work include/linux/task_work.h:21 [inline]
       do_exit+0xa32/0x1b10 kernel/exit.c:865
       do_group_exit+0x149/0x400 kernel/exit.c:969
       get_signal+0x7e8/0x17e0 kernel/signal.c:2330
       do_signal+0x94/0x1ee0 arch/x86/kernel/signal.c:808
       exit_to_usermode_loop+0x21c/0x2d0 arch/x86/entry/common.c:157
       prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
       syscall_return_slowpath+0x3a7/0x450 arch/x86/entry/common.c:263
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7749d4ff
    • A
      udp: fix linear skb reception with PEEK_OFF · 42b73059
      Al Viro 提交于
      copy_linear_skb() is broken; both of its callers actually
      expect 'len' to be the amount we are trying to copy,
      not the offset of the end.
      Fix it keeping the meanings of arguments in sync with what the
      callers (both of them) expect.
      Also restore a saner behavior on EFAULT (i.e. preserving
      the iov_iter position in case of failure):
      
      The commit fd851ba9 ("udp: harden copy_linear_skb()")
      avoids the more destructive effect of the buggy
      copy_linear_skb(), e.g. no more invalid memory access, but
      said function still behaves incorrectly: when peeking with
      offset it can fail with EINVAL instead of copying the
      appropriate amount of memory.
      Reported-by: NSasha Levin <alexander.levin@verizon.com>
      Fixes: b65ac446 ("udp: try to avoid 2 cache miss on dequeue")
      Fixes: fd851ba9 ("udp: harden copy_linear_skb()")
      Signed-off-by: NAl Viro <viro@ZenIV.linux.org.uk>
      Acked-by: NPaolo Abeni <pabeni@redhat.com>
      Tested-by: NSasha Levin <alexander.levin@verizon.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42b73059
    • W
      ipv6: release rt6->rt6i_idev properly during ifdown · e5645f51
      Wei Wang 提交于
      When a dst is created by addrconf_dst_alloc() for a host route or an
      anycast route, dst->dev points to loopback dev while rt6->rt6i_idev
      points to a real device.
      When the real device goes down, the current cleanup code only checks for
      dst->dev and assumes rt6->rt6i_idev->dev is the same. This causes the
      refcount leak on the real device in the above situation.
      This patch makes sure to always release the refcount taken on
      rt6->rt6i_idev during dst_dev_put().
      
      Fixes: 587fea74 ("ipv6: mark DST_NOGC and remove the operation of
      dst_free()")
      Reported-by: NJohn Stultz <john.stultz@linaro.org>
      Tested-by: NJohn Stultz <john.stultz@linaro.org>
      Tested-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NWei Wang <weiwan@google.com>
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5645f51
    • E
      af_key: do not use GFP_KERNEL in atomic contexts · 36f41f8f
      Eric Dumazet 提交于
      pfkey_broadcast() might be called from non process contexts,
      we can not use GFP_KERNEL in these cases [1].
      
      This patch partially reverts commit ba51b6be ("net: Fix RCU splat in
      af_key"), only keeping the GFP_ATOMIC forcing under rcu_read_lock()
      section.
      
      [1] : syzkaller reported :
      
      in_atomic(): 1, irqs_disabled(): 0, pid: 2932, name: syzkaller183439
      3 locks held by syzkaller183439/2932:
       #0:  (&net->xfrm.xfrm_cfg_mutex){+.+.+.}, at: [<ffffffff83b43888>] pfkey_sendmsg+0x4c8/0x9f0 net/key/af_key.c:3649
       #1:  (&pfk->dump_lock){+.+.+.}, at: [<ffffffff83b467f6>] pfkey_do_dump+0x76/0x3f0 net/key/af_key.c:293
       #2:  (&(&net->xfrm.xfrm_policy_lock)->rlock){+...+.}, at: [<ffffffff83957632>] spin_lock_bh include/linux/spinlock.h:304 [inline]
       #2:  (&(&net->xfrm.xfrm_policy_lock)->rlock){+...+.}, at: [<ffffffff83957632>] xfrm_policy_walk+0x192/0xa30 net/xfrm/xfrm_policy.c:1028
      CPU: 0 PID: 2932 Comm: syzkaller183439 Not tainted 4.13.0-rc4+ #24
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:16 [inline]
       dump_stack+0x194/0x257 lib/dump_stack.c:52
       ___might_sleep+0x2b2/0x470 kernel/sched/core.c:5994
       __might_sleep+0x95/0x190 kernel/sched/core.c:5947
       slab_pre_alloc_hook mm/slab.h:416 [inline]
       slab_alloc mm/slab.c:3383 [inline]
       kmem_cache_alloc+0x24b/0x6e0 mm/slab.c:3559
       skb_clone+0x1a0/0x400 net/core/skbuff.c:1037
       pfkey_broadcast_one+0x4b2/0x6f0 net/key/af_key.c:207
       pfkey_broadcast+0x4ba/0x770 net/key/af_key.c:281
       dump_sp+0x3d6/0x500 net/key/af_key.c:2685
       xfrm_policy_walk+0x2f1/0xa30 net/xfrm/xfrm_policy.c:1042
       pfkey_dump_sp+0x42/0x50 net/key/af_key.c:2695
       pfkey_do_dump+0xaa/0x3f0 net/key/af_key.c:299
       pfkey_spddump+0x1a0/0x210 net/key/af_key.c:2722
       pfkey_process+0x606/0x710 net/key/af_key.c:2814
       pfkey_sendmsg+0x4d6/0x9f0 net/key/af_key.c:3650
      sock_sendmsg_nosec net/socket.c:633 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:643
       ___sys_sendmsg+0x755/0x890 net/socket.c:2035
       __sys_sendmsg+0xe5/0x210 net/socket.c:2069
       SYSC_sendmsg net/socket.c:2080 [inline]
       SyS_sendmsg+0x2d/0x50 net/socket.c:2076
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      RIP: 0033:0x445d79
      RSP: 002b:00007f32447c1dc8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000445d79
      RDX: 0000000000000000 RSI: 000000002023dfc8 RDI: 0000000000000008
      RBP: 0000000000000086 R08: 00007f32447c2700 R09: 00007f32447c2700
      R10: 00007f32447c2700 R11: 0000000000000202 R12: 0000000000000000
      R13: 00007ffe33edec4f R14: 00007f32447c29c0 R15: 0000000000000000
      
      Fixes: ba51b6be ("net: Fix RCU splat in af_key")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: David Ahern <dsa@cumulusnetworks.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      36f41f8f
    • S
      tcp: ulp: avoid module refcnt leak in tcp_set_ulp · 539a06ba
      Sabrina Dubroca 提交于
      __tcp_ulp_find_autoload returns tcp_ulp_ops after taking a reference on
      the module. Then, if ->init fails, tcp_set_ulp propagates the error but
      nothing releases that reference.
      
      Fixes: 734942cc ("tcp: ULP infrastructure")
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      539a06ba
    • D
      Merge branch 'Add-new-PCI_DEV_FLAGS_NO_RELAXED_ORDERING-flag' · bae514a6
      David S. Miller 提交于
      Ding Tianhong says:
      
      ====================
      Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
      
      Some devices have problems with Transaction Layer Packets with the Relaxed
      Ordering Attribute set.  This patch set adds a new PCIe Device Flag,
      PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
      devices with Relaxed Ordering issues, and a use of this new flag by the
      cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
      Ports.
      
      It's been years since I've submitted kernel.org patches, I appolgise for the
      almost certain submission errors.
      
      v2: Alexander point out that the v1 was only a part of the whole solution,
          some platform which has some issues could use the new flag to indicate
          that it is not safe to enable relaxed ordering attribute, then we need
          to clear the relaxed ordering enable bits in the PCI configuration when
          initializing the device. So add a new second patch to modify the PCI
          initialization code to clear the relaxed ordering enable bit in the
          event that the root complex doesn't want relaxed ordering enabled.
      
          The third patch was base on the v1's second patch and only be changed
          to query the relaxed ordering enable bit in the PCI configuration space
          to allow the Chelsio NIC to send TLPs with the relaxed ordering attributes
          set.
      
          This version didn't plan to drop the defines for Intel Drivers to use the
          new checking way to enable relaxed ordering because it is not the hardest
          part of the moment, we could fix it in next patchset when this patches
          reach the goal.
      
      v3: Redesigned the logic for pci_configure_relaxed_ordering when configuration,
          If a PCIe device didn't enable the relaxed ordering attribute default,
          we should not do anything in the PCIe configuration, otherwise we
          should check if any of the devices above us do not support relaxed
          ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on
          the result if we get a return that indicate that the relaxed ordering
          is not supported we should update our device to disable relaxed ordering
          in configuration space. If the device above us doesn't exist or isn't
          the PCIe device, we shouldn't do anything and skip updating relaxed ordering
          because we are probably running in a guest.
      
      v4: Rename the functions pcie_get_relaxed_ordering and pcie_disable_relaxed_ordering
          according John's suggestion, and modify the description, use the true/false
          as the return value.
      
          We shouldn't enable relaxed ordering attribute by the setting in the root
          complex configuration space for PCIe device, so fix it for cxgb4.
      
          Fix some format issues.
      
      v5: Removed the unnecessary code for some function which only return the bool
          value, and add the check for VF device.
      
          Make this patch set base on 4.12-rc5.
      
      v6: Fix the logic error in the need to enable the relaxed ordering attribute for cxgb4.
      
      v7: The cxgb4 drivers will enable the PCIe Capability Device Control[Relaxed
          Ordering Enable] in PCI Probe() routine, this will break our current
          solution for some platform which has problematic when enable the relaxed
          ordering attribute. According to the latest recommendations, remove the
          enable_pcie_relaxed_ordering(), although it could not cover the Peer-to-Peer
          scene, but we agree to leave this problem until we really trigger it.
      
          Make this patch set base on 4.12 release version.
      
      v8: Change the second patch title and description to make it more reasonable,
          add the acked-by from Alex and Ashok.
      
          Add a new patch to enable the Relaxed Ordering Attribute for cxgb4vf driver.
      
          Make this patch set base on 4.13-rc2.
      
      v9: The document (https://software.intel.com/sites/default/files/managed/9e/
          bc/64-ia-32-architectures-optimization-manual.pdf) indicate that the Xeon
          processors based on Broadwell/Haswell microarchitecture has the problem
          with Relaxed Ordering Attribute enabled, so add the whole list Device ID
          from Intel to the patch.
      
      v10: Significant rework based on Bjorn's feedback, reorganize the first 2 patches,
           now the Intel and AMD erratum soc has been divided to the different patches,
           rename the pcie_relaxed_ordering_supported() to pcie_relaxed_ordering_enabled(),
           and no need to check every intervening switch except the root ports, update
           some commits.
      
      v11: We shouldn't let the Intel engineer to acked the AMD's erratum patch, fix the
           funny mistake.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bae514a6
    • C
      net/cxgb4vf: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag · b629276d
      Casey Leedom 提交于
      cxgb4vf Ethernet driver now queries PCIe configuration space to
      determine if it can send TLPs to it with the Relaxed Ordering
      Attribute set, just like the pf did.
      Signed-off-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Reviewed-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b629276d
    • C
      net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag · b0ba9d5f
      Casey Leedom 提交于
      cxgb4 Ethernet driver now queries PCIe configuration space to determine
      if it can send TLPs to it with the Relaxed Ordering Attribute set.
      
      Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability
      Device Control[Relaxed Ordering Enable] at probe routine, to make sure
      the driver will not send the Relaxed Ordering TLPs to the Root Complex which
      could not deal the Relaxed Ordering TLPs.
      Signed-off-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Reviewed-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0ba9d5f
    • D
      PCI: Disable Relaxed Ordering Attributes for AMD A1100 · 077fa19c
      dingtianhong 提交于
      Casey reported that the AMD ARM A1100 SoC has a bug in its PCIe
      Root Port where Upstream Transaction Layer Packets with the Relaxed
      Ordering Attribute clear are allowed to bypass earlier TLPs with
      Relaxed Ordering set, it would cause Data Corruption, so we need
      to disable Relaxed Ordering Attribute when Upstream TLPs to the
      Root Port.
      Reported-and-suggested-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Acked-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      077fa19c
    • D
      PCI: Disable Relaxed Ordering for some Intel processors · 87e09cde
      dingtianhong 提交于
      According to the Intel spec section 3.9.1 said:
      
          3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory
                and Toward MMIO Regions (P2P)
      
          In order to maximize performance for PCIe devices in the processors
          listed in Table 3-6 below, the soft- ware should determine whether the
          accesses are toward coherent memory (system memory) or toward MMIO
          regions (P2P access to other devices). If the access is toward MMIO
          region, then software can command HW to set the RO bit in the TLP
          header, as this would allow hardware to achieve maximum throughput for
          these types of accesses. For accesses toward coherent memory, software
          can command HW to clear the RO bit in the TLP header (no RO), as this
          would allow hardware to achieve maximum throughput for these types of
          accesses.
      
          Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing
                     PCIe Performance
      
          Processor                            CPU RP Device IDs
      
          Intel Xeon processors based on       6F01H-6F0EH
          Broadwell microarchitecture
      
          Intel Xeon processors based on       2F01H-2F0EH
          Haswell microarchitecture
      
      It means some Intel processors has performance issue when use the Relaxed
      Ordering Attribute, so disable Relaxed Ordering for these root port.
      Signed-off-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Acked-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Acked-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87e09cde
    • D
      PCI: Disable PCIe Relaxed Ordering if unsupported · a99b646a
      dingtianhong 提交于
      When bit4 is set in the PCIe Device Control register, it indicates
      whether the device is permitted to use relaxed ordering.
      On some platforms using relaxed ordering can have performance issues or
      due to erratum can cause data-corruption. In such cases devices must avoid
      using relaxed ordering.
      
      The patch adds a new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING to indicate that
      Relaxed Ordering (RO) attribute should not be used for Transaction Layer
      Packets (TLP) targeted towards these affected root complexes.
      
      This patch checks if there is any node in the hierarchy that indicates that
      using relaxed ordering is not safe. In such cases the patch turns off the
      relaxed ordering by clearing the capability for this device.
      Signed-off-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Acked-by: NAshok Raj <ashok.raj@intel.com>
      Acked-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Acked-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a99b646a
    • L
      Merge tag 'md/4.13-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md · fcd07350
      Linus Torvalds 提交于
      Pull MD fixes from Shaohua Li:
       "Fix several bugs:
      
         - fix a rcu stall issue introduced in 4.12 (Neil Brown)
      
         - fix two raid5 cache race conditions (Song Liu)"
      
      * tag 'md/4.13-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md:
        MD: not clear ->safemode for external metadata array
        md/r5cache: fix io_unit handling in r5l_log_endio()
        md/r5cache: call mddev_lock/unlock() in r5c_journal_mode_set
        md: fix test in md_write_start()
        md: always clear ->safemode when md_check_recovery gets the mddev lock.
      fcd07350
    • L
      Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · 6b9d1c24
      Linus Torvalds 提交于
      Pull crypto fixes from Herbert Xu:
       "Fix an error path bug in ixp4xx as well as a read overrun in
       sha1-avx2"
      
      * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: x86/sha1 - Fix reads beyond the number of blocks passed
        crypto: ixp4xx - Fix error handling path in 'aead_perform()'
      6b9d1c24
    • J
      tipc: avoid inheriting msg_non_seq flag when message is returned · 59a361bc
      Jon Paul Maloy 提交于
      In the function msg_reverse(), we reverse the header while trying to
      reuse the original buffer whenever possible. Those rejected/returned
      messages are always transmitted as unicast, but the msg_non_seq field
      is not explicitly set to zero as it should be.
      
      We have seen cases where multicast senders set the message type to
      "NOT dest_droppable", meaning that a multicast message shorter than
      one MTU will be returned, e.g., during receive buffer overflow, by
      reusing the original buffer. This has the effect that even the
      'msg_non_seq' field is inadvertently inherited by the rejected message,
      although it is now sent as a unicast message. This again leads the
      receiving unicast link endpoint to steer the packet toward the broadcast
      link receive function, where it is dropped. The affected unicast link is
      thereafter (after 100 failed retransmissions) declared 'stale' and
      reset.
      
      We fix this by unconditionally setting the 'msg_non_seq' flag to zero
      for all rejected/returned messages.
      Reported-by: NCanh Duc Luu <canh.d.luu@dektech.com.au>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59a361bc