linux-stable.git/arch/arm64/include, branch v3.7

open*(2) compat fixes (s390, arm64)

2012-12-02T18:46:38+00:00

The usual rules for open()/openat()/open_by_handle_at() are
 1) native 32bit - don't force O_LARGEFILE in flags
 2) native 64bit - force O_LARGEFILE in flags
 3) compat on 64bit host - as for native 32bit
 4) native 32bit ABI for 64bit system (mips/n32, x86/x32) - as for
    native 64bit

There are only two exceptions - s390 compat has open() forcing
O_LARGEFILE and arm64 compat has open_by_handle_at() doing the same
thing.  The same binaries on native host (s390/31 and arm resp.) will
*not* force O_LARGEFILE, so IMO both are emulation bugs.

Objections? The fix is obvious...

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

arm64: Distinguish between user and kernel XN bits

2012-11-16T15:50:25+00:00

On AArch64, the meaning of the XN bit has changed to UXN (user). The PXN
(privileged) bit must be set to prevent kernel execution. Without the
PXN bit set, the CPU may speculatively access device memory. This patch
ensures that all the mappings that the kernel must not execute from
(including user mappings) have the PXN bit set.

Signed-off-by: Catalin Marinas

arm64: mm: fix booting on systems with no memory below 4GB

2012-11-08T16:06:21+00:00

Booting on a system with all of its memory above the 4GB boundary breaks
for two reasons:

	(1) We still try to create a non-empty DMA32 zone
	(2) no-bootmem limits allocations to 0xffffffff

This patch fixes these issues for ARM64.

Tested-by: Marc Zyngier 
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas

arm64: compat: select CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION

2012-11-08T16:06:20+00:00

Commit c1d7e01d7877 ("ipc: use Kconfig options for
__ARCH_WANT_[COMPAT_]IPC_PARSE_VERSION") replaced the
__ARCH_WANT_COMPAT_IPC_PARSE_VERSION token with a corresponding Kconfig
option instead.

This patch updates arm64 to use the latter, rather than #define an
unused token.

Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas

arm64: elf: fix core dumping definitions for GP and FP registers

2012-11-08T16:06:20+00:00

struct user_fp does not exist for arm64, so use struct user_fpsimd_state
instead for the ELF core dumping definitions. Furthermore, since we use
regset-based core dumping, we do not need definitions for dump_task_regs
and dump_fpu.

Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas

arm64: Move PCI_IOBASE closer to MODULES_VADDR

2012-10-23T14:30:51+00:00

This is to reuse the same pmd table that is sparsely populated with
the modules space.

Signed-off-by: Catalin Marinas

arm64: Use pgprot_t as the last argument when invoking __ioremap()

2012-10-23T14:30:47+00:00

Even if it works with since the types have the same size, the correct
type of the last __ioremap() argument is pgprot_t rather than pteval_t.

Signed-off-by: Catalin Marinas

arm64: fix alignment padding in assembly code

2012-10-20T10:12:01+00:00

An interesting effect of using the generic version of linkage.h
is that the padding is defined in terms of x86 NOPs, which can have
even more interesting effects when the assembly code looks like this:

ENTRY(func1)
	mov	x0, xzr
ENDPROC(func1)
	// fall through
ENTRY(func2)
	mov	x0, #1
	ret
ENDPROC(func2)

Admittedly, the code is not very nice. But having code from another
architecture doesn't look completely sane either.

The fix is to add arm64's version of linkage.h, which causes the insertion
of proper AArch64 NOPs.

Signed-off-by: Marc Zyngier 
Signed-off-by: Catalin Marinas

arm64: ptrace: make structure padding explicit for debug registers

2012-10-18T19:15:31+00:00

The user_hwdebug_state structure contains implicit padding to conform to
the alignment requirements of the AArch64 ABI (namely that aggregates
must be aligned to their most aligned member).

This patch fixes the ptrace functions operating on struct
user_hwdebug_state so that the padding is handled correctly.

Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas

arm64: No need to set the x0-x2 registers in start_thread()

2012-10-18T19:14:01+00:00

For historical reasons, ARM used to set r0-r2 in start_thread() to the
first values on the user stack when starting a new user application. The
same logic has been inherited in AArch64. The x0 register is overridden
by the sys_execve() return value so it's always zero on success. The x1
and x2 registers are ignored by AArch64 and EABI AArch32 applications,
so we can safely remove the register setting for both native and compat
user space.

This also fixes a potential fault with the kernel accessing user space
stack directly.

Signed-off-by: Catalin Marinas 
Reported-by: Al Viro