BMC/Intel-BMC/linux.git/arch/s390/include/asm/compat.h, branch dev

s390/compat: build error for large compat syscall args

2014-03-06T15:30:47+00:00

Enforce 32 bit types for all compat syscall argument types. This way we can make sure that all arguments get correct sign or zero extension. Otherwise incorrect code would be generated. E.g. for a 'long' type the COMPAT_SYSCALL_DEFINE macro wouldn't generate code that would cause sign extension of the passed in 32 bit user space parameter. This can cause quite subtle bugs like e.g. the one that was fixed with dfd948e32af2e "fs/compat: fix parameter handling for compat readv/writev syscalls". Signed-off-by: Heiko Carstens

fs/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types

2014-03-06T15:30:44+00:00

Some fs compat system calls have unsigned long parameters instead of compat_ulong_t. In order to allow the COMPAT_SYSCALL_DEFINE macro generate code that performs proper zero and sign extension convert all 64 bit parameters their corresponding 32 bit counterparts. compat_sys_io_getevents() is a bit different: the non-compat version has signed parameters for the "min_nr" and "nr" parameters while the compat version has unsigned parameters. So change this as well. For all practical purposes this shouldn't make any difference (doesn't fix a real bug). Also introduce a generic compat_aio_context_t type which can be used everywhere. The access_ok() check within compat_sys_io_getevents() got also removed since the non-compat sys_io_getevents() should be able to handle everything anyway. Signed-off-by: Heiko Carstens

s390/compat: convert system call wrappers to C part 11

2014-03-04T08:05:44+00:00

Signed-off-by: Heiko Carstens

s390/compat: fix PSW32_USER_BITS definition

2014-01-13T15:50:21+00:00

PSW32_USER_BITS should define the primary address space for user space instead of the home address space. Symptom of this bug is that gdb doesn't work in compat mode. The bug was introduced with e258d719ff28 "s390/uaccess: always run the kernel in home space" and f26946d7ecad "s390/compat: make psw32_user_bits a constant value again". Cc: stable@vger.kernel.org # v3.13+ Reported-by: Andreas Arnez Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky

s390/compat: make psw32_user_bits a constant value again

2013-10-24T15:17:12+00:00

Make psw32_user_bits a constant value again. This is a leftover of the code which allowed to run the kernel either in primary or home space which got removed with 9a905662 "s390/uaccess: always run the kernel in home space". Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky

s390: fix handling of runtime instrumentation psw bit

2013-10-24T15:17:11+00:00

Fix the following bugs: - When returning from a signal the signal handler copies the saved psw mask from user space and uses parts of it. Especially it restores the RI bit unconditionally. If however the machine doesn't support RI, or RI is disabled for the task, the last lpswe instruction which returns to user space will generate a specification exception. To fix this check if the RI bit is allowed to be set and kill the task if not. - In the compat mode signal handler code the RI bit of the psw mask gets propagated to the mask of the return psw: if user space enables RI in the signal handler, RI will also be enabled after the signal handler is finished. This is a different behaviour than with 64 bit tasks. So change this to match the 64 bit semantics, which restores the original RI bit value. - Fix similar oddities within the ptrace code as well. Reviewed-by: Martin Schwidefsky Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky

s390/uapi: change struct statfs[64] member types to unsigned values

2013-04-23T08:18:18+00:00

Kay Sievers reported that coreutils' stat tool has a problem with s390's statfs[64] definition: > The definition of struct statfs::f_type needs a fix. s390 is the only > architecture in the kernel that uses an int and expects magic > constants lager than INT_MAX to fit into. > > A fix is needed to make Fedora boot on s390, it currently fails to do > so. Userspace does not want to add code to paper-over this issue. [...] > Even coreutils cannot handle it: > #define RAMFS_MAGIC 0x858458f6 > # stat -f -c%t / > ffffffff858458f6 > > #define BTRFS_SUPER_MAGIC 0x9123683E > # stat -f -c%t /mnt > ffffffff9123683e The bug is caused by an implicit sign extension within the stat tool: out_uint_x (pformat, prefix_len, statfsbuf->f_type); where the format finally will be "%lx". A similar problem can be found in the 'tail' tool. s390 is the only architecture which has an int type f_type member in struct statfs[64]. Other architectures have either unsigned ints or long values, so that the problem doesn't occur there. Therefore change the type of the f_type member to unsigned int, so that we get zero extension instead of sign extension when assignment to a long value happens. This patch changes the s390 uapi struct stafs[64] definition in the kernel to contain only unsigned values. This was true for 32 bit builds anyway, since we use the generic uapi header file in that case. So lets not include conditionally the generic uapi header file but have the s390 implementation completely independent. Also fix the types of struct compat_stafs to match reality and move the definition of struct compat_statfs64 to asm/compat.h since it is not part of the api. Reported-by: Kay Sievers Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky

s390/compat: remove ptrace compat definitions from uapi header file

2013-04-23T08:18:12+00:00

The compat definitions are not part of the uapi. So move them to s390's private compat header file. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky

s390/compat: fix compile error for !COMPAT

2013-04-23T08:18:10+00:00

Fix this one for !COMPAT: compat.h: In function ‘arch_compat_alloc_user_space’: compat.h:292:2: error: implicit declaration of function ‘is_compat_task’ Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky

s390/compat: fix compat_sys_statfs() memory corruption

2013-04-23T08:18:09+00:00

The f_spare field within struct compat_statfs is four bytes larger than within the native 31 bit struct statfs. compat_sys_statfs() clears the f_spare field in user space which means that in compat mode four bytes that are behind the user space supplied struct compat_statfs will be corrupted (zeroed). According to Thomas Gleixner's Linux 2.6 history tree this bug is present since v2.5.74 87880da124 "[PATCH] s390: 31 bit compat.". So it get's fixed shortly before its 10th anniversary. Tough luck. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky