1. 26 Jun, 2012 1 commit
  2. 25 Jun, 2012 2 commits
  3. 18 Jun, 2012 1 commit
  4. 14 Jun, 2012 1 commit
  5. 13 Jun, 2012 1 commit
    • Borislav Petkov's avatar
      x86/smp: Fix topology checks on AMD MCM CPUs · 161270fc
      Borislav Petkov authored
      The warning below triggers on AMD MCM packages because physical package
      IDs on the cores of a _physical_ socket are the same. I.e., this field
      says which CPUs belong to the same physical package.
      However, the same two CPUs belong to two different internal, i.e.
      "logical" nodes in the same physical socket which is reflected in the
      CPU-to-node map on x86 with NUMA.
      Which makes this check wrong on the above topologies so circumvent it.
      [    0.444413] Booting Node   0, Processors  #1 #2 #3 #4 #5 Ok.
      [    0.461388] ------------[ cut here ]------------
      [    0.465997] WARNING: at arch/x86/kernel/smpboot.c:310 topology_sane.clone.1+0x6e/0x81()
      [    0.473960] Hardware name: Dinar
      [    0.477170] sched: CPU #6's mc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
      [    0.486860] Booting Node   1, Processors  #6
      [    0.491104] Modules linked in:
      [    0.494141] Pid: 0, comm: swapper/6 Not tainted 3.4.0+ #1
      [    0.499510] Call Trace:
      [    0.501946]  [<ffffffff8144bf92>] ? topology_sane.clone.1+0x6e/0x81
      [    0.508185]  [<ffffffff8102f1fc>] warn_slowpath_common+0x85/0x9d
      [    0.514163]  [<ffffffff8102f2b7>] warn_slowpath_fmt+0x46/0x48
      [    0.519881]  [<ffffffff8144bf92>] topology_sane.clone.1+0x6e/0x81
      [    0.525943]  [<ffffffff8144c234>] set_cpu_sibling_map+0x251/0x371
      [    0.532004]  [<ffffffff8144c4ee>] start_secondary+0x19a/0x218
      [    0.537729] ---[ end trace 4eaa2a86a8e2da22 ]---
      [    0.628197]  #7 #8 #9 #10 #11 Ok.
      [    0.807108] Booting Node   3, Processors  #12 #13 #14 #15 #16 #17 Ok.
      [    0.897587] Booting Node   2, Processors  #18 #19 #20 #21 #22 #23 Ok.
      [    0.917443] Brought up 24 CPUs
      We ran a topology sanity check test we have here on it and
      it all looks ok... hopefully :).
      Signed-off-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20120529135442.GE29157@aftab.osrc.amd.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  6. 11 Jun, 2012 1 commit
  7. 08 Jun, 2012 1 commit
    • Don Zickus's avatar
      x86/nmi: Fix section mismatch warnings on 32-bit · eeaaa96a
      Don Zickus authored
      It was reported that compiling for 32-bit caused a bunch of
      section mismatch warnings:
       VDSOSYM arch/x86/vdso/vdso32-syms.lds
        LD      arch/x86/vdso/built-in.o
        LD      arch/x86/built-in.o
       WARNING: arch/x86/built-in.o(.data+0x5af0): Section mismatch in
       reference from the variable test_nmi_ipi_callback_na.10451 to
       the function .init.text:test_nmi_ipi_callback() [...]
       WARNING: arch/x86/built-in.o(.data+0x5b04): Section mismatch in
       reference from the variable nmi_unk_cb_na.10399 to the function
       .init.text:nmi_unk_cb() The variable nmi_unk_cb_na.10399
       references the function __init nmi_unk_cb() [...]
      Both of these are attributed to the internal representation of
      the nmiaction struct created during register_nmi_handler.  The
      reason for this is that those structs are not defined in the
      init section whereas the rest of the code in nmi_selftest.c is.
      To resolve this, I created a new #define,
      register_nmi_handler_initonly, that tags the struct as
      __initdata to resolve the mismatch.  This #define should only be
      used in rare situations where the register/unregister is called
      during init of the kernel.
      Big thanks to Jan Beulich for decoding this for me as I didn't
      have a clue what was going on.
      Reported-by: default avatarWitold Baryluk <baryluk@smp.if.uj.edu.pl>
      Tested-by: default avatarWitold Baryluk <baryluk@smp.if.uj.edu.pl>
      Cc: Jan Beulich <JBeulich@suse.com>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Link: http://lkml.kernel.org/r/1338991542-23000-1-git-send-email-dzickus@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  8. 06 Jun, 2012 12 commits
  9. 05 Jun, 2012 1 commit
  10. 01 Jun, 2012 7 commits
  11. 31 May, 2012 5 commits
    • Steven Rostedt's avatar
      ftrace/x86: Do not change stacks in DEBUG when calling lockdep · 5963e317
      Steven Rostedt authored
      When both DYNAMIC_FTRACE and LOCKDEP are set, the TRACE_IRQS_ON/OFF
      will call into the lockdep code. The lockdep code can call lots of
      functions that may be traced by ftrace. When ftrace is updating its
      code and hits a breakpoint, the breakpoint handler will call into
      lockdep. If lockdep happens to call a function that also has a breakpoint
      attached, it will jump back into the breakpoint handler resetting
      the stack to the debug stack and corrupt the contents currently on
      that stack.
      The 'do_sym' call that calls do_int3() is protected by modifying the
      IST table to point to a different location if another breakpoint is
      hit. But the TRACE_IRQS_OFF/ON are outside that protection, and if
      a breakpoint is hit from those, the stack will get corrupted, and
      the kernel will crash:
      [ 1013.243754] BUG: unable to handle kernel NULL pointer dereference at 0000000000000002
      [ 1013.272665] IP: [<ffff880145cc0000>] 0xffff880145cbffff
      [ 1013.285186] PGD 1401b2067 PUD 14324c067 PMD 0
      [ 1013.298832] Oops: 0010 [#1] PREEMPT SMP
      [ 1013.310600] CPU 2
      [ 1013.317904] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables crc32c_intel ghash_clmulni_intel microcode usb_debug serio_raw pcspkr iTCO_wdt i2c_i801 iTCO_vendor_support e1000e nfsd nfs_acl auth_rpcgss lockd sunrpc i915 video i2c_algo_bit drm_kms_helper drm i2c_core [last unloaded: scsi_wait_scan]
      [ 1013.401848]
      [ 1013.407399] Pid: 112, comm: kworker/2:1 Not tainted 3.4.0+ #30
      [ 1013.437943] RIP: 8eb8:[<ffff88014630a000>]  [<ffff88014630a000>] 0xffff880146309fff
      [ 1013.459871] RSP: ffffffff8165e919:ffff88014780f408  EFLAGS: 00010046
      [ 1013.477909] RAX: 0000000000000001 RBX: ffffffff81104020 RCX: 0000000000000000
      [ 1013.499458] RDX: ffff880148008ea8 RSI: ffffffff8131ef40 RDI: ffffffff82203b20
      [ 1013.521612] RBP: ffffffff81005751 R08: 0000000000000000 R09: 0000000000000000
      [ 1013.543121] R10: ffffffff82cdc318 R11: 0000000000000000 R12: ffff880145cc0000
      [ 1013.564614] R13: ffff880148008eb8 R14: 0000000000000002 R15: ffff88014780cb40
      [ 1013.586108] FS:  0000000000000000(0000) GS:ffff880148000000(0000) knlGS:0000000000000000
      [ 1013.609458] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 1013.627420] CR2: 0000000000000002 CR3: 0000000141f10000 CR4: 00000000001407e0
      [ 1013.649051] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 1013.670724] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [ 1013.692376] Process kworker/2:1 (pid: 112, threadinfo ffff88013fe0e000, task ffff88014020a6a0)
      [ 1013.717028] Stack:
      [ 1013.724131]  ffff88014780f570 ffff880145cc0000 0000400000004000 0000000000000000
      [ 1013.745918]  cccccccccccccccc ffff88014780cca8 ffffffff811072bb ffffffff81651627
      [ 1013.767870]  ffffffff8118f8a7 ffffffff811072bb ffffffff81f2b6c5 ffffffff81f11bdb
      [ 1013.790021] Call Trace:
      [ 1013.800701] Code: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a <e7> d7 64 81 ff ff ff ff 01 00 00 00 00 00 00 00 65 d9 64 81 ff
      [ 1013.861443] RIP  [<ffff88014630a000>] 0xffff880146309fff
      [ 1013.884466]  RSP <ffff88014780f408>
      [ 1013.901507] CR2: 0000000000000002
      The solution was to reuse the NMI functions that change the IDT table to make the debug
      stack keep its current stack (in kernel mode) when hitting a breakpoint:
        call debug_stack_set_zero
        call debug_stack_reset
      If the TRACE_IRQS_ON happens to hit a breakpoint then it will keep the current stack
      and not crash the box.
      Reported-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
    • Steven Rostedt's avatar
      x86: Allow nesting of the debug stack IDT setting · f8988175
      Steven Rostedt authored
      When the NMI handler runs, it checks if it preempted a debug handler
      and if that handler is using the debug stack. If it is, it changes the
      IDT table not to update the stack, otherwise it will reset the debug
      stack and corrupt the debug handler it preempted.
      Now that ftrace uses breakpoints to change functions from nops to
      callers, many more places may hit a breakpoint. Unfortunately this
      includes some of the calls that lockdep performs. Which causes issues
      with the debug stack. It too needs to change the debug stack before
      tracing (if called from the debug handler).
      Allow the debug_stack_set_zero() and debug_stack_reset() to be nested
      so that the debug handlers can take advantage of them too.
      [ Used this_cpu_*() over __get_cpu_var() as suggested by H. Peter Anvin ]
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
    • Steven Rostedt's avatar
      x86: Reset the debug_stack update counter · c0525a69
      Steven Rostedt authored
      When an NMI goes off and it sees that it preempted the debug stack,
      to keep the debug stack safe, it changes the IDT to point to one that
      does not modify the stack on breakpoint (to allow breakpoints in NMIs).
      But the variable that gets set to know to undo it on exit never gets
      cleared on exit. Thus every NMI will reset it on exit the first time
      it is done even if it does not need to be reset.
      [ Added H. Peter Anvin's suggestion to use this_cpu_read/write ]
      Cc: <stable@vger.kernel.org> # v3.3
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
    • Steven Rostedt's avatar
      ftrace: Use breakpoint method to update ftrace caller · 8a4d0a68
      Steven Rostedt authored
      On boot up and module load, it is fine to modify the code directly,
      without the use of breakpoints. This is because boot up modification
      is done before SMP is initialized, thus the modification is serial,
      and module load is done before the module executes.
      But after that we must use a SMP safe method to modify running code.
      Otherwise, if we are running the function tracer and update its
      function (by starting off the stack tracer, or perf tracing)
      the change of the function called by the ftrace trampoline is done
      directly. If this is being executed on another CPU, that CPU may
      take a GPF and crash the kernel.
      The breakpoint method is used to change the nops at all the functions, but
      the change of the ftrace callback handler itself was still using a
      direct modification. If tracing was enabled and the function callback
      was changed then another CPU could fault if it was currently calling
      the original callback. This modification must use the breakpoint method
      Note, the direct method is still used for boot up and module load.
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
    • Steven Rostedt's avatar
      ftrace: Synchronize variable setting with breakpoints · a192cd04
      Steven Rostedt authored
      When the function tracer starts modifying the code via breakpoints
      it sets a variable (modifying_ftrace_code) to inform the breakpoint
      handler to call the ftrace int3 code.
      But there's no synchronization between setting this code and the
      handler, thus it is possible for the handler to be called on another
      CPU before it sees the variable. This will cause a kernel crash as
      the int3 handler will not know what to do with it.
      I originally added smp_mb()'s to force the visibility of the variable
      but H. Peter Anvin suggested that I just make it atomic.
      [ Added comments as suggested by Peter Zijlstra ]
      Suggested-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
  12. 30 May, 2012 3 commits
  13. 29 May, 2012 2 commits
    • Bjorn Helgaas's avatar
      x86: print physical addresses consistently with other parts of kernel · 365811d6
      Bjorn Helgaas authored
      Print physical address info in a style consistent with the %pR style used
      elsewhere in the kernel.  For example:
          -found SMP MP-table at [ffff8800000fce90] fce90
          +found SMP MP-table at [mem 0x000fce90-0x000fce9f] mapped at [ffff8800000fce90]
          -initial memory mapped : 0 - 20000000
          +initial memory mapped: [mem 0x00000000-0x1fffffff]
          -Base memory trampoline at [ffff88000009c000] 9c000 size 8192
          +Base memory trampoline [mem 0x0009c000-0x0009dfff] mapped at [ffff88000009c000]
          -SRAT: Node 0 PXM 0 0-80000000
          +SRAT: Node 0 PXM 0 [mem 0x00000000-0x7fffffff]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Bjorn Helgaas's avatar
      x86: print e820 physical addresses consistently with other parts of kernel · 91eb0f67
      Bjorn Helgaas authored
      Print physical address info in a style consistent with the %pR style used
      elsewhere in the kernel.  For example:
          -BIOS-provided physical RAM map:
          +e820: BIOS-provided physical RAM map:
          - BIOS-e820: 0000000000000100 - 000000000009e000 (usable)
          +BIOS-e820: [mem 0x0000000000000100-0x000000000009dfff] usable
          -Allocating PCI resources starting at 90000000 (gap: 90000000:6ed1c000)
          +e820: [mem 0x90000000-0xfed1bfff] available for PCI devices
          -reserve RAM buffer: 000000000009e000 - 000000000009ffff
          +e820: reserve RAM buffer [mem 0x0009e000-0x0009ffff]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  14. 25 May, 2012 1 commit
  15. 23 May, 2012 1 commit