1. 16 6月, 2016 2 次提交
  2. 23 9月, 2015 1 次提交
    • P
      atomic, arch: Audit atomic_{read,set}() · 62e8a325
      Peter Zijlstra 提交于
      This patch makes sure that atomic_{read,set}() are at least
      {READ,WRITE}_ONCE().
      
      We already had the 'requirement' that atomic_read() should use
      ACCESS_ONCE(), and most archs had this, but a few were lacking.
      All are now converted to use READ_ONCE().
      
      And, by a symmetry and general paranoia argument, upgrade atomic_set()
      to use WRITE_ONCE().
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: james.hogan@imgtec.com
      Cc: linux-kernel@vger.kernel.org
      Cc: oleg@redhat.com
      Cc: will.deacon@arm.com
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      62e8a325
  3. 27 7月, 2015 3 次提交
    • P
      atomic: Collapse all atomic_{set,clear}_mask definitions · de9e432c
      Peter Zijlstra 提交于
      Move the now generic definitions of atomic_{set,clear}_mask() into
      linux/atomic.h to avoid endless and pointless repetition.
      
      Also, provide an atomic_andnot() wrapper for those few archs that can
      implement that.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      de9e432c
    • P
      atomic: Provide atomic_{or,xor,and} · e6942b7d
      Peter Zijlstra 提交于
      Implement atomic logic ops -- atomic_{or,xor,and}.
      
      These will replace the atomic_{set,clear}_mask functions that are
      available on some archs.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      e6942b7d
    • P
      frv: Rewrite atomic implementation · b0d8003e
      Peter Zijlstra 提交于
      Mostly complete rewrite of the FRV atomic implementation, instead of
      using assembly files, use inline assembler.
      
      The out-of-line CONFIG option makes a bit of a mess of things, but a
      little CPP trickery gets that done too.
      
      FRV already had the atomic logic ops but under a non standard name,
      the reimplementation provides the generic names and provides the
      intermediate form required for the bitops implementation.
      
      The slightly inconsistent __atomic32_fetch_##op naming is because
      __atomic_fetch_##op conlicts with GCC builtin functions.
      
      The 64bit atomic ops use the inline assembly %Ln construct to access
      the low word register (r+1), afaik this construct was not previously
      used in the kernel and is completely undocumented, but I found it in
      the FRV GCC code and it seems to work.
      
      FRV had a non-standard definition of atomic_{clear,set}_mask() which
      would work types other than atomic_t, the one user relying on that
      (arch/frv/kernel/dma.c) got converted to use the new intermediate
      form.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      b0d8003e
  4. 03 10月, 2014 1 次提交
  5. 18 4月, 2014 1 次提交
  6. 29 3月, 2012 1 次提交
  7. 27 7月, 2011 3 次提交
  8. 17 5月, 2010 1 次提交
  9. 02 7月, 2009 1 次提交
    • D
      FRV: Implement atomic64_t · 00460f41
      David Howells 提交于
      Implement atomic64_t and its ops for FRV.  Tested with the following patch:
      
      	diff --git a/arch/frv/kernel/setup.c b/arch/frv/kernel/setup.c
      	index 55e4fab..086d50d 100644
      	--- a/arch/frv/kernel/setup.c
      	+++ b/arch/frv/kernel/setup.c
      	@@ -746,6 +746,52 @@ static void __init parse_cmdline_early(char *cmdline)
      
      	 } /* end parse_cmdline_early() */
      
      	+static atomic64_t xxx;
      	+
      	+static void test_atomic64(void)
      	+{
      	+	atomic64_set(&xxx, 0x12300000023LL);
      	+
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0x12300000023LL);
      	+	mb();
      	+	if (atomic64_inc_return(&xxx) != 0x12300000024LL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0x12300000024LL);
      	+	mb();
      	+	if (atomic64_sub_return(0x36900000050LL, &xxx) != -0x2460000002cLL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != -0x2460000002cLL);
      	+	mb();
      	+	if (atomic64_dec_return(&xxx) != -0x2460000002dLL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != -0x2460000002dLL);
      	+	mb();
      	+	if (atomic64_add_return(0x36800000001LL, &xxx) != 0x121ffffffd4LL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0x121ffffffd4LL);
      	+	mb();
      	+	if (atomic64_cmpxchg(&xxx, 0x123456789abcdefLL, 0x121ffffffd4LL) != 0x121ffffffd4LL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0x121ffffffd4LL);
      	+	mb();
      	+	if (atomic64_cmpxchg(&xxx, 0x121ffffffd4LL, 0x123456789abcdefLL) != 0x121ffffffd4LL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0x123456789abcdefLL);
      	+	mb();
      	+	if (atomic64_xchg(&xxx, 0xabcdef123456789LL) != 0x123456789abcdefLL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0xabcdef123456789LL);
      	+	mb();
      	+}
      	+
      	 /*****************************************************************************/
      	 /*
      	  *
      	@@ -845,6 +891,8 @@ void __init setup_arch(char **cmdline_p)
      	 //	asm volatile("movgs %0,timerd" :: "r"(10000000));
      	 //	__set_HSR(0, __get_HSR(0) | HSR0_ETMD);
      
      	+	test_atomic64();
      	+
      	 } /* end setup_arch() */
      
      	 #if 0
      
      Note that this doesn't cover all the trivial wrappers, but does cover all the
      substantial implementations.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      00460f41
  10. 12 6月, 2009 1 次提交
  11. 10 4月, 2009 1 次提交
  12. 07 1月, 2009 1 次提交
  13. 09 2月, 2008 1 次提交
    • M
      Fix FRV cmpxchg_local · 6784fd59
      Mathieu Desnoyers 提交于
      Fix the FRV cmpxchg_local by breaking the following header dependency loop :
      
      linux/kernel.h -> linux/bitops.h -> asm-frv/bitops.h -> asm-frv/atomic.h
        -> asm-frv/system.h ->
        asm-generic/cmpxchg_local.h -> typecheck() defined in linux/kernel.h
      
      and
      
      linux/kernel.h -> linux/bitops.h -> asm-frv/bitops.h -> asm-frv/atomic.h ->
        asm-generic/cmpxchg_local.h -> typecheck() defined in linux/kernel.h
      
      In order to fix this :
      - Move the atomic_test_and_ *_mask inlines from asm-frv/atomic.h (why are they
        there at all anyway ? They are not touching atomic_t variables!) to
        asm-frv/bitops.h.
      
      Also fix a build issue with cmpxchg : it does not cast to (unsigned long *)
      like other architectures, to deal with it in the cmpxchg_local macro.
      
      FRV builds fine with this patch.
      
      Thanks to Adrian Bunk <bunk@kernel.org> for spotting this bug.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Adrian Bunk <bunk@kernel.org>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6784fd59
  14. 03 2月, 2008 1 次提交
  15. 09 5月, 2007 1 次提交
  16. 23 6月, 2006 1 次提交
  17. 26 4月, 2006 1 次提交
  18. 15 2月, 2006 1 次提交
  19. 10 1月, 2006 1 次提交
  20. 09 1月, 2006 1 次提交
  21. 07 1月, 2006 1 次提交
  22. 14 11月, 2005 2 次提交
  23. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4