1. 10 8月, 2016 1 次提交
  2. 14 7月, 2016 1 次提交
  3. 04 6月, 2016 1 次提交
  4. 16 4月, 2016 1 次提交
    • D
      x86: Fix non-static inlines · a3819e3e
      Denys Vlasenko 提交于
      Four instances of incorrect usage of non-static "inline" crept up
      in arch/x86, all trivial; cleaning them up:
      
      EVT_TO_HPET_DEV() - made static, it is only used in kernel/hpet.c
      
      Debug version of check_iommu_entries() is an __init function.
      Non-debug dummy empty version of it is declared "inline" instead -
      which doesn't help to eliminate it (the caller is in a different unit,
      inlining doesn't happen).
      Switch to non-inlined __init function, which does eliminate it
      (by discarding it as part of __init section).
      
      crypto/sha-mb/sha1_mb.c: looks like they just forgot to add "static"
      to their two internal inlines, which emitted two unused functions into
      vmlinux.
      
            text     data      bss       dec     hex filename
        95903394 20860288 35991552 152755234 91adc22 vmlinux_before
        95903266 20860288 35991552 152755106 91adba2 vmlinux
      Signed-off-by: NDenys Vlasenko <dvlasenk@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/1460739626-12179-1-git-send-email-dvlasenk@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      a3819e3e
  5. 13 4月, 2016 1 次提交
    • A
      x86/vdso: Remove direct HPET access through the vDSO · 1ed95e52
      Andy Lutomirski 提交于
      Allowing user code to map the HPET is problematic.  HPET
      implementations are notoriously buggy, and there are probably many
      machines on which even MMIO reads from bogus HPET addresses are
      problematic.
      
      We have a report that the Dell Precision M2800 with:
      
        ACPI: HPET 0x00000000C8FE6238 000038 (v01 DELL   CBX3  01072009 AMI. 00000005)
      
      is either so slow when accessing the HPET or actually hangs in some
      regard, causing soft lockups to be reported if users do unexpected
      things to the HPET.
      
      The vclock HPET code has also always been a questionable speedup.
      Accessing an HPET is exceedingly slow (on the order of several
      microseconds), so the added overhead in requiring a syscall to read
      the HPET is a small fraction of the total code of accessing it.
      
      To avoid future problems, let's just delete the code entirely.
      
      In the long run, this could actually be a speedup.  Waiman Long as a
      patch to optimize the case where multiple CPUs contend for the HPET,
      but that won't help unless all the accesses are mediated by the
      kernel.
      Reported-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NBorislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Waiman Long <Waiman.Long@hpe.com>
      Cc: Waiman Long <waiman.long@hpe.com>
      Link: http://lkml.kernel.org/r/d2f90bba98db9905041cff294646d290d378f67a.1460074438.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1ed95e52
  6. 19 3月, 2016 1 次提交
  7. 30 1月, 2016 1 次提交
  8. 21 10月, 2015 1 次提交
  9. 31 7月, 2015 1 次提交
  10. 14 7月, 2015 1 次提交
  11. 06 7月, 2015 2 次提交
  12. 21 6月, 2015 1 次提交
  13. 20 6月, 2015 1 次提交
  14. 24 4月, 2015 3 次提交
  15. 13 2月, 2015 1 次提交
  16. 16 5月, 2014 1 次提交
  17. 08 5月, 2014 1 次提交
  18. 06 5月, 2014 1 次提交
  19. 26 3月, 2014 1 次提交
  20. 20 3月, 2014 1 次提交
    • S
      x86, hpet: Fix CPU hotplug callback registration · 9014ad2a
      Srivatsa S. Bhat 提交于
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the hpet code in x86 by using this latter form of callback registration.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9014ad2a
  21. 19 3月, 2014 1 次提交
  22. 05 3月, 2014 1 次提交
  23. 28 1月, 2013 1 次提交
  24. 03 11月, 2012 1 次提交
  25. 25 5月, 2012 1 次提交
  26. 07 5月, 2012 2 次提交
  27. 22 12月, 2011 1 次提交
    • K
      driver-core: remove sysdev.h usage. · edbaa603
      Kay Sievers 提交于
      The sysdev.h file should not be needed by any in-kernel code, so remove
      the .h file from these random files that seem to still want to include
      it.
      
      The sysdev code will be going away soon, so this include needs to be
      removed no matter what.
      
      Cc: Jiandong Zheng <jdzheng@broadcom.com>
      Cc: Scott Branden <sbranden@broadcom.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Daniel Walker <dwalker@fifo99.com>
      Cc: Bryan Huntsman <bryanh@codeaurora.org>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: Wan ZongShun <mcuos.com@gmail.com>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: "Venkatesh Pallipadi
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Matthew Garrett <mjg@redhat.com>
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      edbaa603
  28. 09 12月, 2011 1 次提交
  29. 05 12月, 2011 1 次提交
  30. 01 11月, 2011 1 次提交
    • P
      x86: Fix files explicitly requiring export.h for EXPORT_SYMBOL/THIS_MODULE · 69c60c88
      Paul Gortmaker 提交于
      These files were implicitly getting EXPORT_SYMBOL via device.h
      which was including module.h, but that will be fixed up shortly.
      
      By fixing these now, we can avoid seeing things like:
      
      arch/x86/kernel/rtc.c:29: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
      arch/x86/kernel/pci-dma.c:20: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
      arch/x86/kernel/e820.c:69: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL_GPL’
      
      [ with input from Randy Dunlap <rdunlap@xenotime.net> and also
        from Stephen Rothwell <sfr@canb.auug.org.au> ]
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      69c60c88
  31. 15 7月, 2011 1 次提交
  32. 14 7月, 2011 1 次提交
  33. 09 6月, 2011 2 次提交
  34. 06 6月, 2011 1 次提交
  35. 19 5月, 2011 1 次提交