1. 06 Feb, 2015 16 commits
    • Lad, Prabhakar's avatar
      net: bnx2x: fix sparse warnings · 1444c301
      Lad, Prabhakar authored
      this patch fixes following sparse warnings:
      
      bnx2x_main.c:9172:6: warning: symbol 'bnx2x_stop_ptp' was not declared. Should it be static?
      bnx2x_main.c:13321:6: warning: symbol 'bnx2x_register_phc' was not declared. Should it be static?
      bnx2x_main.c:14638:5: warning: symbol 'bnx2x_enable_ptp_packets' was not declared. Should it be static?
      Signed-off-by: default avatarLad, Prabhakar <prabhakar.csengg@gmail.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1444c301
    • Lad, Prabhakar's avatar
      enic: enic_main: fix sparse warnings · 57ae84a0
      Lad, Prabhakar authored
      this patch fixes following sparse warnings:
      
      enic_main.c:92:28: warning: symbol 'mod_table' was not declared. Should it be static?
      enic_main.c:109:28: warning: symbol 'mod_range' was not declared. Should it be static?
      enic_main.c:1306:5: warning: symbol 'enic_busy_poll' was not declared. Should it be static?
      Signed-off-by: default avatarLad, Prabhakar <prabhakar.csengg@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      57ae84a0
    • Lad, Prabhakar's avatar
      enic: enic_ethtool: fix sparse warning · a20667bf
      Lad, Prabhakar authored
      this patch fixes following sparse warning:
      
      enic_ethtool.c:95:6: warning: symbol 'enic_intr_coal_set_rx' was not declared. Should it be static?
      Signed-off-by: default avatarLad, Prabhakar <prabhakar.csengg@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a20667bf
    • Lad, Prabhakar's avatar
      be2net: fix sparse warning · bc0ee163
      Lad, Prabhakar authored
      this patch fixes following sparse warning:
      
      be_cmds.c:2750:5: warning: symbol 'be_cmd_set_qos' was not declared. Should it be static?
      Signed-off-by: default avatarLad, Prabhakar <prabhakar.csengg@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc0ee163
    • Lad, Prabhakar's avatar
      chelsio: cxgb4: fix sparse warning · 4a95b6d0
      Lad, Prabhakar authored
      this patch fixes following sparse warning:
      
      cxgb4_dcb.c:25:6: warning: symbol 'dcb_ver_array' was not declared. Should it be static?
      
      Alongside making it const.
      Signed-off-by: default avatarLad, Prabhakar <prabhakar.csengg@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a95b6d0
    • Lad, Prabhakar's avatar
      hyperv: fix sparse warnings · da19fcd0
      Lad, Prabhakar authored
      this patch fixes following sparse warnings:
      
      netvsc.c:688:5: warning: symbol 'netvsc_copy_to_send_buf' was not declared. Should it be static?
      rndis_filter.c:627:5: warning: symbol 'rndis_filter_set_offload_params' was not declared. Should it be static?
      rndis_filter.c:702:5: warning: symbol 'rndis_filter_set_rss_param' was not declared. Should it be static?
      Signed-off-by: default avatarLad, Prabhakar <prabhakar.csengg@gmail.com>
      Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      da19fcd0
    • David S. Miller's avatar
      Merge branch 'tipc-next' · 7d231e3f
      David S. Miller authored
      Jon Maloy says:
      
      ====================
      tipc: resolve message disordering problem
      
      When TIPC receives messages from multi-threaded device drivers it may
      occasionally deliver messages to their destination sockets in the wrong
      order. This happens despite correct resequencing at the link layer,
      because the upcall path from link to socket is not protected by any
      locks.
      
      These commits solve this problem by introducing an 'input' message
      queue in each link, through which messages must be delivered to the
      upper layers.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7d231e3f
    • Jon Paul Maloy's avatar
      tipc: eliminate race condition at multicast reception · cb1b7280
      Jon Paul Maloy authored
      In a previous commit in this series we resolved a race problem during
      unicast message reception.
      
      Here, we resolve the same problem at multicast reception. We apply the
      same technique: an input queue serializing the delivery of arriving
      buffers. The main difference is that here we do it in two steps.
      First, the broadcast link feeds arriving buffers into the tail of an
      arrival queue, which head is consumed at the socket level, and where
      destination lookup is performed. Second, if the lookup is successful,
      the resulting buffer clones are fed into a second queue, the input
      queue. This queue is consumed at reception in the socket just like
      in the unicast case. Both queues are protected by the same lock, -the
      one of the input queue.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb1b7280
    • Jon Paul Maloy's avatar
      tipc: simplify socket multicast reception · 3c724acd
      Jon Paul Maloy authored
      The structure 'tipc_port_list' is used to collect port numbers
      representing multicast destination socket on a receiving node.
      The list is not based on a standard linked list, and is in reality
      optimized for the uncommon case that there are more than one
      multicast destinations per node. This makes the list handling
      unecessarily complex, and as a consequence, even the socket
      multicast reception becomes more complex.
      
      In this commit, we replace 'tipc_port_list' with a new 'struct
      tipc_plist', which is based on a standard list. We give the new
      list stack (push/pop) semantics, someting that simplifies
      the implementation of the function tipc_sk_mcast_rcv().
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c724acd
    • Jon Paul Maloy's avatar
      tipc: simplify connection abort notifications when links break · 708ac32c
      Jon Paul Maloy authored
      The new input message queue in struct tipc_link can be used for
      delivering connection abort messages to subscribing sockets. This
      makes it possible to simplify the code for such cases.
      
      This commit removes the temporary list in tipc_node_unlock()
      used for transforming abort subscriptions to messages. Instead, the
      abort messages are now created at the moment of lost contact, and
      then added to the last failed link's generic input queue for delivery
      to the sockets concerned.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      708ac32c
    • Jon Paul Maloy's avatar
      tipc: resolve race problem at unicast message reception · c637c103
      Jon Paul Maloy authored
      TIPC handles message cardinality and sequencing at the link layer,
      before passing messages upwards to the destination sockets. During the
      upcall from link to socket no locks are held. It is therefore possible,
      and we see it happen occasionally, that messages arriving in different
      threads and delivered in sequence still bypass each other before they
      reach the destination socket. This must not happen, since it violates
      the sequentiality guarantee.
      
      We solve this by adding a new input buffer queue to the link structure.
      Arriving messages are added safely to the tail of that queue by the
      link, while the head of the queue is consumed, also safely, by the
      receiving socket. Sequentiality is secured per socket by only allowing
      buffers to be dequeued inside the socket lock. Since there may be multiple
      simultaneous readers of the queue, we use a 'filter' parameter to reduce
      the risk that they peek the same buffer from the queue, hence also
      reducing the risk of contention on the receiving socket locks.
      
      This solves the sequentiality problem, and seems to cause no measurable
      performance degradation.
      
      A nice side effect of this change is that lock handling in the functions
      tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that
      will enable future simplifications of those functions.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c637c103
    • Jon Paul Maloy's avatar
      tipc: use existing sk_write_queue for outgoing packet chain · 94153e36
      Jon Paul Maloy authored
      The list for outgoing traffic buffers from a socket is currently
      allocated on the stack. This forces us to initialize the queue for
      each sent message, something costing extra CPU cycles in the most
      critical data path. Later in this series we will introduce a new
      safe input buffer queue, something that would force us to initialize
      even the spinlock of the outgoing queue. A closer analysis reveals
      that the queue always is filled and emptied within the same lock_sock()
      session. It is therefore safe to use a queue aggregated in the socket
      itself for this purpose. Since there already exists a queue for this
      in struct sock, sk_write_queue, we introduce use of that queue in
      this commit.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      94153e36
    • Jon Paul Maloy's avatar
      tipc: split up function tipc_msg_eval() · e3a77561
      Jon Paul Maloy authored
      The function tipc_msg_eval() is in reality doing two related, but
      different tasks. First it tries to find a new destination for named
      messages, in case there was no first lookup, or if the first lookup
      failed. Second, it does what its name suggests, evaluating the validity
      of the message and its destination, and returning an appropriate error
      code depending on the result.
      
      This is confusing, and in this commit we choose to break it up into two
      functions. A new function, tipc_msg_lookup_dest(), first attempts to find
      a new destination, if the message is of the right type. If this lookup
      fails, or if the message should not be subject to a second lookup, the
      already existing tipc_msg_reverse() is called. This function performs
      prepares the message for rejection, if applicable.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3a77561
    • Jon Paul Maloy's avatar
      tipc: enqueue arrived buffers in socket in separate function · d570d864
      Jon Paul Maloy authored
      The code for enqueuing arriving buffers in the function tipc_sk_rcv()
      contains long code lines and currently goes to two indentation levels.
      As a cosmetic preparaton for the next commits, we break it out into
      a separate function.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d570d864
    • Jon Paul Maloy's avatar
      tipc: simplify message forwarding and rejection in socket layer · 1186adf7
      Jon Paul Maloy authored
      Despite recent improvements, the handling of error codes and return
      values at reception of messages in the socket layer is still confusing.
      
      In this commit, we try to make it more comprehensible. First, we
      separate between the return values coming from the functions called
      by tipc_sk_rcv(), -those are TIPC specific error codes, and the
      return values returned by tipc_sk_rcv() itself. Second, we don't
      use the returned TIPC error code as indication for whether a buffer
      should be forwarded/rejected or not; instead we use the buffer pointer
      passed along with filter_msg(). This separation is necessary because
      we sometimes want to forward messages even when there is no error
      (i.e., protocol messages and successfully secondary looked up data
      messages).
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1186adf7
    • Jon Paul Maloy's avatar
      tipc: reduce usage of context info in socket and link · c5898636
      Jon Paul Maloy authored
      The most common usage of namespace information is when we fetch the
      own node addess from the net structure. This leads to a lot of
      passing around of a parameter of type 'struct net *' between
      functions just to make them able to obtain this address.
      
      However, in many cases this is unnecessary. The own node address
      is readily available as a member of both struct tipc_sock and
      tipc_link, and can be fetched from there instead.
      The fact that the vast majority of functions in socket.c and link.c
      anyway are maintaining a pointer to their respective base structures
      makes this option even more compelling.
      
      In this commit, we introduce the inline functions tsk_own_node()
      and link_own_node() to make it easy for functions to fetch the node
      address from those structs instead of having to pass along and
      dereference the namespace struct.
      
      In particular, we make calls to the msg_xx() functions in msg.{h,c}
      context independent by directly passing them the own node address
      as parameter when needed. Those functions should be regarded as
      leaves in the code dependency tree, and it is hence desirable to
      keep them namspace unaware.
      
      Apart from a potential positive effect on cache behavior, these
      changes make it easier to introduce the changes that will follow
      later in this series.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5898636
  2. 05 Feb, 2015 24 commits