1. 07 2月, 2008 2 次提交
    • I
      x86: fix deadlock, make pgd_lock irq-safe · 58d5d0d8
      Ingo Molnar 提交于
      lockdep just caught this one:
      
      =================================
      [ INFO: inconsistent lock state ]
      2.6.24 #38
      ---------------------------------
      inconsistent {in-softirq-W} -> {softirq-on-W} usage.
      swapper/1 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (pgd_lock){-+..}, at: [<ffffffff8022a9ea>] mm_init+0x1da/0x250
      {in-softirq-W} state was registered at:
        [<ffffffffffffffff>] 0xffffffffffffffff
      irq event stamp: 394559
      hardirqs last  enabled at (394559): [<ffffffff80267f0a>] get_page_from_freelist+0x30a/0x4c0
      hardirqs last disabled at (394558): [<ffffffff80267d25>] get_page_from_freelist+0x125/0x4c0
      softirqs last  enabled at (393952): [<ffffffff80232f8e>] __do_softirq+0xce/0xe0
      softirqs last disabled at (393945): [<ffffffff8020c57c>] call_softirq+0x1c/0x30
      
      other info that might help us debug this:
      no locks held by swapper/1.
      
      stack backtrace:
      Pid: 1, comm: swapper Not tainted 2.6.24 #38
      
      Call Trace:
       [<ffffffff8024e1fb>] print_usage_bug+0x18b/0x190
       [<ffffffff8024f55d>] mark_lock+0x53d/0x560
       [<ffffffff8024fffa>] __lock_acquire+0x3ca/0xed0
       [<ffffffff80250ba8>] lock_acquire+0xa8/0xe0
       [<ffffffff8022a9ea>] ? mm_init+0x1da/0x250
       [<ffffffff809bcd10>] _spin_lock+0x30/0x70
       [<ffffffff8022a9ea>] mm_init+0x1da/0x250
       [<ffffffff8022aa99>] mm_alloc+0x39/0x50
       [<ffffffff8028b95a>] bprm_mm_init+0x2a/0x1a0
       [<ffffffff8028d12b>] do_execve+0x7b/0x220
       [<ffffffff80209776>] sys_execve+0x46/0x70
       [<ffffffff8020c214>] kernel_execve+0x64/0xd0
       [<ffffffff8020901e>] ? _stext+0x1e/0x20
       [<ffffffff802090ba>] init_post+0x9a/0xf0
       [<ffffffff809bc5f6>] ? trace_hardirqs_on_thunk+0x35/0x3a
       [<ffffffff8024f75a>] ? trace_hardirqs_on+0xba/0xd0
       [<ffffffff8020c1a8>] ? child_rip+0xa/0x12
       [<ffffffff8020bcbc>] ? restore_args+0x0/0x44
       [<ffffffff8020c19e>] ? child_rip+0x0/0x12
      
      turns out that pgd_lock has been used on 64-bit x86 in an irq-unsafe
      way for almost two years, since commit 8c914cb7.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      58d5d0d8
    • T
      x86: make spurious fault handler aware of large mappings · d8b57bb7
      Thomas Gleixner 提交于
      In very rare cases, on certain CPUs, we could end up in the spurious
      fault handler and ignore a large pud/pmd mapping. The resulting pte
      pointer points into the mapped physical space and dereferencing it
      will fault recursively.
      
      Make the code aware of large mappings and do the permission check
      on the pmd/pud entry, when a large pud/pmd mapping is detected.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d8b57bb7
  2. 04 2月, 2008 2 次提交
  3. 02 2月, 2008 1 次提交
  4. 30 1月, 2008 31 次提交
  5. 25 10月, 2007 1 次提交
  6. 20 10月, 2007 3 次提交