1. 29 4月, 2009 26 次提交
  2. 24 4月, 2009 1 次提交
  3. 22 4月, 2009 3 次提交
  4. 21 4月, 2009 4 次提交
    • R
      x86: avoid theoretical spurious NMI backtraces with CONFIG_CPUMASK_OFFSTACK=y · fcc5c4a2
      Rusty Russell 提交于
      In theory (though not shown in practice) alloc_cpumask_var() doesn't zero
      memory, so CPUs might print an "NMI backtrace for cpu %d" once on boot.
      
      (Bug introduced in fcef8576).
      
      [ Impact: avoid theoretical syslog noise in rare configs ]
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      LKML-Reference: <alpine.DEB.2.00.0904202113520.10097@gandalf.stny.rr.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fcc5c4a2
    • R
      x86: fix boot crash in NMI watchdog with CONFIG_CPUMASK_OFFSTACK=y and flat APIC · 2f537a9f
      Rusty Russell 提交于
      fcef8576 converted backtrace_mask to a
      cpumask_var_t, and assumed check_nmi_watchdog was called before
      nmi_watchdog_tick was ever called.  Steven's oops shows I was wrong.
      
      This is something of a bandaid: I'm not sure we *should* be calling
      nmi_watchdog_tick before check_nmi_watchdog.  Note that gcc eliminates
      this test for the CONFIG_CPUMASK_OFFSTACK=n case.
      
      [ Impact: fix boot crash in rare configs ]
      Reported-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      LKML-Reference: <alpine.DEB.2.00.0904202113520.10097@gandalf.stny.rr.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2f537a9f
    • S
      x86-64: fix FPU corruption with signals and preemption · 06c38d5e
      Suresh Siddha 提交于
      In 64bit signal delivery path, clear_used_math() was happening before saving
      the current active FPU state on to the user stack for signal handling. Between
      clear_used_math() and the state store on to the user stack, potentially we
      can get a page fault for the user address and can block. Infact, while testing
      we were hitting the might_fault() in __clear_user() which can do a schedule().
      
      At a later point in time, we will schedule back into this process and
      resume the save state (using "xsave/fxsave" instruction) which can lead
      to DNA fault. And as used_math was cleared before, we will reinit the FP state
      in the DNA fault and continue. This reinit will result in loosing the
      FPU state of the process.
      
      Move clear_used_math() to a point after the FPU state has been stored
      onto the user stack.
      
      This issue is present from a long time (even before the xsave changes
      and the x86 merge). But it can easily be exposed in 2.6.28.x and 2.6.29.x
      series because of the __clear_user() in this path, which has an explicit
      __cond_resched() leading to a context switch with CONFIG_PREEMPT_VOLUNTARY.
      
      [ Impact: fix FPU state corruption ]
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: <stable@kernel.org>			[2.6.28.x, 2.6.29.x]
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      06c38d5e
    • J
      x86/uv: fix for no memory at paddr 0 · fc61e663
      Jack Steiner 提交于
      Fix endcase where the memory at physical address 0 does not really
      exist AND one of the sockets on blade 0 has no active cpus.
      
      The memory that _appears_ to be at physical address 0 is actually
      memory that located at a different address but has been remapped by
      the chipset so that it appears to be at physical address 0.
      
      When determining the UV pnode, the algorithm for determining the pnode
      incorrectly used the relocated physical address instead of the actual
      (global) address.
      
      [ Impact: boot failure on partitioned systems ]
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090420132530.GA23156@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fc61e663
  5. 20 4月, 2009 4 次提交
    • T
      acpi-cpufreq: Do not let get_measured perf depend on internal variable · d876dfbb
      Thomas Renninger 提交于
      Take already available policy->cpuinfo.max_freq and get rid of acpi-cpufreq
      specific max_freq variable.
      
      This implies that P0 is always the highest frequency which should always
      be true as ACPI spec says:
      As a result, the zeroth entry describes the highest performance state
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d876dfbb
    • T
      d91758f5
    • T
      acpi-cpufreq: Cleanup: Use printk_once · e0e8c4e5
      Thomas Renninger 提交于
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      e0e8c4e5
    • P
      x86, acpi_cpufreq: Fix the NULL pointer dereference in get_measured_perf · 093f13e2
      Pallipadi, Venkatesh 提交于
      Fix for a regression that was introduced by earlier commit
      18b2646f on Mon Apr 6 11:26:08 2009
      
      Regression resulted in the below error happened on systems with
      software coordination where per_cpu acpi data will not be initiated for
      secondary CPUs in a P-state domain.
      
      On Tue, 2009-04-14 at 23:01 -0700, Zhang, Yanmin wrote:
       My machine hanged with kernel 2.6.30-rc2 when script read
      > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor.
      >
      > opps happens in get_measured_perf:
      >
      >         cur.aperf.whole = readin.aperf.whole -
      >                                 per_cpu(drv_data, cpu)->saved_aperf;
      >
      > Because per_cpu(drv_data, cpu)=NULL.
      >
      > So function get_measured_perf should check if (per_cpu(drv_data,
      > cpu)==NULL)
      > and return 0 if it's NULL.
      
      --------------sys log------------------
      
      BUG: unable to handle kernel NULL pointer dereference at
      0000000000000020
      IP: [<ffffffff8021af75>] get_measured_perf+0x4a/0xf9
      PGD a7dd88067 PUD a7ccf5067 PMD 0
      Oops: 0000 [#1] SMP
      last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
      CPU 0
      Modules linked in: video output
      Pid: 2091, comm: kondemand/0 Not tainted 2.6.30-rc2 #1 MP Server
      RIP: 0010:[<ffffffff8021af75>]  [<ffffffff8021af75>]
      get_measured_perf+0x4a/0xf9
      RSP: 0018:ffff880a7d56de20  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: 00000046241a42b6 RCX: ffff88004d219000
      RDX: 000000000000b660 RSI: 0000000000000020 RDI: 0000000000000001
      RBP: ffff880a7f052000 R08: 00000046241a42b6 R09: ffffffff807639f0
      R10: 00000000ffffffea R11: ffffffff802207f4 R12: ffff880a7f052000
      R13: ffff88004d20e460 R14: 0000000000ddd5a6 R15: 0000000000000001
      FS:  0000000000000000(0000) GS:ffff88004d200000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: 0000000000000020 CR3: 0000000a7f1bf000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process kondemand/0 (pid: 2091, threadinfo ffff880a7d56c000, task
      ffff880a7d4d18c0)
      Stack:
       ffff880a7f052078 ffffffff803efd54 00000046241a42b6 000000462ffa9e95
       0000000000000001 0000000000000001 00000000ffffffea ffffffff8064f41a
       0000000000000012 0000000000000012 ffff880a7f052000 ffffffff80650547
      Call Trace:
       [<ffffffff803efd54>] ? kobject_get+0x12/0x17
       [<ffffffff8064f41a>] ? __cpufreq_driver_getavg+0x42/0x57
       [<ffffffff80650547>] ? do_dbs_timer+0x147/0x272
       [<ffffffff80650400>] ? do_dbs_timer+0x0/0x272
       [<ffffffff802474ca>] ? worker_thread+0x15b/0x1f5
       [<ffffffff8024a02c>] ? autoremove_wake_function+0x0/0x2e
       [<ffffffff8024736f>] ? worker_thread+0x0/0x1f5
       [<ffffffff80249f0d>] ? kthread+0x54/0x83
       [<ffffffff8020c87a>] ? child_rip+0xa/0x20
       [<ffffffff80249eb9>] ? kthread+0x0/0x83
       [<ffffffff8020c870>] ? child_rip+0x0/0x20
      Code: 99 a6 03 00 31 c9 85 c0 0f 85 c3 00 00 00 89 df 4c 8b 44 24 10 48
      c7 c2 60 b6 00 00 48 8b 0c fd e0 30 a5 80 4c 89 c3 48 8b 04 0a <48> 2b
      58 20 48 8b 44 24 18 48 89 1c 24 48 8b 34 0a 48 2b 46 28
      RIP  [<ffffffff8021af75>] get_measured_perf+0x4a/0xf9
       RSP <ffff880a7d56de20>
      CR2: 0000000000000020
      ---[ end trace 2b8fac9a49e19ad4 ]---
      Tested-by: N"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      093f13e2
  6. 18 4月, 2009 2 次提交
    • S
      lockdep, x86: account for irqs enabled in paranoid_exit · 0300e7f1
      Steven Rostedt 提交于
      I hit the check_flags error of lockdep:
      
       WARNING: at kernel/lockdep.c:2893 check_flags+0x1a7/0x1d0()
       [...]
       hardirqs last  enabled at (12567): [<ffffffff8026206a>] local_bh_enable+0xaa/0x110
       hardirqs last disabled at (12569): [<ffffffff80610c76>] int3+0x16/0x40
       softirqs last  enabled at (12566): [<ffffffff80514d2b>] lock_sock_nested+0xfb/0x110
       softirqs last disabled at (12568): [<ffffffff8058454e>] tcp_prequeue_process+0x2e/0xa0
      
      The check_flags warning of lockdep tells me that lockdep thought interrupts
      were disabled, but they were really enabled.
      
      The numbers in the above parenthesis show the order of events:
      
       12566: softirqs last enabled:  lock_sock_nested
       12567: hardirqs last enabled:  local_bh_enable
       12568: softirqs last disabled: tcp_prequeue_process
       12566: hardirqs last disabled: int3
      
      int3 is a breakpoint!
      
      Examining this further, I have CONFIG_NET_TCPPROBE enabled which adds
      break points into the kernel.
      
      The paranoid_exit of the return of int3 does not account for enabling
      interrupts on return to kernel. This code is a bit tricky since it
      is also used by the nmi handler (when lockdep is off), and we must be
      careful about the swapgs. We can not call kernel code after the swapgs
      has been performed.
      
      [ Impact: fix lockdep check_flags warning + self-turn-off ]
      Acked-by: NPeter Zijlsta <a.p.zijlstra@chello.nl>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0300e7f1
    • J
      x86/uv: fix init of cpu-less nodes · 27229ca6
      Jack Steiner 提交于
      Fix an endcase in the UV initialization code for the "UV large system mode"
      of apicids.  If node zero contains no cpus, cpus on another node will be the
      boot cpu.  The percpu data that contains the extra apicid bits was not
      being initialized early enough.
      
      [ Impact: fix potential boot crash on cpu-less UV nodes ]
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090417142447.GA23759@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      27229ca6