1. 17 Nov, 2006 8 commits
    • Linus Torvalds's avatar
    • David Weinehall's avatar
      [PATCH] Update my CREDITS entry · ba9b1cd7
      David Weinehall authored
      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: default avatarDavid Weinehall <tao@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Linus Torvalds's avatar
      Revert "ACPI: created a dedicated workqueue for notify() execution" · b976fe19
      Linus Torvalds authored
      This reverts commit 37605a69.
      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
      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: default avatarLinus Torvalds <torvalds@osdl.org>
    • Linus Torvalds's avatar
      x86: be more careful when walking back the frame pointer chain · 808dbbb6
      Linus Torvalds authored
      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
      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: default avatarLinus Torvalds <torvalds@osdl.org>
    • Ingo Molnar's avatar
      [PATCH] lockdep: fix static keys in module-allocated percpu areas · 1ff56830
      Ingo Molnar authored
      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: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Ingo Molnar's avatar
      [PATCH] i386/x86_64: ACPI cpu_idle_wait() fix · dc1829a4
      Ingo Molnar authored
      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: default avatarIngo 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: default avatarLinus Torvalds <torvalds@osdl.org>
    • Ingo Molnar's avatar
      [PATCH] x86_64: stack unwinder crash fix · 0796bdb7
      Ingo Molnar authored
      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: default avatarIngo 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: default avatarLinus Torvalds <torvalds@osdl.org>
    • Jan-Benedict Glaw's avatar
      lkkbd: Remove my old snail-mail address · 1d08811d
      Jan-Benedict Glaw authored
      I moved to a different town and my old snail-mail address is invalid
      now.  Also, there's no need at all to have any address like that in
      the sources, so remove it completely.
      Signed-off-by: default avatarJan-Benedict Glaw <jbglaw@lug-owl.de>
  2. 16 Nov, 2006 32 commits