linux-toradex.git/arch/parisc/include, branch v3.14.26

parisc: Use compat layer for msgctl, shmat, shmctl and semtimedop syscalls

2014-11-21T17:23:03+00:00

commit 2fe749f50b0bec07650ef135b29b1f55bf543869 upstream.

Switch over the msgctl, shmat, shmctl and semtimedop syscalls to use the compat
layer. The problem was found with the debian procenv package, which called
	shmctl(0, SHM_INFO, &info);
in which the shmctl syscall then overwrote parts of the surrounding areas on
the stack on which the info variable was stored and thus lead to a segfault
later on.

Additionally fix the definition of struct shminfo64 to use unsigned longs like
the other architectures. This has no impact on userspace since we only have a
32bit userspace up to now.

Signed-off-by: Helge Deller 
Cc: John David Anglin 
Signed-off-by: Greg Kroah-Hartman

parisc: Remove SA_RESTORER define

2014-07-31T19:52:56+00:00

commit 20dbea494543aefaace874cc3ec93a39b94b1ec4 upstream.

The sa_restorer field in struct sigaction is obsolete and no longer in
the parisc implementation.  However, the core code assumes the field is
present if SA_RESTORER is defined. So, the define needs to be removed.

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc,metag: Do not hardcode maximum userspace stack size

2014-07-17T23:21:03+00:00

commit 042d27acb64924a0e8a43e972485913a32407beb upstream.

This patch affects only architectures where the stack grows upwards
(currently parisc and metag only). On those do not hardcode the maximum
initial stack size to 1GB for 32-bit processes, but make it configurable
via a config option.

The main problem with the hardcoded stack size is, that we have two
memory regions which grow upwards: stack and heap. To keep most of the
memory available for heap in a flexmap memory layout, it makes no sense
to hard allocate up to 1GB of the memory for stack which can't be used
as heap then.

This patch makes the stack size for 32-bit processes configurable and
uses 80MB as default value which has been in use during the last few
years on parisc and which hasn't showed any problems yet.

Signed-off-by: Helge Deller 
Signed-off-by: James Hogan 
Cc: "James E.J. Bottomley" 
Cc: linux-parisc@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin 
Signed-off-by: Greg Kroah-Hartman

metag: Reduce maximum stack size to 256MB

2014-06-07T17:28:23+00:00

commit d71f290b4e98a39f49f2595a13be3b4d5ce8e1f1 upstream.

Specify the maximum stack size for arches where the stack grows upward
(parisc and metag) in asm/processor.h rather than hard coding in
fs/exec.c so that metag can specify a smaller value of 256MB rather than
1GB.

This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased
beyond a safe value by root. E.g. when starting a process after running
"ulimit -H -s unlimited" it will then attempt to use a stack size of the
maximum 1GB which is far too big for metag's limited user virtual
address space (stack_top is usually 0x3ffff000):

BUG: failure at fs/exec.c:589/shift_arg_pages()!

Signed-off-by: James Hogan 
Cc: Helge Deller 
Cc: "James E.J. Bottomley" 
Cc: linux-parisc@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin 
Signed-off-by: Greg Kroah-Hartman

parisc: remove _STK_LIM_MAX override

2014-05-31T20:20:29+00:00

commit e0d8898d76a785453bfaf6cd08b830a7d5189f78 upstream.

There are only a couple of architectures that override _STK_LIM_MAX to
a non-infinity value. This changes the stack allocation semantics in
subtle ways. For example, GNU make changes its stack allocation to the
hard maximum defined by _STK_LIM_MAX. As a results, threads executed
by processes running under make are allocated a stack size of
_STK_LIM_MAX rather than a sensible default value. This causes various
thread stress tests to fail when they can't muster more than about 50
threads.

The attached change implements the default behavior used by the
majority of architectures.

Signed-off-by: John David Anglin 
Reviewed-by: Carlos O'Donell 
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc: change value of SHMLBA from 0x00400000 to PAGE_SIZE

2014-05-31T20:20:28+00:00

commit 0ef36bd2b37815719e31a72d2beecc28ca8ecd26 upstream.

On parisc, SHMLBA was defined to 0x00400000 (4MB) to reflect that we need to
take care of our caches for shared mappings. But actually, we can map a file at
any multiple address of PAGE_SIZE, so let us correct that now with a value of
PAGE_SIZE for SHMLBA.  Instead we now take care of this cache colouring via the
constant SHM_COLOUR while we map shared pages.

Signed-off-by: Helge Deller 
CC: Jeroen Roovers 
CC: John David Anglin 
CC: Carlos O'Donell 
Signed-off-by: Greg Kroah-Hartman

parisc: locks: remove redundant arch_*_relax operations

2014-03-23T16:01:23+00:00

Now that the arch_{spin,read,write}_relax macros default to cpu_relax(),
remove the redundant definitions for parisc.

Cc: Helge Deller 
Signed-off-by: Will Deacon 
Signed-off-by: Helge Deller

parisc: wire up sys_utimes

2014-03-23T15:57:13+00:00

We seem to be nearly the only platform which does not provide the
sys_utimes syscall.  Adding it now makes our life much easier with
userspace applications (like dietlibc and e2fsprogs) since we then
behave like all other platforms too and don't need extra patches which
are hard to get upstream anyway because we are not a mainstream
architecture.

Signed-off-by: Helge Deller 
Cc: stable@vger.kernel.org # v3.13

parisc: Remove unused CONFIG_PARISC_TMPALIAS code

2014-03-23T15:46:30+00:00

The attached change removes the unused and experimental
CONFIG_PARISC_TMPALIAS code. It doesn't work and I don't believe it will
ever be used.

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller

parisc: add flexible mmap memory layout support

2014-02-02T20:00:13+00:00

Add support for the flexible mmap memory layout (as described in
http://lwn.net/Articles/91829). This is especially very interesting on
parisc since we currently only support 32bit userspace (even with a
64bit Linux kernel).

Signed-off-by: Helge Deller