1. 20 11月, 2006 1 次提交
  2. 18 11月, 2006 7 次提交
    • L
      e030f829
    • D
      [PATCH] Update my CREDITS entry · ba9b1cd7
      David Weinehall 提交于
      I moved from Sweden to Finland 2.5 years ago, thought it might be time
      to update my CREDITS entry (simply removing the address completely
      seemed the sanest option).
      Signed-off-by: NDavid Weinehall <tao@kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ba9b1cd7
    • L
      Revert "ACPI: created a dedicated workqueue for notify() execution" · b976fe19
      Linus Torvalds 提交于
      This reverts commit 37605a69.
      
      Again.
      
      This same bug has now been introduced twice: it was done earlier by
      commit b8d35192, only to be reverted
      last time in commit 72945b2b.
      
      We must NOT try to queue up notify handlers to another thread than the
      normal ACPI execution thread, because the notifications on some systems
      seem to just keep on accumulating until we run out of memory and/or
      threads.
      
      Keeping events within the one deferred execution thread automatically
      throttles the events properly.
      
      At least the Compaq N620c will lock up completely on the first thermal
      event without this patch reverted.
      
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b976fe19
    • L
      x86: be more careful when walking back the frame pointer chain · 808dbbb6
      Linus Torvalds 提交于
      When showing the stack backtrace, make sure that we never accept not
      only an unchanging frame pointer, but also a frame pointer that moves
      back down the stack frame.  It must always grow up (toward older stack
      frames).
      
      I doubt this has triggered, but a subtly corrupt stack with extremely
      unlucky contents could cause us to loop forever on a bogus endless frame
      pointer chain.
      
      This review was triggered by much worse problems happening in some of
      the other stack unwinding code.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      808dbbb6
    • I
      [PATCH] lockdep: fix static keys in module-allocated percpu areas · 1ff56830
      Ingo Molnar 提交于
      lockdep got confused by certain locks in modules:
      
       INFO: trying to register non-static key.
       the code is fine but needs lockdep annotation.
       turning off the locking correctness validator.
      
       Call Trace:
        [<ffffffff8026f40d>] dump_trace+0xaa/0x3f2
        [<ffffffff8026f78f>] show_trace+0x3a/0x60
        [<ffffffff8026f9d1>] dump_stack+0x15/0x17
        [<ffffffff802abfe8>] __lock_acquire+0x724/0x9bb
        [<ffffffff802ac52b>] lock_acquire+0x4d/0x67
        [<ffffffff80267139>] rt_spin_lock+0x3d/0x41
        [<ffffffff8839ed3f>] :ip_conntrack:__ip_ct_refresh_acct+0x131/0x174
        [<ffffffff883a1334>] :ip_conntrack:udp_packet+0xbf/0xcf
        [<ffffffff8839f9af>] :ip_conntrack:ip_conntrack_in+0x394/0x4a7
        [<ffffffff8023551f>] nf_iterate+0x41/0x7f
        [<ffffffff8025946a>] nf_hook_slow+0x64/0xd5
        [<ffffffff802369a2>] ip_rcv+0x24e/0x506
        [...]
      
      Steven Rostedt found the bug: static_obj() check did not take
      PERCPU_ENOUGH_ROOM into account, so in-module DEFINE_PER_CPU-area locks
      were triggering this message.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1ff56830
    • I
      [PATCH] i386/x86_64: ACPI cpu_idle_wait() fix · dc1829a4
      Ingo Molnar 提交于
      The scheduler on Andreas Friedrich's hyperthreading system stopped
      working properly: the scheduler would never move tasks to another CPU!
      The lask known working kernel was 2.6.8.
      
      After a couple of attempts to corner the bug, the following smoking gun
      was found:
      
        BIOS reported wrong ACPI idfor the processor
        CPU#1: set_cpus_allowed(), swapper:1, 3 -> 2
         [<c0103bbe>] show_trace_log_lvl+0x34/0x4a
         [<c0103ceb>] show_trace+0x2c/0x2e
         [<c01045f8>] dump_stack+0x2b/0x2d
         [<c0116a77>] set_cpus_allowed+0x52/0xec
         [<c0101d86>] cpu_idle_wait+0x2e/0x100
         [<c0259c57>] acpi_processor_power_exit+0x45/0x58
         [<c0259752>] acpi_processor_remove+0x46/0xea
         [<c025c6fb>] acpi_start_single_object+0x47/0x54
         [<c025cee5>] acpi_bus_register_driver+0xa4/0xd3
         [<c04ab2d7>] acpi_processor_init+0x57/0x77
         [<c01004d7>] init+0x146/0x2fd
         [<c0103a87>] kernel_thread_helper+0x7/0x10
      
      a quick look at cpu_idle_wait() shows how broken that code is
      on i386: it changes the init task's affinity map but never
      restores it ...
      
      and because all userspace tasks get forked by init, they all
      inherited that single-CPU affinity mask. x86_64 cloned this
      bug too.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Andreas Friedrich <andreas.friedrich@fujitsu-siemens.com>
      Cc: Wolfgang Erig <Wolfgang.Erig@fujitsu-siemens.com>
      Cc: Andrew Morton <akpm@osdl.org>
      Cc: Adrian Bunk <bunk@stusta.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dc1829a4
    • I
      [PATCH] x86_64: stack unwinder crash fix · 0796bdb7
      Ingo Molnar 提交于
      the new dwarf2 unwinder crashes while trying to dump the stack:
      
        Leftover inexact backtrace:
      
        Unable to handle kernel paging request at ffffffff82800000 RIP:
         [<ffffffff8026cf26>] dump_trace+0x35b/0x3d2
        PGD 203027 PUD 205027 PMD 0
        Oops: 0000 [2] PREEMPT SMP
        CPU 0
        Modules linked in:
        Pid: 30, comm: khelper Not tainted 2.6.19-rc6-rt1 #11
        RIP: 0010:[<ffffffff8026cf26>]  [<ffffffff8026cf26>] dump_trace+0x35b/0x3d2
        RSP: 0000:ffff81003fb9d848  EFLAGS: 00010006
        RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
        RDX: 0000000000000000 RSI: ffffffff805b3520 RDI: 0000000000000000
        RBP: ffffffff827ffff9 R08: ffffffff80aad000 R09: 0000000000000005
        R10: ffffffff80aae000 R11: ffffffff8037961b R12: ffff81003fb9d858
        R13: 0000000000000000 R14: ffffffff80598460 R15: ffffffff80ab1fc0
        FS:  0000000000000000(0000) GS:ffffffff806c4200(0000) knlGS:0000000000000000
        CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
        CR2: ffffffff82800000 CR3: 0000000000201000 CR4: 00000000000006e0
      
      this crash happened because it did not sanitize the dwarf2 data it
      got, and got an unaligned stack pointer - which happily walked past
      the process stack (and eventually reached the end of kernel memory
      and pagefaulted there) due to this naive iteration condition:
      
              HANDLE_STACK (((long) stack & (THREAD_SIZE-1)) != 0);
      
      note that i386 is alot more conservative when it comes to trusting
      stack pointers:
      
        static inline int valid_stack_ptr(struct thread_info *tinfo, void *p)
        {
               return  p > (void *)tinfo &&
                       p < (void *)tinfo + THREAD_SIZE - 3;
        }
      
      but the x86_64 code did not take this bit of i386 code.
      
      The fix is to align the stack pointer.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0796bdb7
  3. 17 11月, 2006 32 次提交