1. 28 12月, 2011 2 次提交
  2. 18 9月, 2011 1 次提交
  3. 25 6月, 2011 1 次提交
  4. 14 3月, 2011 3 次提交
  5. 24 2月, 2011 1 次提交
    • A
      tipc: Combine bearer structure with tipc_bearer structure · 2d627b92
      Allan Stephens 提交于
      Combines two distinct structures containing information about a TIPC bearer
      into a single structure. The structures were previously kept separate so
      that public information about a bearer could be made available to plug-in
      media types using TIPC's native API, while the remaining information was
      kept private for use by TIPC itself. However, now that the native API has
      been removed there is no longer any need for this arrangement.
      
      Since one of the structures was already embedded within the other, the
      change largely involves replacing instances of "publ.foo" with "foo".
      The changes do not otherwise alter the operation of TIPC bearers.
      Signed-off-by: NAllan Stephens <Allan.Stephens@windriver.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      2d627b92
  6. 03 12月, 2010 3 次提交
  7. 13 5月, 2010 1 次提交
  8. 04 3月, 2010 1 次提交
    • N
      tipc: Fix oops on send prior to entering networked mode (v3) · d0021b25
      Neil Horman 提交于
      Fix TIPC to disallow sending to remote addresses prior to entering NET_MODE
      
      user programs can oops the kernel by sending datagrams via AF_TIPC prior to
      entering networked mode.  The following backtrace has been observed:
      
      ID: 13459  TASK: ffff810014640040  CPU: 0   COMMAND: "tipc-client"
      [exception RIP: tipc_node_select_next_hop+90]
      RIP: ffffffff8869d3c3  RSP: ffff81002d9a5ab8  RFLAGS: 00010202
      RAX: 0000000000000001  RBX: 0000000000000001  RCX: 0000000000000001
      RDX: 0000000000000000  RSI: 0000000000000001  RDI: 0000000001001001
      RBP: 0000000001001001   R8: 0074736575716552   R9: 0000000000000000
      R10: ffff81003fbd0680  R11: 00000000000000c8  R12: 0000000000000008
      R13: 0000000000000001  R14: 0000000000000001  R15: ffff810015c6ca00
      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
      RIP: 0000003cbd8d49a3  RSP: 00007fffc84e0be8  RFLAGS: 00010206
      RAX: 000000000000002c  RBX: ffffffff8005d116  RCX: 0000000000000000
      RDX: 0000000000000008  RSI: 00007fffc84e0c00  RDI: 0000000000000003
      RBP: 0000000000000000   R8: 00007fffc84e0c10   R9: 0000000000000010
      R10: 0000000000000000  R11: 0000000000000246  R12: 0000000000000000
      R13: 00007fffc84e0d10  R14: 0000000000000000  R15: 00007fffc84e0c30
      ORIG_RAX: 000000000000002c  CS: 0033  SS: 002b
      
      What happens is that, when the tipc module in inserted it enters a standalone
      node mode in which communication to its own address is allowed <0.0.0> but not
      to other addresses, since the appropriate data structures have not been
      allocated yet (specifically the tipc_net pointer).  There is nothing stopping a
      client from trying to send such a message however, and if that happens, we
      attempt to dereference tipc_net.zones while the pointer is still NULL, and
      explode.  The fix is pretty straightforward.  Since these oopses all arise from
      the dereference of global pointers prior to their assignment to allocated
      values, and since these allocations are small (about 2k total), lets convert
      these pointers to static arrays of the appropriate size.  All the accesses to
      these bits consider 0/NULL to be a non match when searching, so all the lookups
      still work properly, and there is no longer a chance of a bad dererence
      anywhere.  As a bonus, this lets us eliminate the setup/teardown routines for
      those pointers, and elimnates the need to preform any locking around them to
      prevent access while their being allocated/freed.
      
      I've updated the tipc_net structure to behave this way to fix the exact reported
      problem, and also fixed up the tipc_bearers and media_list arrays to fix an
      obvious simmilar problem that arises from issuing tipc-config commands to
      manipulate bearers/links prior to entering networked mode
      
      I've tested this for a few hours by running the sanity tests and stress test
      with the tipcutils suite, and nothing has fallen over.  There have been a few
      lockdep warnings, but those were there before, and can be addressed later, as
      they didn't actually result in any deadlock.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Allan Stephens <allan.stephens@windriver.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: tipc-discussion@lists.sourceforge.net
      
       bearer.c |   37 ++++++-------------------------------
       bearer.h |    2 +-
       net.c    |   25 ++++---------------------
       3 files changed, 11 insertions(+), 53 deletions(-)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0021b25
  9. 03 9月, 2008 1 次提交
  10. 11 2月, 2007 1 次提交
  11. 18 1月, 2006 2 次提交
  12. 13 1月, 2006 4 次提交