1. 06 3月, 2014 1 次提交
    • 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
  2. 04 3月, 2014 25 次提交
  3. 21 2月, 2014 2 次提交
  4. 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
  5. 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
  6. 30 1月, 2014 4 次提交
  7. 29 1月, 2014 1 次提交
  8. 24 1月, 2014 2 次提交
  9. 22 1月, 2014 3 次提交
反馈
建议
客服 返回
顶部