1. 10 Dec, 2012 7 commits
  2. 09 Dec, 2012 11 commits
  3. 07 Dec, 2012 22 commits
    • Paul Gortmaker's avatar
      tipc: refactor accept() code for improved readability · 0fef8f20
      Paul Gortmaker authored
      In TIPC's accept() routine, there is a large block of code relating
      to initialization of a new socket, all within an if condition checking
      if the allocation succeeded.
      
      Here, we simply flip the check of the if, so that the main execution
      path stays at the same indentation level, which improves readability.
      If the allocation fails, we jump to an already existing exit label.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      0fef8f20
    • Ying Xue's avatar
      tipc: add lock nesting notation to quiet lockdep warning · 258f8667
      Ying Xue authored
      TIPC accept() call grabs the socket lock on a newly allocated
      socket while holding the socket lock on an old socket. But lockdep
      worries that this might be a recursive lock attempt:
      
        [ INFO: possible recursive locking detected ]
        ---------------------------------------------
        kworker/u:0/6 is trying to acquire lock:
        (sk_lock-AF_TIPC){+.+.+.}, at: [<c8c1226c>] accept+0x15c/0x310 [tipc]
      
        but task is already holding lock:
        (sk_lock-AF_TIPC){+.+.+.}, at: [<c8c12138>] accept+0x28/0x310 [tipc]
      
        other info that might help us debug this:
        Possible unsafe locking scenario:
      
                CPU0
                ----
                lock(sk_lock-AF_TIPC);
                lock(sk_lock-AF_TIPC);
      
                *** DEADLOCK ***
      
        May be due to missing lock nesting notation
        [...]
      
      Tell lockdep that this locking is safe by using lock_sock_nested().
      This is similar to what was done in commit 5131a184 for
      SCTP code ("SCTP: lock_sock_nested in sctp_sock_migrate").
      
      Also note that this is isn't something that is seen normally,
      as it was uncovered with some experimental work-in-progress
      code not yet ready for mainline.  So no need for stable
      backports or similar of this commit.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      258f8667
    • Ying Xue's avatar
      tipc: eliminate connection setup for implied connect in recv_msg() · cbab3687
      Ying Xue authored
      As connection setup is now completed asynchronously in BH context,
      in the function filter_connect(), the corresponding code in recv_msg()
      becomes redundant.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      cbab3687
    • Ying Xue's avatar
      tipc: introduce non-blocking socket connect · 584d24b3
      Ying Xue authored
      TIPC has so far only supported blocking connect(), meaning that a call
      to connect() doesn't return until either the connection is fully
      established, or an error occurs. This has proved insufficient for many
      users, so we now introduce non-blocking connect(), analogous to how
      this is done in TCP and other protocols.
      
      With this feature, if a connection cannot be established instantly,
      connect() will return the error code "-EINPROGRESS".
      If the user later calls connect() again, he will either have the
      return code "-EALREADY" or "-EISCONN", depending on whether the
      connection has been established or not.
      
      The user must have explicitly set the socket to be non-blocking
      (SOCK_NONBLOCK or O_NONBLOCK, depending on method used), so unless
      for some reason they had set this already (the socket would anyway
      remain blocking in current TIPC) this change should be completely
      backwards compatible.
      
      It is also now possible to call select() or poll() to wait for the
      completion of a connection.
      
      An effect of the above is that the actual completion of a connection
      may now be performed asynchronously, independent of the calls from
      user space. Therefore, we now execute this code in BH context, in
      the function filter_rcv(), which is executed upon reception of
      messages in the socket.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      [PG: minor refactoring for improved connect/disconnect function names]
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      584d24b3
    • Ying Xue's avatar
      tipc: consolidate connection-oriented message reception in one function · 7e6c131e
      Ying Xue authored
      Handling of connection-related message reception is currently scattered
      around at different places in the code. This makes it harder to verify
      that things are handled correctly in all possible scenarios.
      So we consolidate the existing processing of connection-oriented
      message reception in a single routine.  In the process, we convert the
      chain of if/else into a switch/case for improved readability.
      
      A cast on the socket_state in the switch is needed to avoid compile
      warnings on 32 bit, like "net/tipc/socket.c:1252:2: warning: case value
      ‘4294967295’ not in enumerated type".  This happens because existing
      tipc code pseudo extends the default linux socket state values with:
      
      	#define SS_LISTENING    -1      /* socket is listening */
      	#define SS_READY        -2      /* socket is connectionless */
      
      It may make sense to add these as _positive_ values to the existing
      socket state enum list someday, vs. these already existing defines.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      [PG: add cast to fix warning; remove returns from middle of switch]
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      7e6c131e
    • Paul Gortmaker's avatar
      tipc: standardize across connect/disconnect function naming · bc879117
      Paul Gortmaker authored
      Currently we have tipc_disconnect and tipc_disconnect_port.  It is
      not clear from the names alone, what they do or how they differ.
      It turns out that tipc_disconnect just deals with the port locking
      and then calls tipc_disconnect_port which does all the work.
      
      If we rename as follows: tipc_disconnect_port --> __tipc_disconnect
      then we will be following typical linux convention, where:
      
         __tipc_disconnect: "raw" function that does all the work.
      
         tipc_disconnect: wrapper that deals with locking and then calls
      		    the real core __tipc_disconnect function
      
      With this, the difference is immediately evident, and locking
      violations are more apt to be spotted by chance while working on,
      or even just while reading the code.
      
      On the connect side of things, we currently only have the single
      "tipc_connect2port" function.  It does both the locking at enter/exit,
      and the core of the work.  Pending changes will make it desireable to
      have the connect be a two part locking wrapper + worker function,
      just like the disconnect is already.
      
      Here, we make the connect look just like the updated disconnect case,
      for the above reason, and for consistency.  In the process, we also
      get rid of the "2port" suffix that was on the original name, since
      it adds no descriptive value.
      
      On close examination, one might notice that the above connect
      changes implicitly move the call to tipc_link_get_max_pkt() to be
      within the scope of tipc_port_lock() protected region; when it was
      not previously.  We don't see any issues with this, and it is in
      keeping with __tipc_connect doing the work and tipc_connect just
      handling the locking.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      bc879117
    • Jon Maloy's avatar
      tipc: change sk_receive_queue upper limit · e643df15
      Jon Maloy authored
      The sk_recv_queue upper limit for connectionless sockets has empirically
      turned out to be too low. When we double the current limit we get much
      fewer rejected messages and no noticable negative side-effects.
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      e643df15
    • Ben Hutchings's avatar
      bonding: Fix check for ethtool get_link operation support · c772dde3
      Ben Hutchings authored
      Since commit 2c60db03 ('net: provide a default dev->ethtool_ops')
      all devices have a non-null ethtool_ops.  Test only
      dev->ethtool_ops->get_link in both places where we care.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c772dde3
    • Cong Wang's avatar
      bridge: export multicast database via netlink · ee07c6e7
      Cong Wang authored
      V5: fix two bugs pointed out by Thomas
          remove seq check for now, mark it as TODO
      
      V4: remove some useless #include
          some coding style fix
      
      V3: drop debugging printk's
          update selinux perm table as well
      
      V2: drop patch 1/2, export ifindex directly
          Redesign netlink attributes
          Improve netlink seq check
          Handle IPv6 addr as well
      
      This patch exports bridge multicast database via netlink
      message type RTM_GETMDB. Similar to fdb, but currently bridge-specific.
      We may need to support modify multicast database too (RTM_{ADD,DEL}MDB).
      
      (Thanks to Thomas for patient reviews)
      
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Stephen Hemminger <shemminger@vyatta.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Graf <tgraf@suug.ch>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee07c6e7
    • Shan Wei's avatar
      net: doc : use more suitable word 'unexpected' to replace 'secluded' · 5d248c49
      Shan Wei authored
       'secluded' is used to describe places, not suitable here.
      Suggested-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarShan Wei <davidshan@tencent.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d248c49
    • Patrick Trantham's avatar
      net: phy: smsc: Fix config_init typo · 4257d583
      Patrick Trantham authored
      Correct a mistake made in the previous commit due to reckless
      copy-and-pasting.
      Signed-off-by: default avatarPatrick Trantham <patrick.trantham@fuel7.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4257d583
    • Greg Kroah-Hartman's avatar
      drivers/net: fix up function prototypes after __dev* removals · 1dd06ae8
      Greg Kroah-Hartman authored
      The __dev* removal patches for the network drivers ended up messing up
      the function prototypes for a bunch of drivers.  This patch fixes all of
      them back up to be properly aligned.
      
      Bonus is that this almost removes 100 lines of code, always a nice
      surprise.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1dd06ae8
    • Ying Xue's avatar
      tipc: eliminate aggregate sk_receive_queue limit · 9da3d475
      Ying Xue authored
      As a complement to the per-socket sk_recv_queue limit, TIPC keeps a
      global atomic counter for the sum of sk_recv_queue sizes across all
      tipc sockets. When incremented, the counter is compared to an upper
      threshold value, and if this is reached, the message is rejected
      with error code TIPC_OVERLOAD.
      
      This check was originally meant to protect the node against
      buffer exhaustion and general CPU overload. However, all experience
      indicates that the feature not only is redundant on Linux, but even
      harmful. Users run into the limit very often, causing disturbances
      for their applications, while removing it seems to have no negative
      effects at all. We have also seen that overall performance is
      boosted significantly when this bottleneck is removed.
      
      Furthermore, we don't see any other network protocols maintaining
      such a mechanism, something strengthening our conviction that this
      control can be eliminated.
      
      As a result, the atomic variable tipc_queue_size is now unused
      and so it can be deleted.  There is a getsockopt call that used
      to allow reading it; we retain that but just return zero for
      maximum compatibility.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      [PG: phase out tipc_queue_size as pointed out by Neil Horman]
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      9da3d475
    • Thomas Graf's avatar
      sctp: Add RCU protection to assoc->transport_addr_list · 45122ca2
      Thomas Graf authored
      peer.transport_addr_list is currently only protected by sk_sock
      which is inpractical to acquire for procfs dumping purposes.
      
      This patch adds RCU protection allowing for the procfs readers to
      enter RCU read-side critical sections.
      
      Modification of the list continues to be serialized via sk_lock.
      
      V2: Use list_del_rcu() in sctp_association_free() to be safe
          Skip transports marked dead when dumping for procfs
      
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      45122ca2
    • Thomas Graf's avatar
      sctp: proc: protect bind_addr->address_list accesses with rcu_read_lock() · 0b0fe913
      Thomas Graf authored
      address_list is protected via the socket lock or RCU. Since we don't want
      to take the socket lock for each assoc we dump in procfs a RCU read-side
      critical section must be entered.
      
      V2: Skip local addresses marked as dead
      
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Acked-by: default avatarVlad Yasevich <vyasevic@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b0fe913
    • David S. Miller's avatar
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next · 36f0ffa5
      David S. Miller authored
      John W. Linville says:
      
      ====================
      This pull request is intended for 3.8...
      
      This includes a Bluetooth pull.  Gustavo says:
      
      "A few more patches to 3.8, I hope they can still make it to mainline!
      The most important ones are the socket option for the SCO protocol to allow
      accept/refuse new connections from userspace. Other than that I added some
      fixes and Andrei did more AMP work."
      
      Also, a mac80211 pull.  Johannes says:
      
      "If you think there's any chance this might make it still, please pull my
      mac80211-next tree (per below). This contains a relatively large number
      of fixes to the previous code, as well as a few small features:
       * VHT association in mac80211
       * some new debugfs files
       * P2P GO powersave configuration
       * masked MAC address verification
      
      The biggest patch is probably the BSS struct changes to use RCU for
      their IE buffers to fix potential races. I've not tagged this for stable
      because it's pretty invasive and nobody has ever seen any bugs in this
      area as far as I know."
      
      Several other drivers get some attention, including ath9k, brcmfmac,
      brcmsmac, and a number of others.  Also, Hauke gives us a series that
      improves watchdog support for the bcma and ssb busses.  Finally, Bill
      Pemberton delivers a group of "remove __dev* attributes" for wireless
      drivers -- these generate some "section mismatch" warnings, but Greg
      K-H assures me that they will disappear by the time -rc1 is released.
      
      This also includes a pull of the wireless tree to avoid merge
      conflicts.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      36f0ffa5
    • Paul Moore's avatar
      tun: correctly report an error in tun_flow_init() · b3943aef
      Paul Moore authored
      On error, the error code from tun_flow_init() is lost inside
      tun_set_iff(), this patch fixes this by assigning the tun_flow_init()
      error code to the "err" variable which is returned by
      the tun_flow_init() function on error.
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3943aef
    • John W. Linville's avatar
      Merge branch 'master' of... · 8024dc19
      John W. Linville authored
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
      8024dc19
    • David S. Miller's avatar
      Merge branch 'vhost-net-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost · b6d04864
      David S. Miller authored
      vhost changes for 3.8 from Michael S. Tsirkin
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6d04864
    • Christoph Paasch's avatar
      sctp: Fix compiler warning when CONFIG_DEBUG_SECTION_MISMATCH=y · f5f417c0
      Christoph Paasch authored
      WARNING: net/sctp/sctp.o(.text+0x72f1): Section mismatch in reference
      from the function sctp_net_init() to the function
      .init.text:sctp_proc_init()
      The function sctp_net_init() references
      the function __init sctp_proc_init().
      This is often because sctp_net_init lacks a __init
      annotation or the annotation of sctp_proc_init is wrong.
      
      And put __net_init after 'int' for sctp_proc_init - as it is done
      everywhere else in the sctp-stack.
      Signed-off-by: default avatarChristoph Paasch <christoph.paasch@uclouvain.be>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f5f417c0
    • Jan Glauber's avatar
      chelsio: remove get_clock and use ktime_get · fd3065b2
      Jan Glauber authored
      The get_clock() of the chelsio driver clashes with the s390 one.
      The chelsio helper reads a timespec via ktime just to convert it
      back to ktime. I can see no different outcome from calling
      ktime_get directly.
      
      Remove the get_clock and use ktime_get directly.
      Signed-off-by: default avatarJan Glauber <jang@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd3065b2
    • Barak Witkowski's avatar
      bnx2x: Prevent link flaps when booting from SAN. · c63da990
      Barak Witkowski authored
      It is possible that the driver is configured to operate with a certain
      link configuration which differs from the link's configuration during
      boot from SAN - this would cause the driver to flap the link.
      
      Said flap may be missed by specific switches, causing dcbx convergence
      to be too long and boot sequence to fail. Convergence is longer because
      switch ignores new dcbx packets due to counters mismatch, as only host
      side reset the counters due to the link flap.
      
      This patch causes the driver to ignore user's initial configuration during
      boot from SAN, and continues with the existing link configuration.
      Signed-off-by: default avatarBarak Witkowski <barak@broadcom.com>
      Signed-off-by: default avatarYuval Mintz <yuvalmin@broadcom.com>
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c63da990