Starting with ARMv6, the CPUs support the BE-8 variant of big-endian
(byte-invariant). This patch adds the core support:

- setting of the BE-8 mode via the CPSR.E register for both kernel and
  user threads
- big-endian page table walking
- REV used to rotate instructions read from memory during fault
  processing as they are still little-endian format
- Kconfig and Makefile support for BE-8. The --be8 option must be passed
  to the final linking stage to convert the instructions to
  little-endian
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Commit 8ec53663 ("[ARM] Improve
non-executable support") added support for detecting non-executable
stack binaries.  One of the things it does is to make READ_IMPLIES_EXEC
be set in ->personality if we are running on a CPU that doesn't support
the XN ("Execute Never") page table bit or if we are running a binary
that needs an executable stack.

This exposed a latent bug in ARM's asm/processor.h due to which we'll
end up placing the stack at a very low address, where it will bump into
the heap on any application that uses significant amount of stack or
heap or both, causing many interesting crashes.

Fix this by testing the ADDR_LIMIT_32BIT bit in ->personality instead
of testing for equality against PER_LINUX_32BIT.
Reviewed-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As suggested by Andrew Morton, remove memzero() - it's not supported
on other architectures so use of it is a potential build breaking bug.
Since the compiler optimizes memset(x,0,n) to __memzero() perfectly
well, we don't miss out on the underlying benefits of memzero().
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

With gcc 4.3 and later, a pointer that has already been dereferenced is
assumed not to be null since it should have caused a segmentation fault
otherwise, hence any subsequent test against NULL is optimized away.

Current inline asm constraint used in the implementation of prefetch()
makes gcc believe that the pointer is dereferenced even though the PLD
instruction does not load any data and does not cause a segmentation
fault on null pointers, which causes all sorts of interesting results
when reaching the end of a linked lists for example.

Let's use a better constraint to properly represent the actual usage of
the pointer value.

Problem reported by Chris Steel.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Move platform independent header files to arch/arm/include/asm, leaving
those in asm/arch* and asm/plat* alone.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Move STACK_TOP[_MAX] out of asm/a.out.h and into asm/processor.h as they're
required whether or not A.OUT format is available.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

 optimization

The gcc manual says:

|`-fdelete-null-pointer-checks'
|     Use global dataflow analysis to identify and eliminate useless
|     checks for null pointers.  The compiler assumes that dereferencing
|     a null pointer would have halted the program.  If a pointer is
|     checked after it has already been dereferenced, it cannot be null.
|     Enabled at levels `-O2', `-O3', `-Os'.

Now the problem can be seen with this test case:

#include <linux/prefetch.h>
extern void bar(char *x);
void foo(char *x)
{
	prefetch(x);
	if (x)
		bar(x);
}

Because the constraint to the inline asm used in the prefetch() macro is
a memory operand, gcc assumes that the asm code does dereference the
pointer and the delete-null-pointer-checks optimization kicks in.
Inspection of generated assembly for the above example shows that bar()
is indeed called unconditionally without any test on the value of x.

Of course in the prefetch case there is no real dereference and it
cannot be assumed that a null pointer would have been caught at that
point. This causes kernel oopses with constructs like
hlist_for_each_entry() where the list's 'next' content is prefetched
before the pointer is tested against NULL, and only when gcc feels like
applying this optimization which doesn't happen all the time with more
complex code.

It appears that the way to prevent delete-null-pointer-checks
optimization to occur in this case is to make prefetch() into a static
inline function instead of a macro. At least this is what is done on
x86_64 where a similar inline asm memory operand is used (I presume they
would have seen the same problem if it didn't work) and resulting code
for the above example confirms that.

An alternative would consist of replacing the memory operand by a
register operand containing the pointer, and use the addressing mode
explicitly in the asm template. But that would be less optimal than an
offsettable memory reference.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

These files want to provide/access ELF hwcap information, so should
be including asm/elf.h rather than asm/procinfo.h
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch supports start_thread in nommu mode which requires the
base index register.
Signed-off-by: NHyok S. Choi <hyok.choi@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Various places in the ARM kernel implicitly assumed that kernel
stacks are always 8K due to hard coded constants.  Replace these
constants with definitions.

Correct the allowable range of kernel stack pointer values within
the allocation.  Arrange for the entire kernel stack to be zeroed,
not just the upper 4K if CONFIG_DEBUG_STACK_USAGE is set.
Signed-off-by: NRussell King <rmk@arm.linux.org.uk>

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!