1. 22 Nov, 2006 14 commits
  2. 21 Nov, 2006 5 commits
  3. 20 Nov, 2006 10 commits
  4. 19 Nov, 2006 1 commit
  5. 18 Nov, 2006 3 commits
  6. 17 Nov, 2006 7 commits
    • 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
      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: default avatarLinus Torvalds <torvalds@osdl.org>
      808dbbb6
    • 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>
      1ff56830
    • 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>
      dc1829a4
    • 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>
      0796bdb7
    • 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>
      1d08811d
    • Linus Torvalds's avatar
      Fix generic fb_ddc i2c edid probe msg · 4be70390
      Linus Torvalds authored
      Benh points out that the msgs[0].flags entry never got initialized, and
      since it's an automatic stack allocation, it could have any random
      value, which is bad.
      
      Rewrite the initializer to explicitly initialize all fields of the small
      i2c_msg structure array we generate.  Just to keep it all obvious, let's
      handle msgs[1].buf in the same initializer while we're at it, instead of
      initializing that one separately later.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4be70390
    • Benjamin Herrenschmidt's avatar
      [PATCH] Fix radeon DDC regression · 4f71c5de
      Benjamin Herrenschmidt authored
      When radeonfb was changed to use the new "generic" ddc, a bit of
      code initializing the GPIO lines was lost, causing it to not work
      if the firmware didn't configure them properly, which seems to
      happen on some cards.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4f71c5de