1. 20 Dec, 2012 1 commit
    • Stephen Boyd's avatar
      lib: atomic64: Initialize locks statically to fix early users · fcc16882
      Stephen Boyd authored
      The atomic64 library uses a handful of static spin locks to implement
      atomic 64-bit operations on architectures without support for atomic
      64-bit instructions.
      
      Unfortunately, the spinlocks are initialized in a pure initcall and that
      is too late for the vfs namespace code which wants to use atomic64
      operations before the initcall is run.
      
      This became a problem as of commit 8823c079: "vfs: Add setns support
      for the mount namespace".
      
      This leads to BUG messages such as:
      
        BUG: spinlock bad magic on CPU#0, swapper/0/0
         lock: atomic64_lock+0x240/0x400, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
          do_raw_spin_lock+0x158/0x198
          _raw_spin_lock_irqsave+0x4c/0x58
          atomic64_add_return+0x30/0x5c
          alloc_mnt_ns.clone.14+0x44/0xac
          create_mnt_ns+0xc/0x54
          mnt_init+0x120/0x1d4
          vfs_caches_init+0xe0/0x10c
          start_kernel+0x29c/0x300
      
      coming out early on during boot when spinlock debugging is enabled.
      
      Fix this by initializing the spinlocks statically at compile time.
      Reported-and-tested-by: 's avatarVaibhav Bedia <vaibhav.bedia@ti.com>
      Tested-by: 's avatarTony Lindgren <tony@atomide.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: 's avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      fcc16882
  2. 07 Mar, 2012 1 commit
  3. 14 Sep, 2011 1 commit
  4. 13 Sep, 2011 1 commit
    • Shan Hai's avatar
      locking, lib/atomic64: Annotate atomic64_lock::lock as raw · f59ca058
      Shan Hai authored
      The spinlock protected atomic64 operations must be irq safe as they
      are used in hard interrupt context and cannot be preempted on -rt:
      
       NIP [c068b218] rt_spin_lock_slowlock+0x78/0x3a8
        LR [c068b1e0] rt_spin_lock_slowlock+0x40/0x3a8
       Call Trace:
        [eb459b90] [c068b1e0] rt_spin_lock_slowlock+0x40/0x3a8 (unreliable)
        [eb459c20] [c068bdb0] rt_spin_lock+0x40/0x98
        [eb459c40] [c03d2a14] atomic64_read+0x48/0x84
        [eb459c60] [c001aaf4] perf_event_interrupt+0xec/0x28c
        [eb459d10] [c0010138] performance_monitor_exception+0x7c/0x150
        [eb459d30] [c0014170] ret_from_except_full+0x0/0x4c
      
      So annotate it.
      
      In mainline this change documents the low level nature of
      the lock - otherwise there's no functional difference. Lockdep
      and Sparse checking will work as usual.
      Signed-off-by: 's avatarShan Hai <haishan.bai@gmail.com>
      Reviewed-by: 's avatarYong Zhang <yong.zhang0@gmail.com>
      Signed-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: 's avatarIngo Molnar <mingo@elte.hu>
      f59ca058
  5. 26 Jul, 2011 1 commit
  6. 01 Mar, 2010 1 commit
  7. 30 Jul, 2009 1 commit
  8. 15 Jun, 2009 1 commit
    • Paul Mackerras's avatar
      lib: Provide generic atomic64_t implementation · 09d4e0ed
      Paul Mackerras authored
      Many processor architectures have no 64-bit atomic instructions, but
      we need atomic64_t in order to support the perf_counter subsystem.
      
      This adds an implementation of 64-bit atomic operations using hashed
      spinlocks to provide atomicity.  For each atomic operation, the address
      of the atomic64_t variable is hashed to an index into an array of 16
      spinlocks.  That spinlock is taken (with interrupts disabled) around the
      operation, which can then be coded non-atomically within the lock.
      
      On UP, all the spinlock manipulation goes away and we simply disable
      interrupts around each operation.  In fact gcc eliminates the whole
      atomic64_lock variable as well.
      Signed-off-by: 's avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: 's avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      09d4e0ed