1. 10 Mar, 2017 11 commits
    • Lendacky, Thomas's avatar
      amd-xgbe: Enable IRQs only if napi_complete_done() is true · d7aba644
      Lendacky, Thomas authored
      Depending on the hardware, the amd-xgbe driver may use disable_irq_nosync()
      and enable_irq() when an interrupt is received to process Rx packets. If
      the napi_complete_done() return value isn't checked an unbalanced enable
      for the IRQ could result, generating a warning stack trace.
      
      Update the driver to only enable interrupts if napi_complete_done() returns
      true.
      Reported-by: default avatarJeremy Linton <jeremy.linton@arm.com>
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7aba644
    • David Howells's avatar
      rxrpc: rxrpc_kernel_send_data() needs to handle failed call better · 6fc166d6
      David Howells authored
      If rxrpc_kernel_send_data() is asked to send data through a call that has
      already failed (due to a remote abort, received protocol error or network
      error), then return the associated error code saved in the call rather than
      ESHUTDOWN.
      
      This allows the caller to work out whether to ask for the abort code or not
      based on this.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6fc166d6
    • Alexey Kodanev's avatar
      udp: avoid ufo handling on IP payload compression packets · 4b3b45ed
      Alexey Kodanev authored
      commit c146066a ("ipv4: Don't use ufo handling on later transformed
      packets") and commit f89c56ce ("ipv6: Don't use ufo handling on
      later transformed packets") added a check that 'rt->dst.header_len' isn't
      zero in order to skip UFO, but it doesn't include IPcomp in transport mode
      where it equals zero.
      
      Packets, after payload compression, may not require further fragmentation,
      and if original length exceeds MTU, later compressed packets will be
      transmitted incorrectly. This can be reproduced with LTP udp_ipsec.sh test
      on veth device with enabled UFO, MTU is 1500 and UDP payload is 2000:
      
      * IPv4 case, offset is wrong + unnecessary fragmentation
          udp_ipsec.sh -p comp -m transport -s 2000 &
          tcpdump -ni ltp_ns_veth2
          ...
          IP (tos 0x0, ttl 64, id 45203, offset 0, flags [+],
            proto Compressed IP (108), length 49)
            10.0.0.2 > 10.0.0.1: IPComp(cpi=0x1000)
          IP (tos 0x0, ttl 64, id 45203, offset 1480, flags [none],
            proto UDP (17), length 21) 10.0.0.2 > 10.0.0.1: ip-proto-17
      
      * IPv6 case, sending small fragments
          udp_ipsec.sh -6 -p comp -m transport -s 2000 &
          tcpdump -ni ltp_ns_veth2
          ...
          IP6 (flowlabel 0x6b9ba, hlim 64, next-header Compressed IP (108)
            payload length: 37) fd00::2 > fd00::1: IPComp(cpi=0x1000)
          IP6 (flowlabel 0x6b9ba, hlim 64, next-header Compressed IP (108)
            payload length: 21) fd00::2 > fd00::1: IPComp(cpi=0x1000)
      
      Fix it by checking 'rt->dst.xfrm' pointer to 'xfrm_state' struct, skip UFO
      if xfrm is set. So the new check will include both cases: IPcomp and IPsec.
      
      Fixes: c146066a ("ipv4: Don't use ufo handling on later transformed packets")
      Fixes: f89c56ce ("ipv6: Don't use ufo handling on later transformed packets")
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b3b45ed
    • David Howells's avatar
      net: Work around lockdep limitation in sockets that use sockets · cdfbabfb
      David Howells authored
      Lockdep issues a circular dependency warning when AFS issues an operation
      through AF_RXRPC from a context in which the VFS/VM holds the mmap_sem.
      
      The theory lockdep comes up with is as follows:
      
       (1) If the pagefault handler decides it needs to read pages from AFS, it
           calls AFS with mmap_sem held and AFS begins an AF_RXRPC call, but
           creating a call requires the socket lock:
      
      	mmap_sem must be taken before sk_lock-AF_RXRPC
      
       (2) afs_open_socket() opens an AF_RXRPC socket and binds it.  rxrpc_bind()
           binds the underlying UDP socket whilst holding its socket lock.
           inet_bind() takes its own socket lock:
      
      	sk_lock-AF_RXRPC must be taken before sk_lock-AF_INET
      
       (3) Reading from a TCP socket into a userspace buffer might cause a fault
           and thus cause the kernel to take the mmap_sem, but the TCP socket is
           locked whilst doing this:
      
      	sk_lock-AF_INET must be taken before mmap_sem
      
      However, lockdep's theory is wrong in this instance because it deals only
      with lock classes and not individual locks.  The AF_INET lock in (2) isn't
      really equivalent to the AF_INET lock in (3) as the former deals with a
      socket entirely internal to the kernel that never sees userspace.  This is
      a limitation in the design of lockdep.
      
      Fix the general case by:
      
       (1) Double up all the locking keys used in sockets so that one set are
           used if the socket is created by userspace and the other set is used
           if the socket is created by the kernel.
      
       (2) Store the kern parameter passed to sk_alloc() in a variable in the
           sock struct (sk_kern_sock).  This informs sock_lock_init(),
           sock_init_data() and sk_clone_lock() as to the lock keys to be used.
      
           Note that the child created by sk_clone_lock() inherits the parent's
           kern setting.
      
       (3) Add a 'kern' parameter to ->accept() that is analogous to the one
           passed in to ->create() that distinguishes whether kernel_accept() or
           sys_accept4() was the caller and can be passed to sk_alloc().
      
           Note that a lot of accept functions merely dequeue an already
           allocated socket.  I haven't touched these as the new socket already
           exists before we get the parameter.
      
           Note also that there are a couple of places where I've made the accepted
           socket unconditionally kernel-based:
      
      	irda_accept()
      	rds_rcp_accept_one()
      	tcp_accept_from_sock()
      
           because they follow a sock_create_kern() and accept off of that.
      
      Whilst creating this, I noticed that lustre and ocfs don't create sockets
      through sock_create_kern() and thus they aren't marked as for-kernel,
      though they appear to be internal.  I wonder if these should do that so
      that they use the new set of lock keys.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cdfbabfb
    • David S. Miller's avatar
      Merge branch 'bnxt_en-misc-small-fixes' · 81dca07b
      David S. Miller authored
      Michael Chan says:
      
      ====================
      bnxt_en: Misc. small fixes.
      
      Fixes include moving the initial function reset, notifying the RDMA driver
      during tx timeout, setting dcbx_cap properly depending on whether the
      firmware agent is running or not, and an autoneg related improvement.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81dca07b
    • Michael Chan's avatar
      bnxt_en: Ignore 0 value in autoneg supported speed from firmware. · 520ad89a
      Michael Chan authored
      In some situations, the firmware will return 0 for autoneg supported
      speed.  This may happen if the firmware detects no SFP module, for
      example.  The driver should ignore this so that we don't end up with
      an invalid autoneg setting with nothing advertised.  When SFP module
      is inserted, we'll get the updated settings from firmware at that time.
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      520ad89a
    • Michael Chan's avatar
      bnxt_en: Check if firmware LLDP agent is running. · bc39f885
      Michael Chan authored
      Set DCB_CAP_DCBX_HOST capability flag only if the firmware LLDP agent
      is not running.
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc39f885
    • Michael Chan's avatar
      bnxt_en: Call bnxt_ulp_stop() during tx timeout. · b386cd36
      Michael Chan authored
      If we call bnxt_reset_task() due to tx timeout, we should call
      bnxt_ulp_stop() to inform the RDMA driver about the error and the
      impending reset.
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b386cd36
    • Michael Chan's avatar
      bnxt_en: Perform function reset earlier during probe. · 3c2217a6
      Michael Chan authored
      The firmware call to do function reset is done too late.  It is causing
      the rings that have been reserved to be freed.  In NPAR mode, this bug
      is causing us to run out of rings.
      
      Fixes: 391be5c2 ("bnxt_en: Implement new scheme to reserve tx rings.")
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c2217a6
    • LABBE Corentin's avatar
      tun: remove copyright printing · 6cbac982
      LABBE Corentin authored
      Printing copyright does not give any useful information on the boot
      process.
      Furthermore, the email address printed is obsolete since
      commit ba57b6f2 ("MAINTAINERS: fix bouncing tun/tap entries")
      Signed-off-by: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6cbac982
    • Alexander Potapenko's avatar
      net: initialize msg.msg_flags in recvfrom · 9f138fa6
      Alexander Potapenko authored
      KMSAN reports a use of uninitialized memory in put_cmsg() because
      msg.msg_flags in recvfrom haven't been initialized properly.
      The flag values don't affect the result on this path, but it's still a
      good idea to initialize them explicitly.
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f138fa6
  2. 09 Mar, 2017 27 commits
  3. 07 Mar, 2017 2 commits
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · 8474c8ca
      David S. Miller authored
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2017-03-06
      
      1) Fix lockdep splat on xfrm policy subsystem initialization.
         From Florian Westphal.
      
      2) When using socket policies on IPv4-mapped IPv6 addresses,
         we access the flow informations of the wrong address family
         what leads to an out of bounds access. Fix this by using
         the family we get with the dst_entry, like we do it for the
         standard policy lookup.
      
      3) vti6 can report a PMTU below IPV6_MIN_MTU. Fix this by
         adding a check for that before sending a ICMPV6_PKT_TOOBIG
         message.
      
      Please pull or let me know if there are problems.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8474c8ca
    • WANG Cong's avatar
      ipv6: reorder icmpv6_init() and ip6_mr_init() · 15e66807
      WANG Cong authored
      Andrey reported the following kernel crash:
      
      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: 0 PID: 14446 Comm: syz-executor6 Not tainted 4.10.0+ #82
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      task: ffff88001f311700 task.stack: ffff88001f6e8000
      RIP: 0010:ip6mr_sk_done+0x15a/0x3d0 net/ipv6/ip6mr.c:1618
      RSP: 0018:ffff88001f6ef418 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: 1ffff10003edde8c RCX: ffffc900043ee000
      RDX: 0000000000000004 RSI: ffffffff83e3b3f8 RDI: 0000000000000020
      RBP: ffff88001f6ef508 R08: fffffbfff0dcc5d8 R09: 0000000000000000
      R10: ffffffff86e62ec0 R11: 0000000000000000 R12: 0000000000000000
      R13: 0000000000000000 R14: ffff88001f6ef4e0 R15: ffff8800380a0040
      FS:  00007f7a52cec700(0000) GS:ffff88003ec00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000000061c500 CR3: 000000001f1ae000 CR4: 00000000000006f0
      DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
      Call Trace:
       rawv6_close+0x4c/0x80 net/ipv6/raw.c:1217
       inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
       inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
       sock_release+0x8d/0x1e0 net/socket.c:597
       __sock_create+0x39d/0x880 net/socket.c:1226
       sock_create_kern+0x3f/0x50 net/socket.c:1243
       inet_ctl_sock_create+0xbb/0x280 net/ipv4/af_inet.c:1526
       icmpv6_sk_init+0x163/0x500 net/ipv6/icmp.c:954
       ops_init+0x10a/0x550 net/core/net_namespace.c:115
       setup_net+0x261/0x660 net/core/net_namespace.c:291
       copy_net_ns+0x27e/0x540 net/core/net_namespace.c:396
      9pnet_virtio: no channels available for device ./file1
       create_new_namespaces+0x437/0x9b0 kernel/nsproxy.c:106
       unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205
       SYSC_unshare kernel/fork.c:2281 [inline]
       SyS_unshare+0x64e/0x1000 kernel/fork.c:2231
       entry_SYSCALL_64_fastpath+0x1f/0xc2
      
      This is because net->ipv6.mr6_tables is not initialized at that point,
      ip6mr_rules_init() is not called yet, therefore on the error path when
      we iterator the list, we trigger this oops. Fix this by reordering
      ip6mr_rules_init() before icmpv6_sk_init().
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15e66807