An error occurred fetching the project authors.
  1. 11 Dec, 2013 3 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
    • Ying Xue's avatar
      tipc: remove TIPC usage of field af_packet_priv in struct net_device · 37cb0620
      Ying Xue authored
      TIPC is currently using the field 'af_packet_priv' in struct net_device
      as a handle to find the bearer instance associated to the given network
      device. But, by doing so it is blocking other networking cleanups, such
      as the one discussed here:
      
      http://patchwork.ozlabs.org/patch/178044/
      
      This commit removes this usage from TIPC. Instead, we introduce a new
      field, 'tipc_ptr', to the net_device structure, to serve this purpose.
      When TIPC bearer is enabled, the bearer object is associated to
      'tipc_ptr'. When a TIPC packet arrives in the recv_msg() upcall
      from a networking device, the bearer object can now be obtained from
      'tipc_ptr'. When a bearer is disabled, the bearer object is detached
      from its underlying network device by setting 'tipc_ptr' to NULL.
      
      Additionally, an RCU lock is used to protect the new pointer.
      Henceforth, the existing tipc_net_lock is used in write mode to
      serialize write accesses to this pointer, while the new RCU lock is
      applied on the read side to ensure that the pointer is 100% valid
      within its wrapped area for all readers.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Cc: Patrick McHardy <kaber@trash.net>
      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>
      37cb0620
    • Jon Paul Maloy's avatar
      tipc: initiate media type array at compile time · 5702dbab
      Jon Paul Maloy authored
      Communication media types are abstracted through the struct 'tipc_media',
      one per media type. These structs are allocated statically inside their
      respective media file.
      
      Furthermore, in order to be able to reach all instances from a central
      location, we keep a static array with pointers to these structs. This
      array is currently initialized at runtime, under protection of
      tipc_net_lock. However, since the contents of the array itself never
      changes after initialization, we can just as well initialize it at
      compile time and make it 'const', at the same time making it obvious
      that no lock protection is needed here.
      
      This commit makes the array constant and removes the redundant lock
      protection.
      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>
      5702dbab
  2. 10 Dec, 2013 1 commit
    • Erik Hugne's avatar
      tipc: remove interface state mirroring in bearer · 512137ee
      Erik Hugne authored
      struct 'tipc_bearer' is a generic representation of the underlying
      media type, and exists in a one-to-one relationship to each interface
      TIPC is using. The struct contains a 'blocked' flag that mirrors the
      operational and execution state of the represented interface, and is
      updated through notification calls from the latter. The users of
      tipc_bearer are checking this flag before each attempt to send a
      packet via the interface.
      
      This state mirroring serves no purpose in the current code base. TIPC
      links will not discover a media failure any faster through this
      mechanism, and in reality the flag only adds overhead at packet
      sending and reception.
      
      Furthermore, the fact that the flag needs to be protected by a spinlock
      aggregated into tipc_bearer has turned out to cause a serious and
      completely unnecessary deadlock problem.
      
      CPU0                                    CPU1
      ----                                    ----
      Time 0: bearer_disable()                link_timeout()
      Time 1:   spin_lock_bh(&b_ptr->lock)      tipc_link_push_queue()
      Time 2:   tipc_link_delete()                tipc_bearer_blocked(b_ptr)
      Time 3:     k_cancel_timer(&req->timer)       spin_lock_bh(&b_ptr->lock)
      Time 4:       del_timer_sync(&req->timer)
      
      I.e., del_timer_sync() on CPU0 never returns, because the timer handler
      on CPU1 is waiting for the bearer lock.
      
      We eliminate the 'blocked' flag from struct tipc_bearer, along with all
      tests on this flag. This not only resolves the deadlock, but also
      simplifies and speeds up the data path execution of TIPC. It also fits
      well into our ongoing effort to make the locking policy simpler and
      more manageable.
      
      An effect of this change is that we can get rid of functions such as
      tipc_bearer_blocked(), tipc_continue() and tipc_block_bearer().
      We replace the latter with a new function, tipc_reset_bearer(), which
      resets all links associated to the bearer immediately after an
      interface goes down.
      
      A user might notice one slight change in link behaviour after this
      change. When an interface goes down, (e.g. through a NETDEV_DOWN
      event) all attached links will be reset immediately, instead of
      leaving it to each link to detect the failure through a timer-driven
      mechanism. We consider this an improvement, and see no obvious risks
      with the new behavior.
      Signed-off-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Reviewed-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>
      512137ee
  3. 18 Oct, 2013 3 commits
  4. 17 Jun, 2013 2 commits
  5. 28 May, 2013 1 commit
  6. 17 Apr, 2013 3 commits
  7. 20 Aug, 2012 2 commits
    • Ying Xue's avatar
      tipc: fix lockdep warning during bearer initialization · 4225a398
      Ying Xue authored
      When the lockdep validator is enabled, it will report the below
      warning when we enable a TIPC bearer:
      
      [ INFO: possible irq lock inversion dependency detected ]
      ---------------------------------------------------------
      Possible interrupt unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(ptype_lock);
                                      local_irq_disable();
                                      lock(tipc_net_lock);
                                      lock(ptype_lock);
         <Interrupt>
         lock(tipc_net_lock);
      
        *** DEADLOCK ***
      
      the shortest dependencies between 2nd lock and 1st lock:
        -> (ptype_lock){+.+...} ops: 10 {
      [...]
      SOFTIRQ-ON-W at:
                            [<c1089418>] __lock_acquire+0x528/0x13e0
                            [<c108a360>] lock_acquire+0x90/0x100
                            [<c1553c38>] _raw_spin_lock+0x38/0x50
                            [<c14651ca>] dev_add_pack+0x3a/0x60
                            [<c182da75>] arp_init+0x1a/0x48
                            [<c182dce5>] inet_init+0x181/0x27e
                            [<c1001114>] do_one_initcall+0x34/0x170
                            [<c17f7329>] kernel_init+0x110/0x1b2
                            [<c155b6a2>] kernel_thread_helper+0x6/0x10
      [...]
         ... key      at: [<c17e4b10>] ptype_lock+0x10/0x20
         ... acquired at:
          [<c108a360>] lock_acquire+0x90/0x100
          [<c1553c38>] _raw_spin_lock+0x38/0x50
          [<c14651ca>] dev_add_pack+0x3a/0x60
          [<c8bc18d2>] enable_bearer+0xf2/0x140 [tipc]
          [<c8bb283a>] tipc_enable_bearer+0x1ba/0x450 [tipc]
          [<c8bb3a04>] tipc_cfg_do_cmd+0x5c4/0x830 [tipc]
          [<c8bbc032>] handle_cmd+0x42/0xd0 [tipc]
          [<c148e802>] genl_rcv_msg+0x232/0x280
          [<c148d3f6>] netlink_rcv_skb+0x86/0xb0
          [<c148e5bc>] genl_rcv+0x1c/0x30
          [<c148d144>] netlink_unicast+0x174/0x1f0
          [<c148ddab>] netlink_sendmsg+0x1eb/0x2d0
          [<c1456bc1>] sock_aio_write+0x161/0x170
          [<c1135a7c>] do_sync_write+0xac/0xf0
          [<c11360f6>] vfs_write+0x156/0x170
          [<c11361e2>] sys_write+0x42/0x70
          [<c155b0df>] sysenter_do_call+0x12/0x38
      [...]
      }
        -> (tipc_net_lock){+..-..} ops: 4 {
      [...]
          IN-SOFTIRQ-R at:
                           [<c108953a>] __lock_acquire+0x64a/0x13e0
                           [<c108a360>] lock_acquire+0x90/0x100
                           [<c15541cd>] _raw_read_lock_bh+0x3d/0x50
                           [<c8bb874d>] tipc_recv_msg+0x1d/0x830 [tipc]
                           [<c8bc195f>] recv_msg+0x3f/0x50 [tipc]
                           [<c146a5fa>] __netif_receive_skb+0x22a/0x590
                           [<c146ab0b>] netif_receive_skb+0x2b/0xf0
                           [<c13c43d2>] pcnet32_poll+0x292/0x780
                           [<c146b00a>] net_rx_action+0xfa/0x1e0
                           [<c103a4be>] __do_softirq+0xae/0x1e0
      [...]
      }
      
      >From the log, we can see three different call chains between
      CPU0 and CPU1:
      
      Time 0 on CPU0:
      
        kernel_init()->inet_init()->dev_add_pack()
      
      At time 0, the ptype_lock is held by CPU0 in dev_add_pack();
      
      Time 1 on CPU1:
      
        tipc_enable_bearer()->enable_bearer()->dev_add_pack()
      
      At time 1, tipc_enable_bearer() first holds tipc_net_lock, and then
      wants to take ptype_lock to register TIPC protocol handler into the
      networking stack.  But the ptype_lock has been taken by dev_add_pack()
      on CPU0, so at this time the dev_add_pack() running on CPU1 has to be
      busy looping.
      
      Time 2 on CPU0:
      
        netif_receive_skb()->recv_msg()->tipc_recv_msg()
      
      At time 2, an incoming TIPC packet arrives at CPU0, hence
      tipc_recv_msg() will be invoked. In tipc_recv_msg(), it first wants
      to hold tipc_net_lock.  At the moment, below scenario happens:
      
      On CPU0, below is our sequence of taking locks:
      
        lock(ptype_lock)->lock(tipc_net_lock)
      
      On CPU1, our sequence of taking locks looks like:
      
        lock(tipc_net_lock)->lock(ptype_lock)
      
      Obviously deadlock may happen in this case.
      
      But please note the deadlock possibly doesn't occur at all when the
      first TIPC bearer is enabled.  Before enable_bearer() -- running on
      CPU1 does not hold ptype_lock, so the TIPC receive handler (i.e.
      recv_msg()) is not registered successfully via dev_add_pack(), so
      the tipc_recv_msg() cannot be called by recv_msg() even if a TIPC
      message comes to CPU0. But when the second TIPC bearer is
      registered, the deadlock can perhaps really happen.
      
      To fix it, we will push the work of registering TIPC protocol
      handler into workqueue context. After the change, both paths taking
      ptype_lock are always in process contexts, thus, the deadlock should
      never occur.
      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>
      4225a398
    • Ying Xue's avatar
      tipc: optimize the initialization of network device notifier · fa7f86f1
      Ying Xue authored
      Ethernet media initialization is only done when TIPC is started or
      switched to network mode. So the initialization of the network device
      notifier structure can be moved out of this function and done
      statically instead.
      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>
      fa7f86f1
  8. 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
  9. 30 Dec, 2011 1 commit
  10. 27 Dec, 2011 7 commits
  11. 18 Sep, 2011 3 commits
  12. 01 Jan, 2011 3 commits
  13. 02 Dec, 2010 1 commit
  14. 10 Sep, 2010 1 commit
  15. 07 Sep, 2010 2 commits
  16. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  17. 17 May, 2009 1 commit
  18. 28 Oct, 2008 1 commit
  19. 20 Jul, 2008 1 commit
  20. 15 Jul, 2008 1 commit
  21. 25 Mar, 2008 1 commit