1. 01 5月, 2012 1 次提交
    • P
      tipc: compress out gratuitous extra carriage returns · 617d3c7a
      Paul Gortmaker 提交于
      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: NPaul Gortmaker <paul.gortmaker@windriver.com>
      617d3c7a
  2. 20 12月, 2011 1 次提交
  3. 02 1月, 2011 2 次提交
  4. 17 10月, 2010 1 次提交
  5. 17 3月, 2010 1 次提交
    • N
      tipc: fix lockdep warning on address assignment · a2f46ee1
      Neil Horman 提交于
      So in the forward porting of various tipc packages, I was constantly
      getting this lockdep warning everytime I used tipc-config to set a network
      address for the protocol:
      
      [ INFO: possible circular locking dependency detected ]
      2.6.33 #1
      tipc-config/1326 is trying to acquire lock:
      (ref_table_lock){+.-...}, at: [<ffffffffa0315148>] tipc_ref_discard+0x53/0xd4 [tipc]
      
      but task is already holding lock:
      (&(&entry->lock)->rlock#2){+.-...}, at: [<ffffffffa03150d5>] tipc_ref_lock+0x43/0x63 [tipc]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&(&entry->lock)->rlock#2){+.-...}:
      [<ffffffff8107b508>] __lock_acquire+0xb67/0xd0f
      [<ffffffff8107b78c>] lock_acquire+0xdc/0x102
      [<ffffffff8145471e>] _raw_spin_lock_bh+0x3b/0x6e
      [<ffffffffa03152b1>] tipc_ref_acquire+0xe8/0x11b [tipc]
      [<ffffffffa031433f>] tipc_createport_raw+0x78/0x1b9 [tipc]
      [<ffffffffa031450b>] tipc_createport+0x8b/0x125 [tipc]
      [<ffffffffa030f221>] tipc_subscr_start+0xce/0x126 [tipc]
      [<ffffffffa0308fb2>] process_signal_queue+0x47/0x7d [tipc]
      [<ffffffff81053e0c>] tasklet_action+0x8c/0xf4
      [<ffffffff81054bd8>] __do_softirq+0xf8/0x1cd
      [<ffffffff8100aadc>] call_softirq+0x1c/0x30
      [<ffffffff810549f4>] _local_bh_enable_ip+0xb8/0xd7
      [<ffffffff81054a21>] local_bh_enable_ip+0xe/0x10
      [<ffffffff81454d31>] _raw_spin_unlock_bh+0x34/0x39
      [<ffffffffa0308eb8>] spin_unlock_bh.clone.0+0x15/0x17 [tipc]
      [<ffffffffa0308f47>] tipc_k_signal+0x8d/0xb1 [tipc]
      [<ffffffffa0308dd9>] tipc_core_start+0x8a/0xad [tipc]
      [<ffffffffa01b1087>] 0xffffffffa01b1087
      [<ffffffff8100207d>] do_one_initcall+0x72/0x18a
      [<ffffffff810872fb>] sys_init_module+0xd8/0x23a
      [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b
      
      -> #0 (ref_table_lock){+.-...}:
      [<ffffffff8107b3b2>] __lock_acquire+0xa11/0xd0f
      [<ffffffff8107b78c>] lock_acquire+0xdc/0x102
      [<ffffffff81454836>] _raw_write_lock_bh+0x3b/0x6e
      [<ffffffffa0315148>] tipc_ref_discard+0x53/0xd4 [tipc]
      [<ffffffffa03141ee>] tipc_deleteport+0x40/0x119 [tipc]
      [<ffffffffa0316e35>] release+0xeb/0x137 [tipc]
      [<ffffffff8139dbf4>] sock_release+0x1f/0x6f
      [<ffffffff8139dc6b>] sock_close+0x27/0x2b
      [<ffffffff811116f6>] __fput+0x12a/0x1df
      [<ffffffff811117c5>] fput+0x1a/0x1c
      [<ffffffff8110e49b>] filp_close+0x68/0x72
      [<ffffffff8110e552>] sys_close+0xad/0xe7
      [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b
      
      Finally decided I should fix this.  Its a straightforward inversion,
      tipc_ref_acquire takes two locks in this order:
      ref_table_lock
      entry->lock
      
      while tipc_deleteport takes them in this order:
      entry->lock (via tipc_port_lock())
      ref_table_lock (via tipc_ref_discard())
      
      when the same entry is referenced, we get the above warning.  The fix is equally
      straightforward.  Theres no real relation between the entry->lock and the
      ref_table_lock (they just are needed at the same time), so move the entry->lock
      aquisition in tipc_ref_acquire down, after we unlock ref_table_lock (this is
      safe since the ref_table_lock guards changes to the reference table, and we've
      already claimed a slot there.  I've tested the below fix and confirmed that it
      clears up the lockdep issue
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Allan Stephens <allan.stephens@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a2f46ee1
  6. 15 7月, 2008 1 次提交
  7. 13 5月, 2008 1 次提交
  8. 17 4月, 2008 3 次提交
  9. 25 2月, 2008 1 次提交
  10. 11 2月, 2007 1 次提交
  11. 22 7月, 2006 1 次提交
  12. 28 6月, 2006 1 次提交
  13. 26 6月, 2006 1 次提交
  14. 21 3月, 2006 1 次提交
  15. 18 1月, 2006 1 次提交
  16. 13 1月, 2006 4 次提交