1. 22 Mar, 2017 25 commits
  2. 21 Mar, 2017 9 commits
    • Yaroslav Isakov's avatar
      tun: fix inability to set offloads after disabling them via ethtool · 09050957
      Yaroslav Isakov authored
      Added missing logic in tun driver, which prevents apps to set
      offloads using tun ioctl, if offloads were previously disabled via ethtool
      Signed-off-by: default avatarYaroslav Isakov <yaroslav.isakov@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      09050957
    • Andrey Ulanov's avatar
      net: unix: properly re-increment inflight counter of GC discarded candidates · 7df9c246
      Andrey Ulanov authored
      Dmitry has reported that a BUG_ON() condition in unix_notinflight()
      may be triggered by a simple code that forwards unix socket in an
      SCM_RIGHTS message.
      That is caused by incorrect unix socket GC implementation in unix_gc().
      
      The GC first collects list of candidates, then (a) decrements their
      "children's" inflight counter, (b) checks which inflight counters are
      now 0, and then (c) increments all inflight counters back.
      (a) and (c) are done by calling scan_children() with inc_inflight or
      dec_inflight as the second argument.
      
      Commit 6209344f ("net: unix: fix inflight counting bug in garbage
      collector") changed scan_children() such that it no longer considers
      sockets that do not have UNIX_GC_CANDIDATE flag. It also added a block
      of code that that unsets this flag _before_ invoking
      scan_children(, dec_iflight, ). This may lead to incorrect inflight
      counters for some sockets.
      
      This change fixes this bug by changing order of operations:
      UNIX_GC_CANDIDATE is now unset only after all inflight counters are
      restored to the original state.
      
        kernel BUG at net/unix/garbage.c:149!
        RIP: 0010:[<ffffffff8717ebf4>]  [<ffffffff8717ebf4>]
        unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
        Call Trace:
         [<ffffffff8716cfbf>] unix_detach_fds.isra.19+0xff/0x170 net/unix/af_unix.c:1487
         [<ffffffff8716f6a9>] unix_destruct_scm+0xf9/0x210 net/unix/af_unix.c:1496
         [<ffffffff86a90a01>] skb_release_head_state+0x101/0x200 net/core/skbuff.c:655
         [<ffffffff86a9808a>] skb_release_all+0x1a/0x60 net/core/skbuff.c:668
         [<ffffffff86a980ea>] __kfree_skb+0x1a/0x30 net/core/skbuff.c:684
         [<ffffffff86a98284>] kfree_skb+0x184/0x570 net/core/skbuff.c:705
         [<ffffffff871789d5>] unix_release_sock+0x5b5/0xbd0 net/unix/af_unix.c:559
         [<ffffffff87179039>] unix_release+0x49/0x90 net/unix/af_unix.c:836
         [<ffffffff86a694b2>] sock_release+0x92/0x1f0 net/socket.c:570
         [<ffffffff86a6962b>] sock_close+0x1b/0x20 net/socket.c:1017
         [<ffffffff81a76b8e>] __fput+0x34e/0x910 fs/file_table.c:208
         [<ffffffff81a771da>] ____fput+0x1a/0x20 fs/file_table.c:244
         [<ffffffff81483ab0>] task_work_run+0x1a0/0x280 kernel/task_work.c:116
         [<     inline     >] exit_task_work include/linux/task_work.h:21
         [<ffffffff8141287a>] do_exit+0x183a/0x2640 kernel/exit.c:828
         [<ffffffff8141383e>] do_group_exit+0x14e/0x420 kernel/exit.c:931
         [<ffffffff814429d3>] get_signal+0x663/0x1880 kernel/signal.c:2307
         [<ffffffff81239b45>] do_signal+0xc5/0x2190 arch/x86/kernel/signal.c:807
         [<ffffffff8100666a>] exit_to_usermode_loop+0x1ea/0x2d0
        arch/x86/entry/common.c:156
         [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
         [<ffffffff81009693>] syscall_return_slowpath+0x4d3/0x570
        arch/x86/entry/common.c:259
         [<ffffffff881478e6>] entry_SYSCALL_64_fastpath+0xc4/0xc6
      
      Link: https://lkml.org/lkml/2017/3/6/252Signed-off-by: default avatarAndrey Ulanov <andreyu@google.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Fixes: 6209344f ("net: unix: fix inflight counting bug in garbage collector")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7df9c246
    • David S. Miller's avatar
      Merge branch 'vsock-pkt-cancel' · a59d376d
      David S. Miller authored
      Peng Tao says:
      
      ====================
      vsock: cancel connect packets when failing to connect
      
      Currently, if a connect call fails on a signal or timeout (e.g., guest is still
      in the process of starting up), we'll just return to caller and leave the connect
      packet queued and they are sent even though the connection is considered a failure,
      which can confuse applications with unwanted false connect attempt.
      
      The patchset enables vsock (both host and guest) to cancel queued packets when
      a connect attempt is considered to fail.
      
      v5 changelog:
        - change virtio_vsock_pkt->cancel_token back to virtio_vsock_pkt->vsk
      v4 changelog:
        - drop two unnecessary void * cast
        - update new callback comment
      v3 changelog:
        - define cancel_pkt callback in struct vsock_transport rather than struct virtio_transport
        - rename virtio_vsock_pkt->vsk to virtio_vsock_pkt->cancel_token
      v2 changelog:
        - fix queued_replies counting and resume tx/rx when necessary
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a59d376d
    • Peng Tao's avatar
      vsock: cancel packets when failing to connect · 380feae0
      Peng Tao authored
      Otherwise we'll leave the packets queued until releasing vsock device.
      E.g., if guest is slow to start up, resulting ETIMEDOUT on connect, guest
      will get the connect requests from failed host sockets.
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarJorgen Hansen <jhansen@vmware.com>
      Signed-off-by: default avatarPeng Tao <bergwolf@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      380feae0
    • Peng Tao's avatar
      vsock: add pkt cancel capability · 073b4f2c
      Peng Tao authored
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarPeng Tao <bergwolf@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      073b4f2c
    • Peng Tao's avatar
      vhost-vsock: add pkt cancel capability · 16320f36
      Peng Tao authored
      To allow canceling all packets of a connection.
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarJorgen Hansen <jhansen@vmware.com>
      Signed-off-by: default avatarPeng Tao <bergwolf@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16320f36
    • Peng Tao's avatar
      vsock: track pkt owner vsock · 36d277ba
      Peng Tao authored
      So that we can cancel a queued pkt later if necessary.
      Signed-off-by: default avatarPeng Tao <bergwolf@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      36d277ba
    • Herbert Xu's avatar
      crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex · 8a0f5ccf
      Herbert Xu authored
      On Tue, Mar 14, 2017 at 10:44:10AM +0100, Dmitry Vyukov wrote:
      >
      > Yes, please.
      > Disregarding some reports is not a good way long term.
      
      Please try this patch.
      
      ---8<---
      Subject: netlink: Annotate nlk cb_mutex by protocol
      
      Currently all occurences of nlk->cb_mutex are annotated by lockdep
      as a single class.  This causes a false lcokdep cycle involving
      genl and crypto_user.
      
      This patch fixes it by dividing cb_mutex into individual classes
      based on the netlink protocol.  As genl and crypto_user do not
      use the same netlink protocol this breaks the false dependency
      loop.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a0f5ccf
    • hayeswang's avatar
      r8152: fix the list rx_done may be used without initialization · 98d068ab
      hayeswang authored
      The list rx_done would be initialized when the linking on occurs.
      Therefore, if a napi is scheduled without any linking on before,
      the following kernel panic would happen.
      
      	BUG: unable to handle kernel NULL pointer dereference at 000000000000008
      	IP: [<ffffffffc085efde>] r8152_poll+0xe1e/0x1210 [r8152]
      	PGD 0
      	Oops: 0002 [#1] SMP
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      98d068ab
  3. 20 Mar, 2017 1 commit
    • Ryan Hsu's avatar
      ath10k: fix incorrect wlan_mac_base in qca6174_regs · 6be3b6cc
      Ryan Hsu authored
      In the 'commit ebee76f7 ("ath10k: allow setting coverage class")',
      it inherits the design and the address offset from ath9k, but the address
      is not applicable to QCA6174, which leads to a random crash while doing the
      resume() operation, since the set_coverage_class.ops will be called from
      ieee80211_reconfig() when resume() (if the wow is not configured).
      
      Fix the incorrect address offset here to avoid the random crash.
      
      Verified on QCA6174/hw3.0 with firmware WLAN.RM.4.4-00022-QCARMSWPZ-2.
      
      kvalo: this also seems to fix a regression with firmware restart.
      
      Fixes: ebee76f7 ("ath10k: allow setting coverage class")
      Cc: <stable@vger.kernel.org> # v4.10
      Signed-off-by: default avatarRyan Hsu <ryanhsu@qca.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      6be3b6cc
  4. 17 Mar, 2017 5 commits
    • Eric Dumazet's avatar
      tcp: tcp_get_info() should read tcp_time_stamp later · db7f00b8
      Eric Dumazet authored
      Commit b369e7fd ("tcp: make TCP_INFO more consistent") moved
      lock_sock_fast() earlier in tcp_get_info()
      
      This has the minor effect that jiffies value being sampled at the
      beginning of tcp_get_info() is more likely to be off by one, and we
      report big tcpi_last_data_sent values (like 0xFFFFFFFF).
      
      Since we lock the socket, fetching tcp_time_stamp right before
      doing the jiffies_to_msecs() calls is enough to remove these
      wrong values.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db7f00b8
    • stephen hemminger's avatar
      netvsc: fix race during initialization · e14b4db7
      stephen hemminger authored
      When device is being setup on boot, there is a small race where
      network device callback is registered, but the netvsc_device pointer
      is not set yet.  This can cause a NULL ptr dereference if packet
      arrives during this window.
      
      Fixes: 46b4f7f5 ("netvsc: eliminate per-device outstanding send counter")
      Signed-off-by: default avatarStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e14b4db7
    • WANG Cong's avatar
      bridge: resolve a false alarm of lockdep · d12c9176
      WANG Cong authored
      Andrei reported a false alarm of lockdep at net/bridge/br_fdb.c:109,
      this is because in Andrei's case, a spin_bug() was already triggered
      before this, therefore the debug_locks is turned off, lockdep_is_held()
      is no longer accurate after that. We should use lockdep_assert_held_once()
      instead of lockdep_is_held() to respect debug_locks.
      
      Fixes: 410b3d48 ("bridge: fdb: add proper lock checks in searching functions")
      Reported-by: default avatarAndrei Vagin <avagin@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d12c9176
    • David Howells's avatar
      rxrpc: Ignore BUSY packets on old calls · 4d4a6ac7
      David Howells authored
      If we receive a BUSY packet for a call we think we've just completed, the
      packet is handed off to the connection processor to deal with - but the
      connection processor doesn't expect a BUSY packet and so flags a protocol
      error.
      
      Fix this by simply ignoring the BUSY packet for the moment.
      
      The symptom of this may appear as a system call failing with EPROTO.  This
      may be triggered by pressing ctrl-C under some circumstances.
      
      This comes about we abort calls due to interruption by a signal (which we
      shouldn't do, but that's going to be a large fix and mostly in fs/afs/).
      What happens is that we abort the call and may also abort follow up calls
      too (this needs offloading somehoe).  So we see a transmission of something
      like the following sequence of packets:
      
      	DATA for call N
      	ABORT call N
      	DATA for call N+1
      	ABORT call N+1
      
      in very quick succession on the same channel.  However, the peer may have
      deferred the processing of the ABORT from the call N to a background thread
      and thus sees the DATA message from the call N+1 coming in before it has
      cleared the channel.  Thus it sends a BUSY packet[*].
      
      [*] Note that some implementations (OpenAFS, for example) mark the BUSY
          packet with one plus the callNumber of the call prior to call N.
          Ordinarily, this would be call N, but there's no requirement for the
          calls on a channel to be numbered strictly sequentially (the number is
          required to increase).
      
          This is wrong and means that the callNumber in the BUSY packet should
          be ignored (it really ought to be N+1 since that's what it's in
          response to).
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4d4a6ac7
    • Nathan Fontenot's avatar
      ibmvnic: Free tx/rx scrq pointer array when releasing sub-crqs · 9501df3c
      Nathan Fontenot authored
      The pointer array for the tx/rx sub crqs should be free'ed when
      releasing the tx/rx sub crqs.
      Signed-off-by: default avatarNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9501df3c