1. 01 7月, 2011 1 次提交
  2. 15 6月, 2011 1 次提交
  3. 14 6月, 2011 1 次提交
  4. 10 6月, 2011 1 次提交
    • M
      exec: delay address limit change until point of no return · dac853ae
      Mathias Krause 提交于
      Unconditionally changing the address limit to USER_DS and not restoring
      it to its old value in the error path is wrong because it prevents us
      using kernel memory on repeated calls to this function.  This, in fact,
      breaks the fallback of hard coded paths to the init program from being
      ever successful if the first candidate fails to load.
      
      With this patch applied switching to USER_DS is delayed until the point
      of no return is reached which makes it possible to have a multi-arch
      rootfs with one arch specific init binary for each of the (hard coded)
      probed paths.
      
      Since the address limit is already set to USER_DS when start_thread()
      will be invoked, this redundancy can be safely removed.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dac853ae
  5. 09 6月, 2011 1 次提交
  6. 08 6月, 2011 1 次提交
    • T
      x86: cpu-hotplug: Prevent softirq wakeup on wrong CPU · fd8a7de1
      Thomas Gleixner 提交于
      After a newly plugged CPU sets the cpu_online bit it enables
      interrupts and goes idle. The cpu which brought up the new cpu waits
      for the cpu_online bit and when it observes it, it sets the cpu_active
      bit for this cpu. The cpu_active bit is the relevant one for the
      scheduler to consider the cpu as a viable target.
      
      With forced threaded interrupt handlers which imply forced threaded
      softirqs we observed the following race:
      
      cpu 0                         cpu 1
      
      bringup(cpu1);
                                    set_cpu_online(smp_processor_id(), true);
      		              local_irq_enable();
      while (!cpu_online(cpu1));
                                    timer_interrupt()
                                      -> wake_up(softirq_thread_cpu1);
                                           -> enqueue_on(softirq_thread_cpu1, cpu0);
      
                                                                              ^^^^
      
      cpu_notify(CPU_ONLINE, cpu1);
        -> sched_cpu_active(cpu1)
           -> set_cpu_active((cpu1, true);
      
      When an interrupt happens before the cpu_active bit is set by the cpu
      which brought up the newly onlined cpu, then the scheduler refuses to
      enqueue the woken thread which is bound to that newly onlined cpu on
      that newly onlined cpu due to the not yet set cpu_active bit and
      selects a fallback runqueue. Not really an expected and desirable
      behaviour.
      
      So far this has only been observed with forced hard/softirq threading,
      but in theory this could happen without forced threaded hard/softirqs
      as well. It's probably unobservable as it would take a massive
      interrupt storm on the newly onlined cpu which causes the softirq loop
      to wake up the softirq thread and an even longer delay of the cpu
      which waits for the cpu_online bit.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: stable@kernel.org # 2.6.39
      fd8a7de1
  7. 07 6月, 2011 1 次提交
    • J
      x86/amd-iommu: Fix boot crash with hidden PCI devices · 26018874
      Joerg Roedel 提交于
      Some PCIe cards ship with a PCI-PCIe bridge which is not
      visible as a PCI device in Linux. But the device-id of the
      bridge is present in the IOMMU tables which causes a boot
      crash in the IOMMU driver.
      This patch fixes by removing these cards from the IOMMU
      handling. This is a pure -stable fix, a real fix to handle
      this situation appriatly will follow for the next merge
      window.
      
      Cc: stable@kernel.org	# > 2.6.32
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      26018874
  8. 06 6月, 2011 2 次提交
  9. 30 5月, 2011 3 次提交
  10. 29 5月, 2011 6 次提交
    • L
      x86 idle: deprecate mwait_idle() and "idle=mwait" cmdline param · 5d4c47e0
      Len Brown 提交于
      mwait_idle() is a C1-only idle loop intended to be more efficient
      than HLT on SMP hardware that supports it.
      
      But mwait_idle() has been replaced by the more general
      mwait_idle_with_hints(), which handles both C1 and deeper C-states.
      ACPI uses only mwait_idle_with_hints(), and never uses mwait_idle().
      
      Deprecate mwait_idle() and the "idle=mwait" cmdline param
      to simplify the x86 idle code.
      
      After this change, kernels configured with
      (!CONFIG_ACPI=n && !CONFIG_INTEL_IDLE=n) when run on hardware
      that support MWAIT will simply use HLT.  If MWAIT is desired
      on those systems, cpuidle and the cpuidle drivers above
      can be used.
      
      cc: x86@kernel.org
      cc: stable@kernel.org # .39.x
      Signed-off-by: NLen Brown <len.brown@intel.com>
      5d4c47e0
    • L
      x86 idle: deprecate "no-hlt" cmdline param · cdaab4a0
      Len Brown 提交于
      We'd rather that modern machines not check if HLT works on
      every entry into idle, for the benefit of machines that had
      marginal electricals 15-years ago.  If those machines are still running
      the upstream kernel, they can use "idle=poll".  The only difference
      will be that they'll now invoke HLT in machine_hlt().
      
      cc: x86@kernel.org # .39.x
      Signed-off-by: NLen Brown <len.brown@intel.com>
      cdaab4a0
    • L
      x86 idle APM: deprecate CONFIG_APM_CPU_IDLE · 99c63221
      Len Brown 提交于
      We don't want to export the pm_idle function pointer to modules.
      Currently CONFIG_APM_CPU_IDLE w/ CONFIG_APM_MODULE forces us to.
      
      CONFIG_APM_CPU_IDLE is of dubious value, it runs only on 32-bit
      uniprocessor laptops that are over 10 years old.  It calls into
      the BIOS during idle, and is known to cause a number of machines
      to fail.
      
      Removing CONFIG_APM_CPU_IDLE and will allow us to stop exporting
      pm_idle.  Any systems that were calling into the APM BIOS
      at run-time will simply use HLT instead.
      
      cc: x86@kernel.org
      cc: Jiri Kosina <jkosina@suse.cz>
      cc: stable@kernel.org # .39.x
      Signed-off-by: NLen Brown <len.brown@intel.com>
      99c63221
    • L
      x86 idle: EXPORT_SYMBOL(default_idle, pm_idle) only when APM demands it · 06ae40ce
      Len Brown 提交于
      In the long run, we don't want default_idle() or (pm_idle)() to
      be exported outside of process.c.  Start by not exporting them
      to modules, unless the APM build demands it.
      
      cc: x86@kernel.org
      cc: Jiri Kosina <jkosina@suse.cz>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      06ae40ce
    • L
      x86 idle: clarify AMD erratum 400 workaround · 02c68a02
      Len Brown 提交于
      The workaround for AMD erratum 400 uses the term "c1e" falsely suggesting:
      1. Intel C1E is somehow involved
      2. All AMD processors with C1E are involved
      
      Use the string "amd_c1e" instead of simply "c1e" to clarify that
      this workaround is specific to AMD's version of C1E.
      Use the string "e400" to clarify that the workaround is specific
      to AMD processors with Erratum 400.
      
      This patch is text-substitution only, with no functional change.
      
      cc: x86@kernel.org
      Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      02c68a02
    • E
      ns: Wire up the setns system call · 7b21fddd
      Eric W. Biederman 提交于
      32bit and 64bit on x86 are tested and working.  The rest I have looked
      at closely and I can't find any problems.
      
      setns is an easy system call to wire up.  It just takes two ints so I
      don't expect any weird architecture porting problems.
      
      While doing this I have noticed that we have some architectures that are
      very slow to get new system calls.  cris seems to be the slowest where
      the last system calls wired up were preadv and pwritev.  avr32 is weird
      in that recvmmsg was wired up but never declared in unistd.h.  frv is
      behind with perf_event_open being the last syscall wired up.  On h8300
      the last system call wired up was epoll_wait.  On m32r the last system
      call wired up was fallocate.  mn10300 has recvmmsg as the last system
      call wired up.  The rest seem to at least have syncfs wired up which was
      new in the 2.6.39.
      
      v2: Most of the architecture support added by Daniel Lezcano <dlezcano@fr.ibm.com>
      v3: ported to v2.6.36-rc4 by: Eric W. Biederman <ebiederm@xmission.com>
      v4: Moved wiring up of the system call to another patch
      v5: ported to v2.6.39-rc6
      v6: rebased onto parisc-next and net-next to avoid syscall  conflicts.
      v7: ported to Linus's latest post 2.6.39 tree.
      
      >  arch/blackfin/include/asm/unistd.h     |    3 ++-
      >  arch/blackfin/mach-common/entry.S      |    1 +
      Acked-by: NMike Frysinger <vapier@gentoo.org>
      
      Oh - ia64 wiring looks good.
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b21fddd
  11. 28 5月, 2011 1 次提交
    • S
      x86: Put back -pg to tsc.o and add no GCOV to vread_tsc_64.o · 89e1be50
      Steven Rostedt 提交于
      The commit 44259b1a
          Author: Andy Lutomirski <luto@MIT.EDU>
          x86-64: Move vread_tsc into a new file with sensible options
      
      Removed the -pg from tsc.o which caused the function graph tracer
      to go into an infinite function call recursion as it uses the tsc
      internally outside its recursion protection, thus tracing the tsc
      breaks the function graph tracer.
      
      This commit also added the file vread_tsc_64.c that gets used
      by vdso but failed to prevent GCOV from monkeying with it,
      causing userspace to try to access kernel data when GCOV was
      enabled.
      
      Thanks to Thomas Gleixner for pointing out GCOV as the likely
      culprit that added strange kernel accesses into the vread_tsc()
      call.
      
      Cc: Author: Andy Lutomirski <luto@MIT.EDU>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      89e1be50
  12. 27 5月, 2011 1 次提交
  13. 26 5月, 2011 3 次提交
    • M
      x86, efi: Retain boot service code until after switching to virtual mode · 916f676f
      Matthew Garrett 提交于
      UEFI stands for "Unified Extensible Firmware Interface", where "Firmware"
      is an ancient African word meaning "Why do something right when you can
      do it so wrong that children will weep and brave adults will cower before
      you", and "UEI" is Celtic for "We missed DOS so we burned it into your
      ROMs". The UEFI specification provides for runtime services (ie, another
      way for the operating system to be forced to depend on the firmware) and
      we rely on these for certain trivial tasks such as setting up the
      bootloader. But some hardware fails to work if we attempt to use these
      runtime services from physical mode, and so we have to switch into virtual
      mode. So far so dreadful.
      
      The specification makes it clear that the operating system is free to do
      whatever it wants with boot services code after ExitBootServices() has been
      called. SetVirtualAddressMap() can't be called until ExitBootServices() has
      been. So, obviously, a whole bunch of EFI implementations call into boot
      services code when we do that. Since we've been charmingly naive and
      trusted that the specification may be somehow relevant to the real world,
      we've already stuffed a picture of a penguin or something in that address
      space. And just to make things more entertaining, we've also marked it
      non-executable.
      
      This patch allocates the boot services regions during EFI init and makes
      sure that they're executable. Then, after SetVirtualAddressMap(), it
      discards them and everyone lives happily ever after. Except for the ones
      who have to work on EFI, who live sad lives haunted by the knowledge that
      someone's eventually going to write yet another firmware specification.
      
      [ hpa: adding this to urgent with a stable tag since it fixes currently-broken
        hardware.  However, I do not know what the dependencies are and so I do
        not know which -stable versions this may be a candidate for. ]
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: <stable@kernel.org>
      916f676f
    • R
      x86/ftrace: Fix compiler warning in ftrace.c · 0d098a7d
      Rakib Mullick 提交于
       Due to commit dc326fca (x86, cpu: Clean up and unify the NOP selection infrastructure), we get the following warning:
      
      arch/x86/kernel/ftrace.c: In function ‘ftrace_make_nop’:
      arch/x86/kernel/ftrace.c:308:6: warning: assignment discards qualifiers from pointer target type
      arch/x86/kernel/ftrace.c: In function ‘ftrace_make_call’:
      arch/x86/kernel/ftrace.c:318:6: warning: assignment discards qualifiers from pointer target type
      
      ftrace_nop_replace() now returns const unsigned char *, so change its associated function/variable to its compatible type to keep compiler clam.
      Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
      Link: http://lkml.kernel.org/r/1305221620.7986.4.camel@localhost.localdomain
      
      [ updated for change of const void *src in probe_kernel_write() ]
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      0d098a7d
    • N
      x86: Remove unnecessary check in detect_ht() · 8b27f2ff
      Nikhil P Rao 提交于
      This patch removes a check that causes incorrect scheduler
      domain setup (SMP instead of SMT) and bootlog warning messages
      when cpuid extensions for topology enumeration are not supported
      and the number of processors reported to the OS is smaller than
      smp_num_siblings.
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NNikhil P Rao <nikhil.rao@intel.com>
      Link: http://lkml.kernel.org/r/1306343921.19325.1.camel@fedora13Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8b27f2ff
  14. 25 5月, 2011 4 次提交
  15. 24 5月, 2011 7 次提交
  16. 23 5月, 2011 2 次提交
  17. 22 5月, 2011 4 次提交