1. 03 12月, 2009 1 次提交
  2. 28 11月, 2009 1 次提交
  3. 20 11月, 2009 1 次提交
    • T
      x86: Prevent GCC 4.4.x (pentium-mmx et al) function prologue wreckage · 746357d6
      Thomas Gleixner 提交于
      When the kernel is compiled with -pg for tracing GCC 4.4.x inserts
      stack alignment of a function _before_ the mcount prologue if the
      -march=pentium-mmx is set and -mtune=generic is not set. This breaks
      the assumption of the function graph tracer which expects that the
      mcount prologue
      
             push %ebp
             mov  %esp, %ebp
      
      is the first stack operation in a function because it needs to modify
      the function return address on the stack to trap into the tracer
      before returning to the real caller.
      
      The generated code is:
      
              push   %edi
              lea    0x8(%esp),%edi
              and    $0xfffffff0,%esp
              pushl  -0x4(%edi)
              push   %ebp
              mov    %esp,%ebp
      
      so the tracer modifies the copy of the return address which is stored
      after the stack alignment and therefor does not trap the return which
      in turn breaks the call chain logic of the tracer and leads to a
      kernel panic.
      
      Aside of the fact that the generated code is horrible for no good
      reason other -march -mtune options generate the expected:
      
              push   %ebp
              mov    %esp,%ebp
              and    $0xfffffff0,%esp
      
      which does the same and keeps everything intact.
      
      After some experimenting we found out that this problem is restricted
      to gcc4.4.x and to the following -march settings:
      
      i586, pentium, pentium-mmx, k6, k6-2, k6-3, winchip-c6, winchip2, c3,
      geode
      
      By adding -mtune=generic the code generator produces always the
      expected code.
      
      So forcing -mtune=generic when CONFIG_FUNCTION_GRAPH_TRACER=y is not
      pretty, but at the moment the only way to prevent that the kernel
      trips over gcc-shrooms induced code madness.
      
      Most distro kernels have CONFIG_X86_GENERIC=y anyway which forces
      -mtune=generic as well so it will not impact those.
      
      References: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
      	    http://lkml.org/lkml/2009/11/19/17Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <alpine.LFD.2.00.0911200206570.24119@localhost.localdomain>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>,
      Cc: Jeff Law <law@redhat.com>
      Cc: gcc@gcc.gnu.org
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: Andrew Haley <aph@redhat.com>
      Cc: Richard Guenther <richard.guenther@gmail.com>
      Cc: stable@kernel.org
      746357d6
  4. 16 11月, 2009 1 次提交
    • P
      x86: AMD Northbridge: Verify NB's node is online · 303fc087
      Prarit Bhargava 提交于
      Fix panic seen on some IBM and HP systems on 2.6.32-rc6:
      
       BUG: unable to handle kernel NULL pointer dereference at (null)
       IP: [<ffffffff8120bf3f>] find_next_bit+0x77/0x9c
        [...]
        [<ffffffff8120bbde>] cpumask_next_and+0x2e/0x3b
        [<ffffffff81225c62>] pci_device_probe+0x8e/0xf5
        [<ffffffff812b9be6>] ? driver_sysfs_add+0x47/0x6c
        [<ffffffff812b9da5>] driver_probe_device+0xd9/0x1f9
        [<ffffffff812b9f1d>] __driver_attach+0x58/0x7c
        [<ffffffff812b9ec5>] ? __driver_attach+0x0/0x7c
        [<ffffffff812b9298>] bus_for_each_dev+0x54/0x89
        [<ffffffff812b9b4f>] driver_attach+0x19/0x1b
        [<ffffffff812b97ae>] bus_add_driver+0xd3/0x23d
        [<ffffffff812ba1e7>] driver_register+0x98/0x109
        [<ffffffff81225ed0>] __pci_register_driver+0x63/0xd3
        [<ffffffff81072776>] ? up_read+0x26/0x2a
        [<ffffffffa0081000>] ? k8temp_init+0x0/0x20 [k8temp]
        [<ffffffffa008101e>] k8temp_init+0x1e/0x20 [k8temp]
        [<ffffffff8100a073>] do_one_initcall+0x6d/0x185
        [<ffffffff8108d765>] sys_init_module+0xd3/0x236
        [<ffffffff81011ac2>] system_call_fastpath+0x16/0x1b
      
      I put in a printk and commented out the set_dev_node()
      call when and got this output:
      
       quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x0
       quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x1
       quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x2
       quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x3
      
      I.e. the issue appears to be that the HW has set val to a valid
      value, however, the system is only configured for a single
      node -- 0, the others are offline.
      
      Check to see if the node is actually online before setting
      the numa node for an AMD northbridge in quirk_amd_nb_node().
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: bhavna.sarathy@amd.com
      Cc: jbarnes@virtuousgeek.org
      Cc: andreas.herrmann3@amd.com
      LKML-Reference: <20091112180933.12532.98685.sendpatchset@prarit.bos.redhat.com>
      [ v2: clean up the code and add comments ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      303fc087
  5. 11 11月, 2009 3 次提交
  6. 10 11月, 2009 1 次提交
  7. 08 11月, 2009 1 次提交
  8. 07 11月, 2009 1 次提交
  9. 04 11月, 2009 1 次提交
    • S
      x86, fs: Fix x86 procfs stack information for threads on 64-bit · 89240ba0
      Stefani Seibold 提交于
      This patch fixes two issues in the procfs stack information on
      x86-64 linux.
      
      The 32 bit loader compat_do_execve did not store stack
      start. (this was figured out by Alexey Dobriyan).
      
      The stack information on a x64_64 kernel always shows 0 kbyte
      stack usage, because of a missing implementation of the KSTK_ESP
      macro which always returned -1.
      
      The new implementation now returns the right value.
      Signed-off-by: NStefani Seibold <stefani@seibold.net>
      Cc: Americo Wang <xiyou.wangcong@gmail.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <1257240160.4889.24.camel@wall-e>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      89240ba0
  10. 03 11月, 2009 2 次提交
  11. 02 11月, 2009 2 次提交
  12. 29 10月, 2009 2 次提交
  13. 27 10月, 2009 1 次提交
  14. 26 10月, 2009 3 次提交
  15. 23 10月, 2009 1 次提交
  16. 21 10月, 2009 1 次提交
  17. 16 10月, 2009 17 次提交