27 Jul, 2011

8 commits

  • Only a few core funcs need to be implemented for SMP systems, so allow the
    arches to override them while getting the rest for free.

    At least, this is enough to allow the Blackfin SMP port to use things.

    Signed-off-by: Mike Frysinger
    Cc: Arun Sharma
    Cc: Arnd Bergmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Frysinger
     
  • Since arches are expected to implement this guy, add a common version for
    people the same way as atomic_clear_mask is handled.

    Signed-off-by: Mike Frysinger
    Cc: Arun Sharma
    Cc: Arnd Bergmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Frysinger
     
  • The atomic helpers are supposed to take an atomic_t pointer, not a random
    unsigned long pointer. So convert atomic_clear_mask over.

    While we're here, also add some nice documentation to the func.

    Signed-off-by: Mike Frysinger
    Cc: Arun Sharma
    Cc: Arnd Bergmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Frysinger
     
  • We already declared inc/dec helpers, so we don't need to call the
    atomic_{add,sub}_return funcs directly.

    Signed-off-by: Mike Frysinger
    Cc: Arun Sharma
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Frysinger
     
  • This clarifies the differences between and

    Signed-off-by: Arun Sharma
    Suggested-by: Mike Frysinger
    Cc: Eric Dumazet
    Cc: Ingo Molnar
    Cc: David Miller
    Acked-by: Mike Frysinger
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arun Sharma
     
  • After changing all consumers of atomics to include , we
    ran into some compile time errors due to this dependency chain:

    linux/atomic.h
    -> asm/atomic.h
    -> asm-generic/atomic-long.h

    where atomic-long.h could use funcs defined later in linux/atomic.h
    without a prototype. This patches moves the code that includes
    asm-generic/atomic*.h to linux/atomic.h.

    Archs that need need to select
    CONFIG_GENERIC_ATOMIC64 from now on (some of them used to include it
    unconditionally).

    Compile tested on i386 and x86_64 with allnoconfig.

    Signed-off-by: Arun Sharma
    Cc: Eric Dumazet
    Cc: Ingo Molnar
    Cc: David Miller
    Acked-by: Mike Frysinger
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arun Sharma
     
  • This is in preparation for more generic atomic primitives based on
    __atomic_add_unless.

    Signed-off-by: Arun Sharma
    Signed-off-by: Hans-Christian Egtvedt
    Reviewed-by: Eric Dumazet
    Cc: Ingo Molnar
    Cc: David Miller
    Acked-by: Mike Frysinger
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arun Sharma
     
  • This allows us to move duplicated code in
    (atomic_inc_not_zero() for now) to

    Signed-off-by: Arun Sharma
    Reviewed-by: Eric Dumazet
    Cc: Ingo Molnar
    Cc: David Miller
    Cc: Eric Dumazet
    Acked-by: Mike Frysinger
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arun Sharma
     

23 Oct, 2010

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
    asm-generic/io.h: allow people to override individual funcs
    bitops: remove duplicated extern declarations
    bitops: make asm-generic/bitops/find.h more generic
    asm-generic: kdebug.h: Checkpatch cleanup
    asm-generic: fcntl: make exported headers use strict posix types
    asm-generic: cmpxchg does not handle non-long arguments
    asm-generic: make atomic_add_unless a function

    Linus Torvalds
     

10 Oct, 2010

1 commit

  • atomic_add_unless is a macro so, bad things happen if the caller defines
    a local variable named c, just like like the local variable c defined by
    the macro. Thus, convert atomic_add_unless to a function. (bug triggered
    by net/ipv4/netfilter/ipt_CLUSTERIP.c: clusterip_config_find_get calls
    atomic_inc_not_zero)

    Signed-off-by: Mathieu Lacage
    Signed-off-by: Arnd Bergmann

    Mathieu Lacage
     

07 Oct, 2010

1 commit

  • Fix the IRQ flag handling naming. In linux/irqflags.h under one configuration,
    it maps:

    local_irq_enable() -> raw_local_irq_enable()
    local_irq_disable() -> raw_local_irq_disable()
    local_irq_save() -> raw_local_irq_save()
    ...

    and under the other configuration, it maps:

    raw_local_irq_enable() -> local_irq_enable()
    raw_local_irq_disable() -> local_irq_disable()
    raw_local_irq_save() -> local_irq_save()
    ...

    This is quite confusing. There should be one set of names expected of the
    arch, and this should be wrapped to give another set of names that are expected
    by users of this facility.

    Change this to have the arch provide:

    flags = arch_local_save_flags()
    flags = arch_local_irq_save()
    arch_local_irq_restore(flags)
    arch_local_irq_disable()
    arch_local_irq_enable()
    arch_irqs_disabled_flags(flags)
    arch_irqs_disabled()
    arch_safe_halt()

    Then linux/irqflags.h wraps these to provide:

    raw_local_save_flags(flags)
    raw_local_irq_save(flags)
    raw_local_irq_restore(flags)
    raw_local_irq_disable()
    raw_local_irq_enable()
    raw_irqs_disabled_flags(flags)
    raw_irqs_disabled()
    raw_safe_halt()

    with type checking on the flags 'arguments', and then wraps those to provide:

    local_save_flags(flags)
    local_irq_save(flags)
    local_irq_restore(flags)
    local_irq_disable()
    local_irq_enable()
    irqs_disabled_flags(flags)
    irqs_disabled()
    safe_halt()

    with tracing included if enabled.

    The arch functions can now all be inline functions rather than some of them
    having to be macros.

    Signed-off-by: David Howells [X86, FRV, MN10300]
    Signed-off-by: Chris Metcalf [Tile]
    Signed-off-by: Michal Simek [Microblaze]
    Tested-by: Catalin Marinas [ARM]
    Acked-by: Thomas Gleixner
    Acked-by: Haavard Skinnemoen [AVR]
    Acked-by: Tony Luck [IA-64]
    Acked-by: Hirokazu Takata [M32R]
    Acked-by: Greg Ungerer [M68K/M68KNOMMU]
    Acked-by: Ralf Baechle [MIPS]
    Acked-by: Kyle McMartin [PA-RISC]
    Acked-by: Paul Mackerras [PowerPC]
    Acked-by: Martin Schwidefsky [S390]
    Acked-by: Chen Liqin [Score]
    Acked-by: Matt Fleming [SH]
    Acked-by: David S. Miller [Sparc]
    Acked-by: Chris Zankel [Xtensa]
    Reviewed-by: Richard Henderson [Alpha]
    Reviewed-by: Yoshinori Sato [H8300]
    Cc: starvik@axis.com [CRIS]
    Cc: jesper.nilsson@axis.com [CRIS]
    Cc: linux-cris-kernel@axis.com

    David Howells
     

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

    Michal Simek
     

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

    Peter Fritzsche
     

17 May, 2010

1 commit


12 Jun, 2009

2 commits


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

    Heiko Carstens
     

11 Dec, 2008

1 commit


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

    Christoph Lameter
     

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

    Mathieu Desnoyers
     
  • Signed-off-by: Mathieu Desnoyers
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mathieu Desnoyers
     

08 Dec, 2006

1 commit


16 Jan, 2006

1 commit


09 Jan, 2006

1 commit


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

    Christoph Lameter