1. 27 12月, 2011 6 次提交
    • M
      [S390] add support for physical memory > 4TB · 14045ebf
      Martin Schwidefsky 提交于
      The kernel address space of a 64 bit kernel currently uses a three level
      page table and the vmemmap array has a fixed address and a fixed maximum
      size. A three level page table is good enough for systems with less than
      3.8TB of memory, for bigger systems four page table levels need to be
      used. Each page table level costs a bit of performance, use 3 levels for
      normal systems and 4 levels only for the really big systems.
      To avoid bloating sparse.o too much set MAX_PHYSMEM_BITS to 46 for a
      maximum of 64TB of memory.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      14045ebf
    • M
    • M
      [S390] Rework create_mem_hole() function · 44e5ddc4
      Michael Holzheu 提交于
      This patch makes the create_mem_hole() function more readable and
      fixes some minor bugs (e.g. off-by-one problems).
      Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      44e5ddc4
    • C
      [S390] kvm: fix sleeping function ... at mm/page_alloc.c:2260 · c86cce2a
      Christian Borntraeger 提交于
      commit cc772456
          [S390] fix list corruption in gmap reverse mapping
      
      added a potential dead lock:
      
      BUG: sleeping function called from invalid context at mm/page_alloc.c:2260
      in_atomic(): 1, irqs_disabled(): 0, pid: 1108, name: qemu-system-s39
      3 locks held by qemu-system-s39/1108:
       #0:  (&kvm->slots_lock){+.+.+.}, at: [<000003e004866542>] kvm_set_memory_region+0x3a/0x6c [kvm]
       #1:  (&mm->mmap_sem){++++++}, at: [<0000000000123790>] gmap_map_segment+0x9c/0x298
       #2:  (&(&mm->page_table_lock)->rlock){+.+.+.}, at: [<00000000001237a8>] gmap_map_segment+0xb4/0x298
      CPU: 0 Not tainted 3.1.3 #45
      Process qemu-system-s39 (pid: 1108, task: 00000004f8b3cb30, ksp: 00000004fd5978d0)
      00000004fd5979a0 00000004fd597920 0000000000000002 0000000000000000
             00000004fd5979c0 00000004fd597938 00000004fd597938 0000000000617e96
             0000000000000000 00000004f8b3cf58 0000000000000000 0000000000000000
             000000000000000d 000000000000000c 00000004fd597988 0000000000000000
             0000000000000000 0000000000100a18 00000004fd597920 00000004fd597960
      Call Trace:
      ([<0000000000100926>] show_trace+0xee/0x144)
       [<0000000000131f3a>] __might_sleep+0x12a/0x158
       [<0000000000217fb4>] __alloc_pages_nodemask+0x224/0xadc
       [<0000000000123086>] gmap_alloc_table+0x46/0x114
       [<000000000012395c>] gmap_map_segment+0x268/0x298
       [<000003e00486b014>] kvm_arch_commit_memory_region+0x44/0x6c [kvm]
       [<000003e004866414>] __kvm_set_memory_region+0x3b0/0x4a4 [kvm]
       [<000003e004866554>] kvm_set_memory_region+0x4c/0x6c [kvm]
       [<000003e004867c7a>] kvm_vm_ioctl+0x14a/0x314 [kvm]
       [<0000000000292100>] do_vfs_ioctl+0x94/0x588
       [<0000000000292688>] SyS_ioctl+0x94/0xac
       [<000000000061e124>] sysc_noemu+0x22/0x28
       [<000003fffcd5e7ca>] 0x3fffcd5e7ca
      3 locks held by qemu-system-s39/1108:
       #0:  (&kvm->slots_lock){+.+.+.}, at: [<000003e004866542>] kvm_set_memory_region+0x3a/0x6c [kvm]
       #1:  (&mm->mmap_sem){++++++}, at: [<0000000000123790>] gmap_map_segment+0x9c/0x298
       #2:  (&(&mm->page_table_lock)->rlock){+.+.+.}, at: [<00000000001237a8>] gmap_map_segment+0xb4/0x298
      
      Fix this by freeing the lock on the alloc path. This is ok, since the
      gmap table is never freed until we call gmap_free, so the table we are
      walking cannot go.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c86cce2a
    • M
      [S390] Check for NULL termination in command line setup · 1fb81057
      Michael Holzheu 提交于
      The current code in setup_boot_command_line() uses a heuristic to
      detect an EBCDIC command line. It checks if any of the bytes in
      the command line has bit one (0x80) set. In that case it is assumed
      that we have an EBCDIC string and the complete command line is
      converted.
      
      On s390 there are cases where the boot loader provides a kernel
      command line that is NULL terminated, but has random data after
      the NULL termination. In that case, setup_boot_command_line()
      might misinterpret an ASCII string for an EBCDIC string. A
      subsequent string conversion can then damage the ASCII string.
      
      This patch solves the problem by checking for NULL termination.
      If no EBCDIC character has been found until the the NULL
      termination has been found, we now assume that we have an ASCII
      string.
      Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      1fb81057
    • H
      [S390] irq: fix accounting of external call/emergency signal · 272f01bf
      Heiko Carstens 提交于
      Mask the extint_code parameter of the smp external interrupt handler
      to get the interruption code. Otherwise emergency call interrupts
      erroneously might be accounted as emergency signal interrupts.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      272f01bf
  2. 20 12月, 2011 1 次提交
  3. 01 12月, 2011 5 次提交
  4. 17 11月, 2011 4 次提交
  5. 14 11月, 2011 9 次提交
  6. 03 11月, 2011 3 次提交
  7. 02 11月, 2011 3 次提交
  8. 01 11月, 2011 1 次提交
  9. 30 10月, 2011 8 次提交
新手
引导
客服 返回
顶部