1. 31 8月, 2009 19 次提交
  2. 27 8月, 2009 11 次提交
  3. 25 8月, 2009 2 次提交
    • J
      x86: Fix build with older binutils and consolidate linker script · c62e4320
      Jan Beulich 提交于
      binutils prior to 2.17 can't deal with the currently possible
      situation of a new segment following the per-CPU segment, but
      that new segment being empty - objcopy misplaces the .bss (and
      perhaps also the .brk) sections outside of any segment.
      
      However, the current ordering of sections really just appears
      to be the effect of cumulative unrelated changes; re-ordering
      things allows to easily guarantee that the segment following
      the per-CPU one is non-empty, and at once eliminates the need
      for the bogus data.init2 segment.
      
      Once touching this code, also use the various data section
      helper macros from include/asm-generic/vmlinux.lds.h.
      
      -v2: fix !SMP builds.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: <sam@ravnborg.org>
      LKML-Reference: <4A94085D02000078000119A5@vpn.id2.novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c62e4320
    • A
      x86: Fix an incorrect argument of reserve_bootmem() · a6a06f7b
      Amerigo Wang 提交于
      This line looks suspicious, because if this is true, then the
      'flags' parameter of function reserve_bootmem_generic() will be
      unused when !CONFIG_NUMA. I don't think this is what we want.
      Signed-off-by: NWANG Cong <amwang@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: akpm@linux-foundation.org
      LKML-Reference: <20090821083709.5098.52505.sendpatchset@localhost.localdomain>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a6a06f7b
  4. 24 8月, 2009 1 次提交
  5. 22 8月, 2009 2 次提交
    • L
      x86: don't call '->send_IPI_mask()' with an empty mask · b04e6373
      Linus Torvalds 提交于
      As noted in 83d349f3 ("x86: don't send
      an IPI to the empty set of CPU's"), some APIC's will be very unhappy
      with an empty destination mask.  That commit added a WARN_ON() for that
      case, and avoided the resulting problem, but didn't fix the underlying
      reason for why those empty mask cases happened.
      
      This fixes that, by checking the result of 'cpumask_andnot()' of the
      current CPU actually has any other CPU's left in the set of CPU's to be
      sent a TLB flush, and not calling down to the IPI code if the mask is
      empty.
      
      The reason this started happening at all is that we started passing just
      the CPU mask pointers around in commit 4595f962 ("x86: change
      flush_tlb_others to take a const struct cpumask"), and when we did that,
      the cpumask was no longer thread-local.
      
      Before that commit, flush_tlb_mm() used to create it's own copy of
      'mm->cpu_vm_mask' and pass that copy down to the low-level flush
      routines after having tested that it was not empty.  But after changing
      it to just pass down the CPU mask pointer, the lower level TLB flush
      routines would now get a pointer to that 'mm->cpu_vm_mask', and that
      could still change - and become empty - after the test due to other
      CPU's having flushed their own TLB's.
      
      See
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=13933
      
      for details.
      Tested-by: NThomas Björnell <thomas.bjornell@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b04e6373
    • L
      x86: don't send an IPI to the empty set of CPU's · 83d349f3
      Linus Torvalds 提交于
      The default_send_IPI_mask_logical() function uses the "flat" APIC mode
      to send an IPI to a set of CPU's at once, but if that set happens to be
      empty, some older local APIC's will apparently be rather unhappy.  So
      just warn if a caller gives us an empty mask, and ignore it.
      
      This fixes a regression in 2.6.30.x, due to commit 4595f962 ("x86:
      change flush_tlb_others to take a const struct cpumask"), documented
      here:
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=13933
      
      which causes a silent lock-up.  It only seems to happen on PPro, P2, P3
      and Athlon XP cores.  Most developers sadly (or not so sadly, if you're
      a developer..) have more modern CPU's.  Also, on x86-64 we don't use the
      flat APIC mode, so it would never trigger there even if the APIC didn't
      like sending an empty IPI mask.
      Reported-by: NPavel Vilim <wylda@volny.cz>
      Reported-and-tested-by: NThomas Björnell <thomas.bjornell@gmail.com>
      Reported-and-tested-by: NMartin Rogge <marogge@onlinehome.de>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83d349f3
  6. 21 8月, 2009 1 次提交
  7. 20 8月, 2009 3 次提交
    • J
      xen: rearrange things to fix stackprotector · ce2eef33
      Jeremy Fitzhardinge 提交于
      Make sure the stack-protector segment registers are properly set up
      before calling any functions which may have stack-protection compiled
      into them.
      
      [ Impact: prevent Xen early-boot crash when stack-protector is enabled ]
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      ce2eef33
    • J
      x86: make sure load_percpu_segment has no stackprotector · 5416c266
      Jeremy Fitzhardinge 提交于
      load_percpu_segment() is used to set up the per-cpu segment registers,
      which are also used for -fstack-protector.  Make sure that the
      load_percpu_segment() function doesn't have stackprotector enabled.
      
      [ Impact: allow percpu setup before calling stack-protected functions ]
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      5416c266
    • S
      clockevent: Prevent dead lock on clockevents_lock · f833bab8
      Suresh Siddha 提交于
      Currently clockevents_notify() is called with interrupts enabled at
      some places and interrupts disabled at some other places.
      
      This results in a deadlock in this scenario.
      
      cpu A holds clockevents_lock in clockevents_notify() with irqs enabled
      cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled
      cpu C doing set_mtrr() which will try to rendezvous of all the cpus.
      
      This will result in C and A come to the rendezvous point and waiting
      for B. B is stuck forever waiting for the spinlock and thus not
      reaching the rendezvous point.
      
      Fix the clockevents code so that clockevents_lock is taken with
      interrupts disabled and thus avoid the above deadlock.
      
      Also call lapic_timer_propagate_broadcast() on the destination cpu so
      that we avoid calling smp_call_function() in the clockevents notifier
      chain.
      
      This issue left us wondering if we need to change the MTRR rendezvous
      logic to use stop machine logic (instead of smp_call_function) or add
      a check in spinlock debug code to see if there are other spinlocks
      which gets taken under both interrupts enabled/disabled conditions.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: "Pallipadi Venkatesh" <venkatesh.pallipadi@intel.com>
      Cc: "Brown Len" <len.brown@intel.com>
      LKML-Reference: <1250544899.2709.210.camel@sbs-t61.sc.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f833bab8
  8. 18 8月, 2009 1 次提交
    • J
      i386: Fix section mismatches for init code with !HOTPLUG_CPU · 78b89ecd
      Jan Beulich 提交于
      Commit 0e83815b changed the
      section the initial_code variable gets allocated in, in an
      attempt to address a section conflict warning. This, however
      created a new section conflict when building without
      HOTPLUG_CPU. The apparently only (reasonable) way to address
      this is to always use __REFDATA.
      
      Once at it, also fix a second section mismatch when not using
      HOTPLUG_CPU.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: Robert Richter <robert.richter@amd.com>
      LKML-Reference: <4A8AE7CD020000780001054B@vpn.id2.novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      78b89ecd