1. 09 9月, 2016 13 次提交
  2. 08 9月, 2016 1 次提交
  3. 07 9月, 2016 6 次提交
  4. 05 9月, 2016 6 次提交
    • L
      af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock' · 6e1ce3c3
      Linus Torvalds 提交于
      Right now we use the 'readlock' both for protecting some of the af_unix
      IO path and for making the bind be single-threaded.
      
      The two are independent, but using the same lock makes for a nasty
      deadlock due to ordering with regards to filesystem locking.  The bind
      locking would want to nest outside the VSF pathname locking, but the IO
      locking wants to nest inside some of those same locks.
      
      We tried to fix this earlier with commit c845acb3 ("af_unix: Fix
      splice-bind deadlock") which moved the readlock inside the vfs locks,
      but that caused problems with overlayfs that will then call back into
      filesystem routines that take the lock in the wrong order anyway.
      
      Splitting the locks means that we can go back to having the bind lock be
      the outermost lock, and we don't have any deadlocks with lock ordering.
      Acked-by: NRainer Weikusat <rweikusat@cyberadapt.com>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e1ce3c3
    • L
      Revert "af_unix: Fix splice-bind deadlock" · 38f7bd94
      Linus Torvalds 提交于
      This reverts commit c845acb3.
      
      It turns out that it just replaces one deadlock with another one: we can
      still get the wrong lock ordering with the readlock due to overlayfs
      calling back into the filesystem layer and still taking the vfs locks
      after the readlock.
      
      The proper solution ends up being to just split the readlock into two
      pieces: the bind lock (taken *outside* the vfs locks) and the IO lock
      (taken *inside* the filesystem locks).  The two locks are independent
      anyway.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Reviewed-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38f7bd94
    • D
      Merge branch 'vxlan-fixes' · 2f83a53a
      David S. Miller 提交于
      Jiri Benc says:
      
      ====================
      vxlan: fix error reporting
      
      This patchset improves checking for invalid configuration in VXLAN and
      fixes problems with duplicated and inappropriate error messages.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2f83a53a
    • J
      vxlan: fix duplicated and wrong error messages · 3555621d
      Jiri Benc 提交于
      vxlan_dev_configure outputs error messages before returning, no need to
      print again the same mesages in vxlan_newlink. Also, vxlan_dev_configure may
      return a particular error code for a different reason than vxlan_newlink
      thinks.
      
      Move the remaining error messages into vxlan_dev_configure and let
      vxlan_newlink just pass on the error code.
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3555621d
    • J
      vxlan: reject multicast destination without an interface · 9b4cdd51
      Jiri Benc 提交于
      Currently, kernel accepts configurations such as:
      
        ip l a type vxlan dstport 4789 id 1 group 239.192.0.1
        ip l a type vxlan dstport 4789 id 1 group ff0e::110
      
      However, neither of those really works. In the IPv4 case, the interface
      cannot be brought up ("RTNETLINK answers: No such device"). This is because
      multicast join will be rejected without the interface being specified.
      
      In the IPv6 case, multicast wil be joined on the first interface found. This
      is not what the user wants as it depends on random factors (order of
      interfaces).
      
      Note that it's possible to add a local address but it doesn't solve
      anything. For IPv4, it's not considered in the multicast join (thus the same
      error as above is returned on ifup). This could be added but it wouldn't
      help for IPv6 anyway. For IPv6, we do need the interface.
      
      Just reject a configuration that sets multicast address and does not provide
      an interface. Nobody can depend on the previous behavior as it never worked.
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b4cdd51
    • M
      bonding: Fix bonding crash · 24b27fc4
      Mahesh Bandewar 提交于
      Following few steps will crash kernel -
      
        (a) Create bonding master
            > modprobe bonding miimon=50
        (b) Create macvlan bridge on eth2
            > ip link add link eth2 dev mvl0 address aa:0:0:0:0:01 \
      	   type macvlan
        (c) Now try adding eth2 into the bond
            > echo +eth2 > /sys/class/net/bond0/bonding/slaves
            <crash>
      
      Bonding does lots of things before checking if the device enslaved is
      busy or not.
      
      In this case when the notifier call-chain sends notifications, the
      bond_netdev_event() assumes that the rx_handler /rx_handler_data is
      registered while the bond_enslave() hasn't progressed far enough to
      register rx_handler for the new slave.
      
      This patch adds a rx_handler check that can be performed right at the
      beginning of the enslave code to avoid getting into this situation.
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24b27fc4
  5. 03 9月, 2016 6 次提交
  6. 02 9月, 2016 8 次提交