Doug / smarc-fsl-linux-kernel

20 Dec, 2011

1 commit

02 Jan, 2011

2 commits

  • e3ec9c7d5   tipc: remove zeroing assignments to static global variables ... Browse Code »

    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

    Allan Stephens
     
  • 0e65967e3   tipc: cleanup various cosmetic whitespace issues ... Browse Code »

    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

    Allan Stephens
     

17 Oct, 2010

1 commit

  • 31e3c3f6f   tipc: cleanup function namespace ... Browse Code »

    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

    stephen hemminger
     

17 Mar, 2010

1 commit

  • a2f46ee1b   tipc: fix lockdep warning on address assignment ... Browse Code »

    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

    Neil Horman
     

15 Jul, 2008

1 commit

  • 0e35fd5e5   tipc: Eliminate improper use of TIPC_OK error code ... Browse Code »

    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

    Allan Stephens
     

13 May, 2008

1 commit

  • 7ef43ebaa   tipc: Fix race condition when creating socket or native port ... Browse Code »

    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

    Allan Stephens
     

17 Apr, 2008

3 commits

25 Feb, 2008

1 commit

  • 5f2f40a92   tipc: fix integer as NULL pointer sparse warnings in tipc ... Browse Code »

    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

    Harvey Harrison
     

11 Feb, 2007

1 commit

22 Jul, 2006

1 commit

28 Jun, 2006

1 commit

  • 34af946a2   [PATCH] spin/rwlock init cleanups ... Browse Code »

    locking init cleanups:

    - convert " = SPIN_LOCK_UNLOCKED" to spin_lock_init() or DEFINE_SPINLOCK()
    - convert rwlocks in a similar manner

    this patch was generated automatically.

    Motivation:

    - cleanliness
    - lockdep needs control of lock initialization, which the open-coded
    variants do not give
    - it's also useful for -rt and for lock debugging in general

    Signed-off-by: Ingo Molnar
    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

26 Jun, 2006

1 commit

  • f131072c3   [TIPC]: First phase of assert() cleanup ... Browse Code »

    This also contains enhancements to simplify comparisons in name table
    publication removal algorithm and to simplify name table sanity checking
    when shutting down TIPC.

    Signed-off-by: Allan Stephens
    Signed-off-by: Per Liden
    Signed-off-by: David S. Miller

    Allan Stephens
     

21 Mar, 2006

1 commit

  • 1fc54d8f4   [TIPC]: Fix simple sparse warnings ... Browse Code »

    Tried to run the new tipc stack through sparse.
    Following patch fixes all cases where 0 was used
    as replacement of NULL.
    Use NULL to document this is a pointer and to silence sparse.

    This brough sparse warning count down with 127 to 24 warnings.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: Per Liden
    Signed-off-by: David S. Miller

    Sam Ravnborg
     

18 Jan, 2006

1 commit

13 Jan, 2006

4 commits