1. 06 8月, 2009 10 次提交
  2. 30 7月, 2009 9 次提交
  3. 29 7月, 2009 1 次提交
  4. 28 7月, 2009 2 次提交
  5. 27 7月, 2009 16 次提交
  6. 24 7月, 2009 2 次提交
    • M
      [S390] vdso: clock_gettime of CLOCK_THREAD_CPUTIME_ID with noexec=on · 1277580f
      Martin Schwidefsky 提交于
      The combination of noexec=on and a clock_gettime call with clock id
      CLOCK_THREAD_CPUTIME_ID is broken. The vdso code switches to the
      access register mode to get access to the per-cpu data structure to
      execute the magic ectg instruction. After the ectg instruction the
      code always switches back to the primary mode but for noexec=on the
      correct mode is the secondary mode. The effect of the bug is that the
      user space program looses the access to all mappings without PROT_EXEC,
      e.g. the stack. The problem is fixed by restoring the mode that has
      been active before the switch to the access register mode.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      1277580f
    • H
      [S390] vdso: fix per cpu area allocation · 3a6ba460
      Heiko Carstens 提交于
      vdso per cpu area allocation in smp_prepare_cpus() happens with GFP_KERNEL
      but irqs disabled. Triggers this one:
      
      Badness at kernel/lockdep.c:2280
      Modules linked in:
      CPU: 0 Not tainted 2.6.30 #2
      Process swapper (pid: 1, task: 000000003fe88000, ksp: 000000003fe87eb8)
      Krnl PSW : 0400c00180000000 0000000000083360 (lockdep_trace_alloc+0xec/0xf8)
      [...]
      Call Trace:
      ([<00000000000832b6>] lockdep_trace_alloc+0x42/0xf8)
       [<00000000000b1880>] __alloc_pages_internal+0x3e8/0x5c4
       [<00000000000b1b4a>] __get_free_pages+0x3a/0xb0
       [<0000000000026546>] vdso_alloc_per_cpu+0x6a/0x18c
       [<00000000005eff82>] smp_prepare_cpus+0x322/0x594
       [<00000000005e8232>] kernel_init+0x76/0x398
       [<000000000001bb1e>] kernel_thread_starter+0x6/0xc
       [<000000000001bb18>] kernel_thread_starter+0x0/0xc
      
      Fix this by moving the allocation out of the irqs disabled section.
      Reported-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      3a6ba460