1. 13 11月, 2013 2 次提交
    • P
      drivers/char/hpet.c: allow user controlled mmap for user processes · 3d035f58
      Prarit Bhargava 提交于
      The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET
      registers to userspace.  The Kconfig help points out that in some cases
      this can be a security risk as some systems may erroneously configure the
      map such that additional data is exposed to userspace.
      
      This is a problem for distributions -- some users want the MMAP
      functionality but it comes with a significant security risk.  In an effort
      to mitigate this risk, and due to the low number of users of the MMAP
      functionality, I've introduced a kernel parameter, hpet_mmap_enable, that
      is required in order to actually have the HPET MMAP exposed.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Acked-by: NMatt Wilson <msw@amazon.com>
      Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Tomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3d035f58
    • T
      mem-hotplug: introduce movable_node boot option · c5320926
      Tang Chen 提交于
      The hot-Pluggable field in SRAT specifies which memory is hotpluggable.
      As we mentioned before, if hotpluggable memory is used by the kernel, it
      cannot be hot-removed.  So memory hotplug users may want to set all
      hotpluggable memory in ZONE_MOVABLE so that the kernel won't use it.
      
      Memory hotplug users may also set a node as movable node, which has
      ZONE_MOVABLE only, so that the whole node can be hot-removed.
      
      But the kernel cannot use memory in ZONE_MOVABLE.  By doing this, the
      kernel cannot use memory in movable nodes.  This will cause NUMA
      performance down.  And other users may be unhappy.
      
      So we need a way to allow users to enable and disable this functionality.
      In this patch, we introduce movable_node boot option to allow users to
      choose to not to consume hotpluggable memory at early boot time and later
      we can set it as ZONE_MOVABLE.
      
      To achieve this, the movable_node boot option will control the memblock
      allocation direction.  That said, after memblock is ready, before SRAT is
      parsed, we should allocate memory near the kernel image as we explained in
      the previous patches.  So if movable_node boot option is set, the kernel
      does the following:
      
      1. After memblock is ready, make memblock allocate memory bottom up.
      2. After SRAT is parsed, make memblock behave as default, allocate memory
         top down.
      
      Users can specify "movable_node" in kernel commandline to enable this
      functionality.  For those who don't use memory hotplug or who don't want
      to lose their NUMA performance, just don't specify anything.  The kernel
      will work as before.
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Signed-off-by: NZhang Yanfei <zhangyanfei@cn.fujitsu.com>
      Suggested-by: NKamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Suggested-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NTejun Heo <tj@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Jiang Liu <jiang.liu@huawei.com>
      Cc: Wen Congyang <wency@cn.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c5320926
  2. 29 10月, 2013 1 次提交
  3. 18 10月, 2013 1 次提交
  4. 16 10月, 2013 1 次提交
  5. 01 10月, 2013 2 次提交
  6. 25 9月, 2013 1 次提交
  7. 05 9月, 2013 1 次提交
  8. 24 8月, 2013 1 次提交
  9. 05 8月, 2013 1 次提交
    • C
      vt: make the default color configurable · 3855ae1c
      Clemens Ladisch 提交于
      The virtual console has (undocumented) module parameters to set the
      colors for italic and underlined text, but the default text color was
      hardcoded for some reason.  This made it impossible to change the color
      for startup messages, or to set the default for new virtual consoles.
      Add a module parameter for that, and document the entire bunch.
      
      Any hacker who thinks that a command prompt on a "black screen with
      white font" is not supicious enough can now use the kernel parameter
      vt.color=10 to get a nice, evil green.
      Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3855ae1c
  10. 23 7月, 2013 2 次提交
    • L
      ACPI: Add facility to remove all _OSI strings · 741d8128
      Lv Zheng 提交于
      This patch changes the "acpi_osi=" boot parameter implementation so
      that:
      1. "acpi_osi=!" can be used to disable all _OSI OS vendor strings by
         default.  It is meaningless to specify "acpi_osi=!" multiple
         times as it can only affect the default state of the target _OSI
         strings.
      2. "acpi_osi=!*" can be used to remove all _OSI OS vendor strings
         and all _OSI feature group strings.  It is useful to specify
         "acpi_osi=!*" multiple times through kernel command line to
         override the current state of the target _OSI strings.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Reviewed-by: NZhang Rui <rui.zhang@intel.com>
      Acked-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      741d8128
    • L
      ACPI: Add facility to disable all _OSI OS vendor strings · 5dc17986
      Lv Zheng 提交于
      This patch introduces "acpi_osi=!" command line to force Linux replying
      "UNSUPPORTED" to all of the _OSI strings.  This patch is based on an
      ACPICA enhancement - the new API acpi_update_interfaces().
      
      The _OSI object provides the platform with the ability to query OSPM
      to determine the set of ACPI related interfaces, behaviors, or
      features that the operating system supports.  The argument passed to
      the _OSI is a string like the followings:
      1. Feature Group String, examples include
         Module Device
         Processor Device
         3.0 _SCP Extensions
         Processor Aggregator Device
         ...
      2. OS Vendor String, examples include
         Linux
         FreeBSD
         Windows
         ...
      
      There are AML codes provided in the ACPI namespace written in the
      following style to determine OSPM interfaces / features:
          Method(OSCK)
          {
              if (CondRefOf(_OSI, Local0))
              {
                  if (\_OSI("Windows"))
                  {
                      Return (One)
                  }
                  if (\_OSI("Windows 2006"))
                  {
                      Return (Ones)
                  }
                  Return (Zero)
              }
              Return (Zero)
          }
      
      There is a debugging facility implemented in Linux.  Users can pass
      "acpi_osi=" boot parameters to the kernel to tune the _OSI evaluation
      result so that certain AML codes can be executed.  Current
      implementation includes:
      1. 'acpi_osi=' - this makes CondRefOf(_OSI, Local0) TRUE
      2. 'acpi_osi="Windows"' - this makes \_OSI("Windows") TRUE
      3. 'acpi_osi="!Windows"' - this makes \_OSI("Windows") FALSE
      The function to implement this feature is also used as a quirk mechanism
      in the Linux ACPI subystem.
      
      When _OSI is evaluatated by the AML codes, ACPICA replies "SUPPORTED"
      to all Windows operating system vendor strings.  This is because
      Windows operating systems return "SUPPORTED" if the argument to the
      _OSI method specifies an earlier version of Windows.  Please refer to
      the following MSDN document:
      
      How to Identify the Windows Version in ACPI by Using _OSI
      http://msdn.microsoft.com/en-us/library/hardware/gg463275.aspx
      
      This adds difficulties when developers want to feed specific Windows
      operating system vendor string to the BIOS codes for debugging
      purpose, multiple acpi_osi="!xxx" have to be specified in the command
      line to force Linux replying "UNSUPPORTED" to the Windows OS vendor
      strings listed in the AML codes.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Reviewed-by: NZhang Rui <rui.zhang@intel.com>
      Acked-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5dc17986
  11. 10 7月, 2013 1 次提交
  12. 21 6月, 2013 1 次提交
  13. 20 6月, 2013 2 次提交
    • M
      integrity: move integrity_audit_msg() · d726d8d7
      Mimi Zohar 提交于
      This patch moves the integrity_audit_msg() function and defintion to
      security/integrity/, the parent directory, renames the 'ima_audit'
      boot command line option to 'integrity_audit', and fixes the Kconfig
      help text to reflect the actual code.
      
      Changelog:
      - Fixed ifdef inclusion of integrity_audit_msg() (Fengguang Wu)
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      d726d8d7
    • S
      tracing: Disable tracing on warning · de7edd31
      Steven Rostedt (Red Hat) 提交于
      Add a traceoff_on_warning option in both the kernel command line as well
      as a sysctl option. When set, any WARN*() function that is hit will cause
      the tracing_on variable to be cleared, which disables writing to the
      ring buffer.
      
      This is useful especially when tracing a bug with function tracing. When
      a warning is hit, the print caused by the warning can flood the trace with
      the functions that producing the output for the warning. This can make the
      resulting trace useless by either hiding where the bug happened, or worse,
      by overflowing the buffer and losing the trace of the bug totally.
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      de7edd31
  14. 15 6月, 2013 1 次提交
  15. 22 5月, 2013 1 次提交
    • V
      libata: Add atapi_dmadir force flag · 966fbe19
      Vincent Pelletier 提交于
      Some device require DMADIR to be enabled, but are not detected as such
      by atapi_id_dmadir.  One such example is "Asus Serillel 2"
      SATA-host-to-PATA-device bridge: the bridge itself requires DMADIR,
      even if the bridged device does not.
      
      As atapi_dmadir module parameter can cause problems with some devices
      (as per Tejun Heo's memory), enabling it globally may not be possible
      depending on the hardware.
      
      This patch adds atapi_dmadir in the form of a "force" horkage value,
      allowing global, per-bus and per-device control.
      Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      966fbe19
  16. 17 5月, 2013 1 次提交
  17. 15 5月, 2013 3 次提交
    • K
      xen/tmem: Don't use self[ballooning|shrinking] if frontswap is off. · 37d46e15
      Konrad Rzeszutek Wilk 提交于
      There is no point. We would just squeeze the guest to put more and
      more pages in the swap disk without any purpose.
      
      The only time it makes sense to use the selfballooning and shrinking
      is when frontswap is being utilized.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      37d46e15
    • K
      xen/tmem: Remove the boot options and fold them in the tmem.X parameters. · 2ca62b04
      Konrad Rzeszutek Wilk 提交于
      If tmem is built-in or a module, the user has the option on
      the command line to influence it by doing: tmem.<some option>
      instead of having a variety of "nocleancache", and
      "nofrontswap". The others: "noselfballooning" and "selfballooning";
      and "noselfshrink" are in a different driver xen-selfballoon.c
      and the patches:
      
       xen/tmem: Remove the usage of 'noselfshrink' and use 'tmem.selfshrink' bool instead.
       xen/tmem: Remove the usage of 'noselfballoon','selfballoon' and use 'tmem.selfballon' bool instead.
      
      remove them.
      
      Also add documentation.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      2ca62b04
    • V
      workqueues: Introduce new flag WQ_POWER_EFFICIENT for power oriented workqueues · cee22a15
      Viresh Kumar 提交于
      Workqueues can be performance or power-oriented. Currently, most workqueues are
      bound to the CPU they were created on. This gives good performance (due to cache
      effects) at the cost of potentially waking up otherwise idle cores (Idle from
      scheduler's perspective. Which may or may not be physically idle) just to
      process some work. To save power, we can allow the work to be rescheduled on a
      core that is already awake.
      
      Workqueues created with the WQ_UNBOUND flag will allow some power savings.
      However, we don't change the default behaviour of the system.  To enable
      power-saving behaviour, a new config option CONFIG_WQ_POWER_EFFICIENT needs to
      be turned on. This option can also be overridden by the
      workqueue.power_efficient boot parameter.
      
      tj: Updated config description and comments.  Renamed
          CONFIG_WQ_POWER_EFFICIENT to CONFIG_WQ_POWER_EFFICIENT_DEFAULT.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: NAmit Kucheria <amit.kucheria@linaro.org>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      cee22a15
  18. 28 4月, 2013 1 次提交
  19. 20 4月, 2013 1 次提交
  20. 19 4月, 2013 2 次提交
    • F
      nohz: Ensure full dynticks CPUs are RCU nocbs · d1e43fa5
      Frederic Weisbecker 提交于
      We need full dynticks CPU to also be RCU nocb so
      that we don't have to keep the tick to handle RCU
      callbacks.
      
      Make sure the range passed to nohz_full= boot
      parameter is a subset of rcu_nocbs=
      
      The CPUs that fail to meet this requirement will be
      excluded from the nohz_full range. This is checked
      early in boot time, before any CPU has the opportunity
      to stop its tick.
      Suggested-by: NSteven Rostedt <rostedt@goodmis.org>
      Reviewed-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Geoff Levand <geoff@infradead.org>
      Cc: Gilad Ben Yossef <gilad@benyossef.com>
      Cc: Hakan Akkan <hakanakkan@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      d1e43fa5
    • F
      nohz: Force boot CPU outside full dynticks range · 0453b435
      Frederic Weisbecker 提交于
      The timekeeping job must be able to run early on boot
      because there may be some pre-SMP (and thus pre-initcalls )
      components that rely on it. The IO-APIC is one such users
      as it tests the timer health by watching jiffies progression.
      
      Given that it happens before we know the initial online
      set, we can't rely on it to select a timekeeper. We need
      one before SMP time otherwise we simply crash on boot.
      
      To fix this and keep things simple for now, force the boot CPU
      outside of the full dynticks range in any case and do this early
      on kernel parameter parsing time.
      
      We might want a trickier solution later, expecially for aSMP
      architectures that need to assign housekeeping tasks to arbitrary
      low power CPUs.
      
      But it's still first pass KISS time for now.
      Reviewed-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Geoff Levand <geoff@infradead.org>
      Cc: Gilad Ben Yossef <gilad@benyossef.com>
      Cc: Hakan Akkan <hakanakkan@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      0453b435
  21. 18 4月, 2013 3 次提交
  22. 17 4月, 2013 2 次提交
  23. 16 4月, 2013 1 次提交
    • F
      nohz: Switch from "extended nohz" to "full nohz" based naming · c5bfece2
      Frederic Weisbecker 提交于
      "Extended nohz" was used as a naming base for the full dynticks
      API and Kconfig symbols. It reflects the fact the system tries
      to stop the tick in more places than just idle.
      
      But that "extended" name is a bit opaque and vague. Rename it to
      "full" makes it clearer what the system tries to do under this
      config: try to shutdown the tick anytime it can. The various
      constraints that prevent that to happen shouldn't be considered
      as fundamental properties of this feature but rather technical
      issues that may be solved in the future.
      Reported-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Geoff Levand <geoff@infradead.org>
      Cc: Gilad Ben Yossef <gilad@benyossef.com>
      Cc: Hakan Akkan <hakanakkan@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      c5bfece2
  24. 11 4月, 2013 1 次提交
  25. 02 4月, 2013 1 次提交
    • T
      workqueue: update sysfs interface to reflect NUMA awareness and a kernel param... · d55262c4
      Tejun Heo 提交于
      workqueue: update sysfs interface to reflect NUMA awareness and a kernel param to disable NUMA affinity
      
      Unbound workqueues are now NUMA aware.  Let's add some control knobs
      and update sysfs interface accordingly.
      
      * Add kernel param workqueue.numa_disable which disables NUMA affinity
        globally.
      
      * Replace sysfs file "pool_id" with "pool_ids" which contain
        node:pool_id pairs.  This change is userland-visible but "pool_id"
        hasn't seen a release yet, so this is okay.
      
      * Add a new sysf files "numa" which can toggle NUMA affinity on
        individual workqueues.  This is implemented as attrs->no_numa whichn
        is special in that it isn't part of a pool's attributes.  It only
        affects how apply_workqueue_attrs() picks which pools to use.
      
      After "pool_ids" change, first_pwq() doesn't have any user left.
      Removed.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NLai Jiangshan <laijs@cn.fujitsu.com>
      d55262c4
  26. 27 3月, 2013 2 次提交
  27. 26 3月, 2013 2 次提交
  28. 21 3月, 2013 1 次提交
    • F
      nohz: Basic full dynticks interface · a831881b
      Frederic Weisbecker 提交于
      For extreme usecases such as Real Time or HPC, having
      the ability to shutdown the tick when a single task runs
      on a CPU is a desired feature:
      
      * Reducing the amount of interrupts improves throughput
      for CPU-bound tasks. The CPU is less distracted from its
      real job, from an execution time and from the cache point
      of views.
      
      * This also improve latency response as we have less critical
      sections.
      
      Start with introducing a very simple interface to define
      full dynticks CPU: use a boot time option defined cpumask
      through the "nohz_extended=" kernel parameter. CPUs that
      are part of this range will have their tick shutdown
      whenever possible: provided they run a single task and
      they don't do kernel activity that require the periodic
      tick. These details will be later documented in
      Documentation/*
      
      An online CPU must be kept outside this range to handle the
      timekeeping.
      Suggested-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Geoff Levand <geoff@infradead.org>
      Cc: Gilad Ben Yossef <gilad@benyossef.com>
      Cc: Hakan Akkan <hakanakkan@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      a831881b