1. 11 Apr, 2016 1 commit
  2. 24 Oct, 2015 1 commit
    • Jon Paul Maloy's avatar
      tipc: create broadcast transmission link at namespace init · 5fd9fd63
      Jon Paul Maloy authored
      
      
      The broadcast transmission link is currently instantiated when the
      network subsystem is started, i.e., on order from user space via netlink.
      
      This forces the broadcast transmission code to do unnecessary tests for
      the existence of the transmission link, as well in single mode node as
      in network mode.
      
      In this commit, we do instead create the link during initialization of
      the name space, and remove it when it is stopped. The fact that the
      transmission link now has a guaranteed longer life cycle than any of its
      potential clients paves the way for further code simplifcations
      and optimizations.
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5fd9fd63
  3. 04 May, 2015 1 commit
    • Ying Xue's avatar
      tipc: rename functions defined in subscr.c · 57f1d186
      Ying Xue authored
      
      
      When a topology server accepts a connection request from its client,
      it allocates a connection instance and a tipc_subscriber structure
      object. The former is used to communicate with client, and the latter
      is often treated as a subscriber which manages all subscription events
      requested from a same client. When a topology server receives a request
      of subscribing name services from a client through the connection, it
      creates a tipc_subscription structure instance which is seen as a
      subscription recording what name services are subscribed. In order to
      manage all subscriptions from a same client, topology server links
      them into the subscrp_list of the subscriber. So subscriber and
      subscription completely represents different meanings respectively,
      but function names associated with them make us so confused that we
      are unable to easily tell which function is against subscriber and
      which is to subscription. So we want to eliminate the confusion by
      renaming them.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Reviewed-by: default avatarJon Maloy <jon.maloy@ericson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      57f1d186
  4. 01 Apr, 2015 1 commit
    • Ying Xue's avatar
      tipc: fix a slab object leak · 7e436905
      Ying Xue authored
      When remove TIPC module, there is a warning to remind us that a slab
      object is leaked like:
      
      root@localhost:~# rmmod tipc
      [   19.056226] =============================================================================
      [   19.057549] BUG TIPC (Not tainted): Objects remaining in TIPC on kmem_cache_close()
      [   19.058736] -----------------------------------------------------------------------------
      [   19.058736]
      [   19.060287] INFO: Slab 0xffffea0000519a00 objects=23 used=1 fp=0xffff880014668b00 flags=0x100000000004080
      [   19.061915] INFO: Object 0xffff880014668000 @offset=0
      [   19.062717] kmem_cache_destroy TIPC: Slab cache still has objects
      
      This is because the listening socket of TIPC topology server is not
      closed before TIPC proto handler is unregistered with proto_unregister().
      However, as the socket is closed in tipc_exit_net() which is called by
      unregister_pernet_subsys() during unregistering TIPC namespace operation,
      the warning can be eliminated if calling unregister_pernet_subsys() is
      moved before calling proto_unregister().
      
      Fixes: e05b31f4
      
       ("tipc: make tipc socket support net namespace")
      Reviewed-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e436905
  5. 09 Feb, 2015 2 commits
  6. 12 Jan, 2015 9 commits
  7. 09 Jan, 2015 1 commit
    • Ying Xue's avatar
      tipc: convert tipc reference table to use generic rhashtable · 07f6c4bc
      Ying Xue authored
      
      
      As tipc reference table is statically allocated, its memory size
      requested on stack initialization stage is quite big even if the
      maximum port number is just restricted to 8191 currently, however,
      the number already becomes insufficient in practice. But if the
      maximum ports is allowed to its theory value - 2^32, its consumed
      memory size will reach a ridiculously unacceptable value. Apart from
      this, heavy tipc users spend a considerable amount of time in
      tipc_sk_get() due to the read-lock on ref_table_lock.
      
      If tipc reference table is converted with generic rhashtable, above
      mentioned both disadvantages would be resolved respectively: making
      use of the new resizable hash table can avoid locking on the lookup;
      smaller memory size is required at initial stage, for example, 256
      hash bucket slots are requested at the beginning phase instead of
      allocating the entire 8191 slots in old mode. The hash table will
      grow if entries exceeds 75% of table size up to a total table size
      of 1M, and it will automatically shrink if usage falls below 30%,
      but the minimum table size is allowed down to 256.
      
      Also converts ref_table_lock to a separate mutex to protect hash table
      mutations on write side. Lastly defers the release of the socket
      reference using call_rcu() to allow using an RCU read-side protected
      call to rhashtable_lookup().
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Acked-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Cc: Thomas Graf <tgraf@suug.ch>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07f6c4bc
  8. 23 Aug, 2014 2 commits
  9. 14 May, 2014 1 commit
    • Jon Paul Maloy's avatar
      tipc: decrease connection flow control window · 6163a194
      Jon Paul Maloy authored
      
      
      Memory overhead when allocating big buffers for data transfer may
      be quite significant. E.g., truesize of a 64 KB buffer turns out
      to be 132 KB, 2 x the requested size.
      
      This invalidates the "worst case" calculation we have been
      using to determine the default socket receive buffer limit,
      which is based on the assumption that 1024x64KB = 67MB buffers
      may be queued up on a socket.
      
      Since TIPC connections cannot survive hitting the buffer limit,
      we have to compensate for this overhead.
      
      We do that in this commit by dividing the fix connection flow
      control window from 1024 (2*512) messages to 512 (2*256). Since
      older version nodes send out acks at 512 message intervals,
      compatibility with such nodes is guaranteed, although performance
      may be non-optimal in such cases.
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6163a194
  10. 05 May, 2014 1 commit
  11. 27 Mar, 2014 1 commit
  12. 22 Feb, 2014 2 commits
    • Ying Xue's avatar
      tipc: make bearer set up in module insertion stage · 970122fd
      Ying Xue authored
      Accidentally a side effect is involved by commit 6e967adf
      
      (tipc:
      relocate common functions from media to bearer). Now tipc stack
      handler of receiving packets from netdevices as well as netdevice
      notification handler are registered when bearer is enabled rather
      than tipc module initialization stage, but the two handlers are
      both unregistered in tipc module exit phase. If tipc module is
      inserted and then immediately removed, the following warning
      message will appear:
      
      "dev_remove_pack: ffffffffa0380940 not found"
      
      This is because in module insertion stage tipc stack packet handler
      is not registered at all, but in module exit phase dev_remove_pack()
      needs to remove it. Of course, dev_remove_pack() cannot find tipc
      protocol handler from the kernel protocol handler list so that the
      warning message is printed out.
      
      But if registering the two handlers is adjusted from enabling bearer
      phase into inserting module stage, the warning message will be
      eliminated. Due to this change, tipc_core_start_net() and
      tipc_core_stop_net() can be deleted as well.
      Reported-by: default avatarWang Weidong <wangweidong1@huawei.com>
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      Cc: Erik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Reviewed-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      970122fd
    • Ying Xue's avatar
      tipc: remove all enabled flags from all tipc components · 9fe7ed47
      Ying Xue authored
      
      
      When tipc module is inserted, many tipc components are initialized
      one by one. During the initialization period, if one of them is
      failed, tipc_core_stop() will be called to stop all components
      whatever corresponding components are created or not. To avoid to
      release uncreated ones, relevant components have to add necessary
      enabled flags indicating whether they are created or not.
      
      But in the initialization stage, if one component is unsuccessfully
      created, we will just destroy successfully created components before
      the failed component instead of all components. All enabled flags
      defined in components, in turn, become redundant. Additionally it's
      also unnecessary to identify whether table.types is NULL in
      tipc_nametbl_stop() because name stable has been definitely created
      successfully when tipc_nametbl_stop() is called.
      
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      Cc: Erik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Reviewed-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9fe7ed47
  13. 13 Feb, 2014 1 commit
    • Ying Xue's avatar
      tipc: remove 'links' list from tipc_bearer struct · c61dd61d
      Ying Xue authored
      
      
      In our ongoing effort to simplify the TIPC locking structure,
      we see a need to remove the linked list for tipc_links
      in the bearer. This can be explained as follows.
      
      Currently, we have three different ways to access a link,
      via three different lists/tables:
      
      1: Via a node hash table:
         Used by the time-critical outgoing/incoming data paths.
         (e.g. link_send_sections_fast() and tipc_recv_msg() ):
      
      grab net_lock(read)
         find node from node hash table
         grab node_lock
             select link
             grab bearer_lock
                send_msg()
             release bearer_lock
         release node lock
      release net_lock
      
      2: Via a global linked list for nodes:
         Used by configuration commands (link_cmd_set_value())
      
      grab net_lock(read)
         find node and link from global node list (using link name)
         grab node_lock
             update link
         release node lock
      release net_lock
      
      (Same locking order as above. No problem.)
      
      3: Via the bearer's linked link list:
         Used by notifications from interface (e.g. tipc_disable_bearer() )
      
      grab net_lock(write)
         grab bearer_lock
            get link ptr from bearer's link list
            get node from link
            grab node_lock
               delete link
            release node lock
         release bearer_lock
      release net_lock
      
      (Different order from above, but works because we grab the
      outer net_lock in write mode first, excluding all other access.)
      
      The first major goal in our simplification effort is to get rid
      of the "big" net_lock, replacing it with rcu-locks when accessing
      the node list and node hash array. This will come in a later patch
      series.
      
      But to get there we first need to rewrite access methods ##2 and 3,
      since removal of net_lock would introduce three major problems:
      
      a) In access method #2, we access the link before taking the
         protecting node_lock. This will not work once net_lock is gone,
         so we will have to change the access order. We will deal with
         this in a later commit in this series, "tipc: add node lock
         protection to link found by link_find_link()".
      
      b) When the outer protection from net_lock is gone, taking
         bearer_lock and node_lock in opposite order of method 1) and 2)
         will become an obvious deadlock hazard. This is fixed in the
         commit ("tipc: remove bearer_lock from tipc_bearer struct")
         later in this series.
      
      c) Similar to what is described in problem a), access method #3
         starts with using a link pointer that is unprotected by node_lock,
         in order to via that pointer find the correct node struct and
         lock it. Before we remove net_lock, this access order must be
         altered. This is what we do with this commit.
      
      We can avoid introducing problem problem c) by even here using the
      global node list to find the node, before accessing its links. When
      we loop though the node list we use the own bearer identity as search
      criteria, thus easily finding the links that are associated to the
      resetting/disabling bearer. It should be noted that although this
      method is somewhat slower than the current list traversal, it is in
      no way time critical. This is only about resetting or deleting links,
      something that must be considered relatively infrequent events.
      
      As a bonus, we can get rid of the mutual pointers between links and
      bearers. After this commit, pointer dependency go in one direction
      only: from the link to the bearer.
      
      This commit pre-empts introduction of problem c) as described above.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Reviewed-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c61dd61d
  14. 11 Dec, 2013 2 commits
    • Ying Xue's avatar
      tipc: relocate common functions from media to bearer · 6e967adf
      Ying Xue authored
      
      
      Currently, registering a TIPC stack handler in the network device layer
      is done twice, once for Ethernet (eth_media) and Infiniband (ib_media)
      repectively. But, as this registration is not media specific, we can
      avoid some code duplication by moving the registering function to
      the generic bearer layer, to the file bearer.c, and call it only once.
      The same is true for the network device event notifier.
      
      As a side effect, the two workqueues we are using for for setting up/
      cleaning up media can now be eliminated. Furthermore, the array for
      storing the specific media type structs, media_array[], can be entirely
      deleted.
      
      Note that the eth_started and ib_started flags were removed during the
      code relocation.  There is now only one call to bearer_setup and
      bearer_cleanup, and these can logically not race against each other.
      
      Despite its size, this cleanup work incurs no functional changes in TIPC.
      In particular, it should be noted that the sequence ordering of received
      packets is unaffected by this change, since packet reception never was
      subject to any work queue handling in the first place.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e967adf
    • Jon Paul Maloy's avatar
      tipc: correct the order of stopping services at rmmod · 993b858e
      Jon Paul Maloy authored
      
      
      The 'signal handler' service in TIPC is a mechanism that makes it
      possible to postpone execution of functions, by launcing them into
      a job queue for execution in a separate tasklet, independent of
      the launching execution thread.
      
      When we do rmmod on the tipc module, this service is stopped after
      the network service. At the same time, the stopping of the network
      service may itself launch jobs for execution, with the risk that these
      functions may be scheduled for execution after the data structures
      meant to be accessed by the job have already been deleted. We have
      seen this happen, most often resulting in an oops.
      
      This commit ensures that the signal handler is the very first to be
      stopped when TIPC is shut down, so there are no surprises during
      the cleanup of the other services.
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      993b858e
  15. 17 Jun, 2013 3 commits
    • Ying Xue's avatar
      tipc: convert configuration server to use new server facility · 7d0ab17b
      Ying Xue authored
      
      
      As the new socket-based TIPC server infrastructure has been
      introduced, we can now convert the configuration server to use
      it.  Then we can take future steps to simplify the configuration
      server locking policy.
      
      Some minor reordering of initialization is done, due to the
      dependency on having tipc_socket_init completed.
      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>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7d0ab17b
    • Ying Xue's avatar
      tipc: convert topology server to use new server facility · 13a2e898
      Ying Xue authored
      
      
      As the new TIPC server infrastructure has been introduced, we can
      now convert the TIPC topology server to it.  We get two benefits
      from doing this:
      
      1) It simplifies the topology server locking policy.  In the
      original locking policy, we placed one spin lock pointer in the
      tipc_subscriber structure to reuse the lock of the subscriber's
      server port, controlling access to members of tipc_subscriber
      instance.  That is, we only used one lock to ensure both
      tipc_port and tipc_subscriber members were safely accessed.
      
      Now we introduce another spin lock for tipc_subscriber structure
      only protecting themselves, to get a finer granularity locking
      policy.  Moreover, the change will allow us to make the topology
      server code more readable and maintainable.
      
      2) It fixes a bug where sent subscription events may be lost when
      the topology port is congested.  Using the new service, the
      topology server now queues sent events into an outgoing buffer,
      and then wakes up a sender process which has been blocked in
      workqueue context.  The process will keep picking events from the
      buffer and send them to their respective subscribers, using the
      kernel socket interface, until the buffer is empty. Even if the
      socket is congested during transmission there is no risk that
      events may be dropped, since the sender process may block when
      needed.
      
      Some minor reordering of initialization is done, since we now
      have a scenario where the topology server must be started after
      socket initialization has taken place, as the former depends
      on the latter.  And overall, we see a simplification of the
      TIPC subscriber code in making this changeover.
      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>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13a2e898
    • Ying Xue's avatar
      tipc: change socket buffer overflow control to respect sk_rcvbuf · cc79dd1b
      Ying Xue authored
      
      
      As per feedback from the netdev community, we change the buffer
      overflow protection algorithm in receiving sockets so that it
      always respects the nominal upper limit set in sk_rcvbuf.
      
      Instead of scaling up from a small sk_rcvbuf value, which leads to
      violation of the configured sk_rcvbuf limit, we now calculate the
      weighted per-message limit by scaling down from a much bigger value,
      still in the same field, according to the importance priority of the
      received message.
      
      To allow for administrative tunability of the socket receive buffer
      size, we create a tipc_rmem sysctl variable to allow the user to
      configure an even bigger value via sysctl command.  It is a size of
      three (min/default/max) to be consistent with things like tcp_rmem.
      
      By default, the value initialized in tipc_rmem[1] is equal to the
      receive socket size needed by a TIPC_CRITICAL_IMPORTANCE message.
      This value is also set as the default value of sk_rcvbuf.
      Originally-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      [Ying: added sysctl variation to Jon's original patch]
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      [PG: don't compile sysctl.c if not config'd; add Documentation]
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc79dd1b
  16. 17 Apr, 2013 1 commit
    • Patrick McHardy's avatar
      tipc: add InfiniBand media type · a29a194a
      Patrick McHardy authored
      
      
      Add InfiniBand media type based on the ethernet media type.
      
      The only real difference is that in case of InfiniBand, we need the entire
      20 bytes of space reserved for media addresses, so the TIPC media type ID is
      not explicitly stored in the packet payload.
      
      Sample output of tipc-config:
      
      # tipc-config -v -addr -netid -nt=all -p -m -b -n -ls
      
      node address: <10.1.4>
      current network id: 4711
      Type       Lower      Upper      Port Identity              Publication Scope
      0          167776257  167776257  <10.1.1:1855512577>        1855512578  cluster
                 167776260  167776260  <10.1.4:1216454657>        1216454658  zone
      1          1          1          <10.1.4:1216479235>        1216479236  node
      Ports:
      1216479235: bound to {1,1}
      1216454657: bound to {0,167776260}
      Media:
      eth
      ib
      Bearers:
      ib:ib0
      Nodes known:
      <10.1.1>: up
      Link <broadcast-link>
        Window:20 packets
        RX packets:0 fragments:0/0 bundles:0/0
        TX packets:0 fragments:0/0 bundles:0/0
        RX naks:0 defs:0 dups:0
        TX naks:0 acks:0 dups:0
        Congestion bearer:0 link:0  Send queue max:0 avg:0
      
      Link <10.1.4:ib0-10.1.1:ib0>
        ACTIVE  MTU:2044  Priority:10  Tolerance:1500 ms  Window:50 packets
        RX packets:80 fragments:0/0 bundles:0/0
        TX packets:40 fragments:0/0 bundles:0/0
        TX profile sample:22 packets  average:54 octets
        0-64:100% -256:0% -1024:0% -4096:0% -16384:0% -32768:0% -66000:0%
        RX states:410 probes:213 naks:0 defs:0 dups:0
        TX states:410 probes:197 naks:0 acks:0 dups:0
        Congestion bearer:0 link:0  Send queue max:1 avg:0
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a29a194a
  17. 22 Nov, 2012 1 commit
    • Paul Gortmaker's avatar
      tipc: delete TIPC_ADVANCED Kconfig variable · 94fc9c47
      Paul Gortmaker authored
      
      
      There used to be a time when TIPC had lots of Kconfig knobs the
      end user could alter, but they have all been made automatic or
      obsolete, with the exception of CONFIG_TIPC_PORTS.  This
      previously existing set of options was all hidden under the
      TIPC_ADVANCED setting, which does not exist in any code, but
      only in Kconfig scope.
      
      Having this now, just to hide the one remaining "advanced"
      option no longer makes sense.  Remove it.  Also get rid of the
      ifdeffery in the TIPC code that allowed for TIPC_PORTS to be
      possibly undefined.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      94fc9c47
  18. 20 Aug, 2012 5 commits
  19. 13 Jul, 2012 2 commits
  20. 30 Apr, 2012 1 commit
    • Paul Gortmaker's avatar
      tipc: compress out gratuitous extra carriage returns · 617d3c7a
      Paul Gortmaker authored
      
      
      Some of the comment blocks are floating in limbo between two
      functions, or between blocks of code.  Delete the extra line
      feeds between any comment and its associated following block
      of code, to be consistent with the majority of the rest of
      the kernel.  Also delete trailing newlines at EOF and fix
      a couple trivial typos in existing comments.
      
      This is a 100% cosmetic change with no runtime impact.  We get
      rid of over 500 lines of non-code, and being blank line deletes,
      they won't even show up as noise in git blame.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      617d3c7a
  21. 26 Apr, 2012 1 commit