Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 06 3月, 2014 2 次提交
    • H
      s390/compat: build error for large compat syscall args · 9a205286
      由 Heiko Carstens 提交于 
      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 dfd948e3 "fs/compat: fix parameter handling for compat
readv/writev syscalls".
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      9a205286
    • H
      fs/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types · 932602e2
      由 Heiko Carstens 提交于 
      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: NHeiko Carstens <heiko.carstens@de.ibm.com>
      932602e2
  3. 04 3月, 2014 25 次提交
  5. 21 2月, 2014 2 次提交
  7. 05 2月, 2014 1 次提交
    • M
      s390: fix kernel crash due to linkage stack instructions · 8d7f6690
      由 Martin Schwidefsky 提交于 
      The kernel currently crashes with a low-address-protection exception
if a user space process executes an instruction that tries to use the
linkage stack. Set the base-ASTE origin and the subspace-ASTE origin
of the dispatchable-unit-control-table to point to a dummy ASTE.
Set up control register 15 to point to an empty linkage stack with no
room left.

A user space process with a linkage stack instruction will still crash
but with a different exception which is correctly translated to a
segmentation fault instead of a kernel oops.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      8d7f6690
  9. 04 2月, 2014 1 次提交
    • M
      s390/dump: Fix dump memory detection · d7736ff5
      由 Michael Holzheu 提交于 
      Dumps created by kdump or zfcpdump can contain invalid memory holes when
dumping z/VM systems that have memory pressure.

For example:

   # zgetdump -i /proc/vmcore.
   Memory map:
   0000000000000000 - 0000000000bfffff (12 MB)
   0000000000e00000 - 00000000014fffff (7 MB)
   000000000bd00000 - 00000000f3bfffff (3711 MB)

The memory detection function find_memory_chunks() issues tprot to
find valid memory chunks. In case of CMM it can happen that pages are
marked as unstable via set_page_unstable() in arch_free_page().
If z/VM has released that pages, tprot returns -EFAULT and indicates
a memory hole.

So fix this and switch off CMM in case of kdump or zfcpdump.

Cc: <stable@vger.kernel.org>
Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      d7736ff5
  11. 30 1月, 2014 4 次提交
  13. 29 1月, 2014 1 次提交
  15. 24 1月, 2014 2 次提交
  17. 22 1月, 2014 2 次提交