* 'for-2.6.38' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu: (30 commits)
gameport: use this_cpu_read instead of lookup
x86: udelay: Use this_cpu_read to avoid address calculation
x86: Use this_cpu_inc_return for nmi counter
x86: Replace uses of current_cpu_data with this_cpu ops
x86: Use this_cpu_ops to optimize code
vmstat: User per cpu atomics to avoid interrupt disable / enable
irq_work: Use per cpu atomics instead of regular atomics
cpuops: Use cmpxchg for xchg to avoid lock semantics
x86: this_cpu_cmpxchg and this_cpu_xchg operations
percpu: Generic this_cpu_cmpxchg() and this_cpu_xchg support
percpu,x86: relocate this_cpu_add_return() and friends
connector: Use this_cpu operations
xen: Use this_cpu_inc_return
taskstats: Use this_cpu_ops
random: Use this_cpu_inc_return
fs: Use this_cpu_inc_return in buffer.c
highmem: Use this_cpu_xx_return() operations
vmstat: Use this_cpu_inc_return for vm statistics
x86: Support for this_cpu_add, sub, dec, inc_return
percpu: Generic support for this_cpu_add, sub, dec, inc_return
...
Fixed up conflicts: in arch/x86/kernel/{apic/nmi.c, apic/x2apic_uv_x.c, process.c}
as per Tejun.
__get_cpu_var() can be replaced with this_cpu_read and will then use a
single read instruction with implied address calculation to access the
correct per cpu instance.
However, the address of a per cpu variable passed to __this_cpu_read()
cannot be determined (since it's an implied address conversion through
segment prefixes). Therefore apply this only to uses of __get_cpu_var
where the address of the variable is not used.
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Hugh Dickins <hughd@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The existing asm-generic/stat.h specifies st_mtime, etc., as a 32-value,
and works well for 32-bit architectures (currently microblaze, score,
and 32-bit tile). However, for 64-bit architectures it isn't sufficient
to return 32 bits of time_t; this isn't good insurance against the 2037
rollover. (It also makes glibc support less convenient, since we can't
use glibc's handy STAT_IS_KERNEL_STAT mode.)
This change extends the two "timespec" fields for each of the three atime,
mtime, and ctime fields from "int" to "long". As a result, on 32-bit
platforms nothing changes, and 64-bit platforms will now work as expected.
The only wrinkle is 32-bit userspace under 64-bit kernels taking advantage
of COMPAT mode. For these, we leave the "struct stat64" definitions with
the "int" versions of the time_t and nsec fields, so that architectures
can implement compat_sys_stat64() and friends with sys_stat64(), etc.,
and get the expected 32-bit structure layout. This requires a
field-by-field copy in the kernel, implemented by the code guarded
under __ARCH_WANT_STAT64.
This does mean that the shape of the "struct stat" and "struct stat64"
structures is different on a 64-bit kernel, but only one of the two
structures should ever be used by any given process: "struct stat"
is meant for 64-bit userspace only, and "struct stat64" for 32-bit
userspace only. (On a 32-bit kernel the two structures continue to have
the same shape, since "long" is 32 bits.)
The alternative is keeping the two structures the same shape on 64-bit
kernels, which means a 64-bit time_t in "struct stat64" for 32-bit
processes. This is a little unnatural since 32-bit userspace can't
do anything with 64 bits of time_t information, since time_t is just
"long", not "int64_t"; and in any case 32-bit userspace might expect
to be running under a 32-bit kernel, which can't provide the high 32
bits anyway. In the case of a 32-bit kernel we'd then be extending the
kernel's 32-bit time_t to 64 bits, then truncating it back to 32 bits
again in userspace, for no particular reason. And, as mentioned above,
if we have 64-bit time_t for 32-bit processes we can't easily use glibc's
STAT_IS_KERNEL_STAT, since glibc's stat structure requires an embedded
"struct timespec", which is a pair of "long" (32-bit) values in a 32-bit
userspace. "Inventive" solutions are possible, but are pretty hacky.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6:
initramfs: Fix build break on symbol-prefixed archs
initramfs: fix initramfs size calculation
initramfs: generalize initramfs_data.xxx.S variants
scripts/kallsyms: Enable error messages while hush up unnecessary warnings
scripts/setlocalversion: update comment
kbuild: Use a single clean rule for kernel and external modules
kbuild: Do not run make clean in $(srctree)
scripts/mod/modpost.c: fix commentary accordingly to last changes
kbuild: Really don't clean bounds.h and asm-offsets.h
commit 7444a72eff ("gpiolib: allow user-selection")
removed HAVE_GPIO_LIB Kconfig symbol, but the header file still uses the
name [to confuse readers wrt #ifdef/#else/#endif location].
The real Kconfig symbol nowadays is CONFIG_GPIOLIB.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The new init ramfs format (cpio based) requires an alignment of 4 (per the
documentation and per the source files themselves). As for compressed
sources, the decompressors can all deal with unaligned buffers.
The cpio source is also found in the __init sections of the kernel, so
once they are read and expanded into a tmpfs, the source is freed. That
means there is no need to force page alignment here either.
This has been used on Blackfin systems for many releases without issue.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With the recent change "net: remove time limit in process_backlog()", the
softnet_data variable changed from "DEFINE_PER_CPU()" to
"DEFINE_PER_CPU_ALIGNED()" which moved it from the .data section to the
.data.shared_align section. I'm not saying this patch is wrong, just that
is what caused me to notice this larger problem. No one else in the
kernel is using this aligned macro variant, so I imagine that's why no one
has noticed yet.
Since .data..shared_align isn't declared in any vmlinux files that I can
see, the linker just places it last. This "just works" for most people,
but when building a ROM kernel on Blackfin systems, it causes section
overlap errors:
bfin-uclinux-ld.real:
section .init.data [00000000202e06b8 -> 00000000202e48b7] overlaps
section .data.shared_aligned [00000000202e06b8 -> 00000000202e0723]
I imagine other arches which support the ROM config option and thus do
funky placement would see similar issues ...
On x86, it is stuck in a dedicated section at the end:
[8] .data PROGBITS ffffffff810ec000 2ec0000303a8 00 WA 0 0 4096
[9] .data.shared_alig PROGBITS ffffffff8111c3c0 31c3c00000c8 00 WA 0 0 64
So make sure we include this section in the DATA_DATA macro so that it is
placed in the right location.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Cc: Greg Ungerer <gerg@snapgear.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Improve performance of the sske operation by using the nonquiescing
variant if the affected page has no mappings established. On machines
with no support for the new sske variant the mask bit will be ignored.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6: (49 commits)
serial8250: ratelimit "too much work" error
serial: bfin_sport_uart: speed up sport RX sample rate to be 3% faster
serial: abstraction for 8250 legacy ports
serial/imx: check that the buffer is non-empty before sending it out
serial: mfd: add more baud rates support
jsm: Remove the uart port on errors
Alchemy: Add UART PM methods.
8250: allow platforms to override PM hook.
altera_uart: Don't use plain integer as NULL pointer
altera_uart: Fix missing prototype for registering an early console
altera_uart: Fixup type usage of port flags
altera_uart: Make it possible to use Altera UART and 8250 ports together
altera_uart: Add support for different address strides
altera_uart: Add support for getting mapbase and IRQ from resources
altera_uart: Add support for polling mode (IRQ-less)
serial: Factor out uart_poll_timeout() from 8250 driver
serial: mark the 8250 driver as maintained
serial: 8250: Don't delay after transmitter is ready.
tty: MAINTAINERS: add drivers/serial/jsm/ as maintained driver
vcs: invoke the vt update callback when /dev/vcs* is written to
...
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
percpu: update comments to reflect that percpu allocations are always zero-filled
percpu: Optimize __get_cpu_var()
x86, percpu: Optimize this_cpu_ptr
percpu: clear memory allocated with the km allocator
percpu: fix build breakage on s390 and cleanup build configuration tests
percpu: use percpu allocator on UP too
percpu: reduce PCPU_MIN_UNIT_SIZE to 32k
vmalloc: pcpu_get/free_vm_areas() aren't needed on UP
Fixed up trivial conflicts in include/linux/percpu.h
* 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
This patch converts cris to use asm-generic/ioctls.h instead of its
own version.
The differences between the arch-specific version and the generic
version are as follows:
- CRIS defines two ioctls: TIOCSERSETRS485 and TIOCSERWRRS485,
kept in arch-specific portion
- CRIS defines a different value for TIOCSRS485, kept via ifndef in generic
- The generic version adds support for termiox
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-2.6-irqflags:
Fix IRQ flag handling naming
MIPS: Add missing #inclusions of <linux/irq.h>
smc91x: Add missing #inclusion of <linux/irq.h>
Drop a couple of unnecessary asm/system.h inclusions
SH: Add missing consts to sys_execve() declaration
Blackfin: Rename IRQ flags handling functions
Blackfin: Add missing dep to asm/irqflags.h
Blackfin: Rename DES PC2() symbol to avoid collision
Blackfin: Split the BF532 BFIN_*_FIO_FLAG() functions to their own header
Blackfin: Split PLL code from mach-specific cdef headers
* 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86-32, percpu: Correct the ordering of the percpu readmostly section
x86, mm: Enable ARCH_DMA_ADDR_T_64BIT with X86_64 || HIGHMEM64G
x86: Spread tlb flush vector between nodes
percpu: Introduce a read-mostly percpu API
x86, mm: Fix incorrect data type in vmalloc_sync_all()
x86, mm: Hold mm->page_table_lock while doing vmalloc_sync
x86, mm: Fix bogus whitespace in sync_global_pgds()
x86-32: Fix sparse warning for the __PHYSICAL_MASK calculation
x86, mm: Add RESERVE_BRK_ARRAY() helper
mm, x86: Saving vmcore with non-lazy freeing of vmas
x86, kdump: Change copy_oldmem_page() to use cached addressing
x86, mm: fix uninitialized addr in kernel_physical_mapping_init()
x86, kmemcheck: Remove double test
x86, mm: Make spurious_fault check explicitly check the PRESENT bit
x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes
x86, mm: Separate x86_64 vmalloc_sync_all() into separate functions
x86, mm: Avoid unnecessary TLB flush
Add a new readmostly percpu section and API. This can be used to
avoid dirtying data lines which are generally not written to, which is
especially important for data which may be accessed by processors
other than the one for which the percpu area belongs to.
[ hpa: moved it *after* the page-aligned section, for obvious
reasons. ]
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
LKML-Reference: <1287544022.4571.7.camel@sli10-conroe.sh.intel.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
For the Blackfin port, we can use much of the asm-generic/io.h header,
but we still need to declare some of our own versions of functions.
Like the __raw_read* and in/out "string" helpers. So let people do
this easily for many of these funcs.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
If CONFIG_GENERIC_FIND_NEXT_BIT is enabled, find_next_bit() and
find_next_zero_bit() are doubly declared in asm-generic/bitops/find.h
and linux/bitops.h.
asm/bitops.h includes asm-generic/bitops/find.h if and only if the
architecture enables CONFIG_GENERIC_FIND_NEXT_BIT. And asm/bitops.h
is included by linux/bitops.h
So we can just remove the extern declarations of find_next_bit() and
find_next_zero_bit() in linux/bitops.h.
Also we can remove unneeded #ifndef CONFIG_GENERIC_FIND_NEXT_BIT in
asm-generic/bitops/find.h.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
asm-generic/bitops/find.h has the extern declarations of find_next_bit()
and find_next_zero_bit() and the macro definitions of find_first_bit()
and find_first_zero_bit(). It is only usable by the architectures which
enables CONFIG_GENERIC_FIND_NEXT_BIT and disables
CONFIG_GENERIC_FIND_FIRST_BIT.
x86 and tile enable both CONFIG_GENERIC_FIND_NEXT_BIT and
CONFIG_GENERIC_FIND_FIRST_BIT. These architectures cannot include
asm-generic/bitops/find.h in their asm/bitops.h. So ifdefed extern
declarations of find_first_bit and find_first_zero_bit() are put in
linux/bitops.h.
This makes asm-generic/bitops/find.h usable by these architectures
and use it. Also this change is needed for the forthcoming duplicated
extern declarations cleanup.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Chris Metcalf <cmetcalf@tilera.com>
All 'pid_t' were changed to '__kernel_pid_t' in a previous commit:
make exported headers use strict posix types
A number of standard posix types are used in exported headers,
which is not allowed if __STRICT_KERNEL_NAMES is defined. In order
to get rid of the non-__STRICT_KERNEL_NAMES part and to make sane
headers the default, we have to change them all to safe types.
but a later change introduced 'pid_t' again:
fcntl: add F_[SG]ETOWN_EX
This makes asm-generic/fcntl.h d use strict posix types again.
Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The version of cmpxchg defined in asm-generic/system.h does not handle
correctly non-long arguments. Use the version defined in cmpxchg.h
instead.
Signed-off-by: Mathieu Lacage <mathieu.lacage@inria.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
