linux/net/tipc/ref.c, branch v3.0.61

tipc: remove zeroing assignments to static global variables

2011-01-01T21:57:57Z

Cleans up TIPC's source code to eliminate the needless initialization of static variables to zero. These changes are purely cosmetic and do not alter the operation of TIPC in any way. Signed-off-by: Allan Stephens Signed-off-by: Paul Gortmaker Signed-off-by: David S. Miller

tipc: cleanup various cosmetic whitespace issues

2011-01-01T21:57:56Z

Cleans up TIPC's source code to eliminate deviations from generally accepted coding conventions relating to leading/trailing white space and white space around commas, braces, cases, and sizeof. These changes are purely cosmetic and do not alter the operation of TIPC in any way. Signed-off-by: Allan Stephens Signed-off-by: Paul Gortmaker Signed-off-by: David S. Miller

tipc: cleanup function namespace

2010-10-16T18:13:24Z

Do some cleanups of TIPC based on make namespacecheck 1. Don't export unused symbols 2. Eliminate dead code 3. Make functions and variables local 4. Rename buf_acquire to tipc_buf_acquire since it is used in several files Compile tested only. This make break out of tree kernel modules that depend on TIPC routines. Signed-off-by: Stephen Hemminger Acked-by: Jon Maloy Acked-by: Paul Gortmaker Signed-off-by: David S. Miller

tipc: fix lockdep warning on address assignment

2010-03-16T21:15:45Z

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: [] tipc_ref_discard+0x53/0xd4 [tipc] but task is already holding lock: (&(&entry->lock)->rlock#2){+.-...}, at: [] 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){+.-...}: [] __lock_acquire+0xb67/0xd0f [] lock_acquire+0xdc/0x102 [] _raw_spin_lock_bh+0x3b/0x6e [] tipc_ref_acquire+0xe8/0x11b [tipc] [] tipc_createport_raw+0x78/0x1b9 [tipc] [] tipc_createport+0x8b/0x125 [tipc] [] tipc_subscr_start+0xce/0x126 [tipc] [] process_signal_queue+0x47/0x7d [tipc] [] tasklet_action+0x8c/0xf4 [] __do_softirq+0xf8/0x1cd [] call_softirq+0x1c/0x30 [] _local_bh_enable_ip+0xb8/0xd7 [] local_bh_enable_ip+0xe/0x10 [] _raw_spin_unlock_bh+0x34/0x39 [] spin_unlock_bh.clone.0+0x15/0x17 [tipc] [] tipc_k_signal+0x8d/0xb1 [tipc] [] tipc_core_start+0x8a/0xad [tipc] [] 0xffffffffa01b1087 [] do_one_initcall+0x72/0x18a [] sys_init_module+0xd8/0x23a [] system_call_fastpath+0x16/0x1b -> #0 (ref_table_lock){+.-...}: [] __lock_acquire+0xa11/0xd0f [] lock_acquire+0xdc/0x102 [] _raw_write_lock_bh+0x3b/0x6e [] tipc_ref_discard+0x53/0xd4 [tipc] [] tipc_deleteport+0x40/0x119 [tipc] [] release+0xeb/0x137 [tipc] [] sock_release+0x1f/0x6f [] sock_close+0x27/0x2b [] __fput+0x12a/0x1df [] fput+0x1a/0x1c [] filp_close+0x68/0x72 [] sys_close+0xad/0xe7 [] 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: Neil Horman CC: Allan Stephens Signed-off-by: David S. Miller

tipc: Eliminate improper use of TIPC_OK error code

2008-07-15T05:44:01Z

This patch corrects many places where TIPC routines indicated successful completion by returning TIPC_OK instead of 0. (The TIPC_OK symbol has the value 0, but it should only be used in contexts that deal with the error code field of a TIPC message header.) Signed-off-by: Allan Stephens Signed-off-by: David S. Miller

tipc: Fix race condition when creating socket or native port

2008-05-12T22:42:28Z

This patch eliminates the (very remote) chance of a crash resulting from a partially initialized socket or native port unexpectedly receiving a message. Now, during the creation of a socket or native port, the underlying generic port's lock is not released until all initialization required to handle incoming messages has been done. Signed-off-by: Allan Stephens Signed-off-by: David S. Miller

[TIPC]: Cleanup of TIPC reference table code

2008-04-17T01:22:20Z

This patch is a largely cosmetic cleanup of the TIPC reference table code. - The object reference field in each table entry is now single 32-bit integer instead of a union of two 32-bit integers. - Variable naming has been made more consistent. - Error message output has been made more consistent. - Useless #includes have been eliminated. Signed-off-by: Allan Stephens Signed-off-by: David S. Miller

[TIPC]: Optimized initialization of TIPC reference table

2008-04-17T01:21:47Z

This patch modifies TIPC's reference table code to delay initializing table entries until they are actually needed by applications. Signed-off-by: Allan Stephens Signed-off-by: David S. Miller

[TIPC]: Remove inlining of reference table locking routines

2008-04-17T01:21:16Z

This patch converts the TIPC reference table locking routines into non-inlined routines, since they are mainly called from non-performance critical areas of TIPC and the added code footprint incurred through inlining can no longer be justified. Signed-off-by: Allan Stephens Signed-off-by: David S. Miller

tipc: fix integer as NULL pointer sparse warnings in tipc

2008-02-25T02:38:31Z

net/tipc/cluster.c:145:2: warning: Using plain integer as NULL pointer net/tipc/link.c:3254:36: warning: Using plain integer as NULL pointer net/tipc/ref.c:151:15: warning: Using plain integer as NULL pointer net/tipc/zone.c:85:2: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison Signed-off-by: David S. Miller