Skip to content
Snippets Groups Projects
  1. Nov 13, 2013
    • Prarit Bhargava's avatar
      drivers/char/hpet.c: allow user controlled mmap for user processes · 3d035f58
      Prarit Bhargava authored
      
      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: default avatarPrarit Bhargava <prarit@redhat.com>
      Acked-by: default avatarMatt Wilson <msw@amazon.com>
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Tomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3d035f58
    • Tang Chen's avatar
      mem-hotplug: introduce movable_node boot option · c5320926
      Tang Chen authored
      
      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: default avatarTang Chen <tangchen@cn.fujitsu.com>
      Signed-off-by: default avatarZhang Yanfei <zhangyanfei@cn.fujitsu.com>
      Suggested-by: default avatarKamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Suggested-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarToshi 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c5320926
  2. Oct 28, 2013
  3. Oct 27, 2013
    • Mimi Zohar's avatar
      ima: enable support for larger default filedata hash algorithms · e7a2ad7e
      Mimi Zohar authored
      
      The IMA measurement list contains two hashes - a template data hash
      and a filedata hash.  The template data hash is committed to the TPM,
      which is limited, by the TPM v1.2 specification, to 20 bytes.  The
      filedata hash is defined as 20 bytes as well.
      
      Now that support for variable length measurement list templates was
      added, the filedata hash is not limited to 20 bytes.  This patch adds
      Kconfig support for defining larger default filedata hash algorithms
      and replacing the builtin default with one specified on the kernel
      command line.
      
      <uapi/linux/hash_info.h> contains a list of hash algorithms.  The
      Kconfig default hash algorithm is a subset of this list, but any hash
      algorithm included in the list can be specified at boot, using the
      'ima_hash=' kernel command line option.
      
      Changelog v2:
      - update Kconfig
      
      Changelog:
      - support hashes that are configured
      - use generic HASH_ALGO_ definitions
      - add Kconfig support
      - hash_setup must be called only once (Dmitry)
      - removed trailing whitespaces (Roberto Sassu)
      
      Signed-off-by: default avatarMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: default avatarRoberto Sassu <roberto.sassu@polito.it>
      e7a2ad7e
    • Roberto Sassu's avatar
      ima: define kernel parameter 'ima_template=' to change configured default · 9b9d4ce5
      Roberto Sassu authored
      
      This patch allows users to specify from the kernel command line the
      template descriptor, among those defined, that will be used to generate
      and display measurement entries. If an user specifies a wrong template,
      IMA reverts to the template descriptor set in the kernel configuration.
      
      Signed-off-by: default avatarRoberto Sassu <roberto.sassu@polito.it>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      9b9d4ce5
  4. Oct 17, 2013
  5. Oct 15, 2013
  6. Sep 30, 2013
  7. Sep 25, 2013
  8. Sep 04, 2013
  9. Aug 23, 2013
  10. Aug 05, 2013
    • Clemens Ladisch's avatar
      vt: make the default color configurable · 3855ae1c
      Clemens Ladisch authored
      
      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: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3855ae1c
  11. Jul 23, 2013
    • Lv Zheng's avatar
      ACPI: Add facility to remove all _OSI strings · 741d8128
      Lv Zheng authored
      
      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: default avatarLv Zheng <lv.zheng@intel.com>
      Reviewed-by: default avatarZhang Rui <rui.zhang@intel.com>
      Acked-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      741d8128
    • Lv Zheng's avatar
      ACPI: Add facility to disable all _OSI OS vendor strings · 5dc17986
      Lv Zheng authored
      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: default avatarLv Zheng <lv.zheng@intel.com>
      Reviewed-by: default avatarZhang Rui <rui.zhang@intel.com>
      Acked-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5dc17986
  12. Jul 09, 2013
  13. Jun 20, 2013
  14. Jun 14, 2013
  15. May 21, 2013
    • Vincent Pelletier's avatar
      libata: Add atapi_dmadir force flag · 966fbe19
      Vincent Pelletier authored
      
      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: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      966fbe19
  16. May 17, 2013
  17. May 15, 2013
  18. May 14, 2013
    • Viresh Kumar's avatar
      workqueues: Introduce new flag WQ_POWER_EFFICIENT for power oriented workqueues · cee22a15
      Viresh Kumar authored
      
      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: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: default avatarAmit Kucheria <amit.kucheria@linaro.org>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      cee22a15
  19. Apr 28, 2013
  20. Apr 19, 2013
    • Joerg Roedel's avatar
      iommu/amd: Document ivrs_ioapic and ivrs_hpet parameters · 7d8bfa26
      Joerg Roedel authored
      
      Document the new kernel commandline parameters in the
      appropriate file.
      
      Reviewed-by: default avatarShuah Khan <shuahkhan@gmail.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      7d8bfa26
    • Frederic Weisbecker's avatar
      nohz: Ensure full dynticks CPUs are RCU nocbs · d1e43fa5
      Frederic Weisbecker authored
      
      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: default avatarSteven Rostedt <rostedt@goodmis.org>
      Reviewed-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarFrederic 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
    • Frederic Weisbecker's avatar
      nohz: Force boot CPU outside full dynticks range · 0453b435
      Frederic Weisbecker authored
      
      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: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarFrederic 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. Apr 17, 2013
  22. Apr 15, 2013
    • Frederic Weisbecker's avatar
      nohz: Switch from "extended nohz" to "full nohz" based naming · c5bfece2
      Frederic Weisbecker authored
      
      "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: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarFrederic 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
  23. Apr 11, 2013
  24. Apr 01, 2013
    • Tejun Heo's avatar
      workqueue: update sysfs interface to reflect NUMA awareness and a kernel param... · d55262c4
      Tejun Heo authored
      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: default avatarTejun Heo <tj@kernel.org>
      Reviewed-by: default avatarLai Jiangshan <laijs@cn.fujitsu.com>
      d55262c4
  25. Mar 27, 2013
  26. Mar 26, 2013
Loading