10 Aug, 2010
1 commit
-
The start/stop_critical_timing functions for preemptirqsoff, preemptoff
and irqsoff tracers contain atomic_inc() and atomic_dec() operations.Atomic operations use local_irq_save/restore macros to ensure atomic
access but they are traced by the same function which is causing recursion
problem.The reason is when these tracers are turn ON then the
local_irq_save/restore macros are changed in include/linux/irqflags.h to
call trace_hardirqs_on/off which call start/stop_critical_timing.Microblaze was affected because it uses generic atomic implementation.
Signed-off-by: Michal Simek
Acked-by: Steven Rostedt
Cc: Ingo Molnar
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 May, 2010
1 commit
-
32-bit Sparc used to only allow usage of 24-bit of it's atomic_t type.
This was corrected with linux 2.6.3 when Keith M Wesolowski changed the
implementation to use the parisc approach of having an array of spinlocks
to protect the atomic_t.These warnings were also removed from the sparc implementation when the
new implementation was merged in BKrev:402e4949VThdc6D3iaosSFUgabMfvw, but
the warning still remained in some other places without any 24-bit-only
atomic_t implementation inside the kernel.We should remove these warnings to allow users to rely on the full 32-bit
range of atomic_t.Signed-off-by: Peter Fritzsche
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 May, 2010
1 commit
-
In preparation for removing volatile from the atomic_t definition, this
patch adds a volatile cast to all the atomic read functions.Signed-off-by: Anton Blanchard
Signed-off-by: Linus Torvalds
12 Jun, 2009
2 commits
-
atomic.h and io.h are based on the mn10300 architecture,
which is already pretty generic and can be used by
other architectures that do not have hardware support
for atomic operations or out-of-order I/O access.Signed-off-by: Arnd Bergmann
-
The existing asm-generic/atomic.h only defines the
atomic_long type. This renames it to atomic-long.h
so we have a place to add a truly generic atomic.h
that can be used on all non-SMP systems.Signed-off-by: Remis Lima Baima
Signed-off-by: Arnd Bergmann
Acked-by: Ingo Molnar
03 May, 2009
1 commit
-
On a linux-next allyesconfig build:
kernel/trace/ring_buffer.c:1726:
warning: passing argument 1 of 'atomic_cmpxchg' from incompatible pointer type
linux-next/arch/s390/include/asm/atomic.h:112:
note: expected 'struct atomic_t *' but argument is of type 'struct atomic64_t *'atomic_long_cmpxchg and atomic_long_xchg are incorrectly defined for 64
bit architectures. They should be mapped to the atomic64_* variants.Acked-by: Mathieu Desnoyers
Signed-off-by: Heiko Carstens
Acked-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Dec, 2008
1 commit
-
atomic_long_xchg() is not correctly defined for 32bit arches.
Signed-off-by: Eric Dumazet
Cc: Mathieu Desnoyers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
05 Jul, 2008
1 commit
-
Remove all clameter@sgi.com addresses from the kernel tree since they will
become invalid on June 27th. Change my maintainer email address for the
slab allocators to cl@linux-foundation.org (which will be the new email
address for the future).Signed-off-by: Christoph Lameter
Signed-off-by: Christoph Lameter
Cc: Pekka Enberg
Cc: Stephen Rothwell
Cc: Matt Mackall
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
09 May, 2007
2 commits
-
atomic_add_unless as inline. Remove system.h atomic.h circular dependency.
I agree (with Andi Kleen) this typeof is not needed and more error
prone. All the original atomic.h code that uses cmpxchg (which includes
the atomic_add_unless) uses defines instead of inline functions,
probably to circumvent a circular dependency between system.h and
atomic.h on powerpc (which my patch addresses). Therefore, it makes
sense to use inline functions that will provide type checking.atomic_add_unless as inline. Remove system.h atomic.h circular dependency.
Digging into the FRV architecture shows me that it is also affected by
such a circular dependency. Here is the diff applying this against the
rest of my atomic.h patches.It applies over the atomic.h standardization patches.
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Dec, 2006
1 commit
-
cleanup asm-generic/atomic.h
- no longer a userspace header
- remove the unneeded #include
- #else/#endif comments[akpm@osdl.org: fix arm build]
Signed-off-by: Adrian Bunk
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
16 Jan, 2006
1 commit
-
For some reason, the BITS_PER_LONG == 64 case of atomic_long_set
was using atomic_set instead of atomic64_set. This does not jive
with architectures which use an inline instead of a #define to
implement their atomic_set() primitives.Signed-off-by: Kyle McMartin
Signed-off-by: Linus Torvalds
09 Jan, 2006
1 commit
-
For BITS_PER_LONG
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Jan, 2006
1 commit
-
Several counters already have the need to use 64 atomic variables on 64 bit
platforms (see mm_counter_t in sched.h). We have to do ugly ifdefs to fall
back to 32 bit atomic on 32 bit platforms.The VM statistics patch that I am working on will also make more extensive
use of atomic64.This patch introduces a new type atomic_long_t by providing definitions in
asm-generic/atomic.h that works similar to the c "long" type. Its 32 bits
on 32 bit platforms and 64 bits on 64 bit platforms.Also cleans up the determination of the mm_counter_t in sched.h.
Signed-off-by: Christoph Lameter
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
