1. 31 Oct, 2014 1 commit
  2. 27 Oct, 2014 1 commit
  3. 24 Oct, 2014 1 commit
  4. 13 Oct, 2014 1 commit
    • Nishanth Aravamudan's avatar
      powerpc/numa: Add ability to disable and debug topology updates · 2d73bae1
      Nishanth Aravamudan authored
      We have hit a few customer issues with the topology update code (VPHN
      and PRRN). It would be nice to be able to debug the notifications coming
      from the hypervisor in both cases to the LPAR, as well as to disable
      responding to the notifications at boot-time, to narrow down the source
      of the problems. Add a basic level of such functionality, similar to the
      numa= command-line parameter. We already have a toggle in
      /proc/powerpc/topology_updates that allows run-time enabling/disabling,
      so the updates can be started at run-time if desired. But the bugs we've
      run into have occured during boot or very shortly after coming to login,
      and have resulted in a broken NUMA topology.
      Signed-off-by: default avatarNishanth Aravamudan <nacc@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      2d73bae1
  5. 11 Oct, 2014 1 commit
    • Dmitry Torokhov's avatar
      Input: i8042 - disable active multiplexing by default · 68da1664
      Dmitry Torokhov authored
      Active multiplexing is a nice feature as it allows several pointing devices
      (such as touchpad and external mouse) use their native protocols at the
      same time. Unfortunately many manufacturers do not implement the feature
      properly even though they advertise it. The problematic implementations are
      never fixed, since Windows by default does not use this mode, and move from
      one BIOS/model of laptop to another. When active multiplexing is broken
      turning it on usually results in touchpad, keyboard, or both unresponsive.
      
      With PS/2 usage on decline (most of PS/2 devices in use nowadays are
      internal laptop touchpads), I expect number of users who have laptops with
      working MUX implementation, docking stations with external PS/2 ports, and
      who are still using external PS/2 mice, to be rather small. Let's flip the
      default to be OFF and allow activating it through i8042.nomux=0 kernel
      option.  We'll also keep DMI table where we can record known good models.
      Acked-by: default avatarJiri Kosina <jkosina@suse.cz>
      Acked-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      68da1664
  6. 09 Oct, 2014 2 commits
  7. 03 Oct, 2014 3 commits
    • Dave Young's avatar
      efi: Add kernel param efi=noruntime · 5ae3683c
      Dave Young authored
      noefi kernel param means actually disabling efi runtime, Per suggestion
      from Leif Lindholm efi=noruntime should be better. But since noefi is
      already used in X86 thus just adding another param efi=noruntime for
      same purpose.
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      5ae3683c
    • Dave Young's avatar
      efi: Move noefi early param code out of x86 arch code · b2e0a54a
      Dave Young authored
      noefi param can be used for arches other than X86 later, thus move it
      out of x86 platform code.
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      b2e0a54a
    • Matt Fleming's avatar
      efi: Add efi= parameter parsing to the EFI boot stub · 5a17dae4
      Matt Fleming authored
      We need a way to customize the behaviour of the EFI boot stub, in
      particular, we need a way to disable the "chunking" workaround, used
      when reading files from the EFI System Partition.
      
      One of my machines doesn't cope well when reading files in 1MB chunks to
      a buffer above the 4GB mark - it appears that the "chunking" bug
      workaround triggers another firmware bug. This was only discovered with
      commit 4bf7111f ("x86/efi: Support initrd loaded above 4G"), and
      that commit is perfectly valid. The symptom I observed was a corrupt
      initrd rather than any kind of crash.
      
      efi= is now used to specify EFI parameters in two very different
      execution environments, the EFI boot stub and during kernel boot.
      
      There is also a slight performance optimization by enabling efi=nochunk,
      but that's offset by the fact that you're more likely to run into
      firmware issues, at least on x86. This is the rationale behind leaving
      the workaround enabled by default.
      
      Also provide some documentation for EFI_READ_CHUNK_SIZE and why we're
      using the current value of 1MB.
      Tested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Roy Franz <roy.franz@linaro.org>
      Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Borislav Petkov <bp@suse.de>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      5a17dae4
  8. 30 Sep, 2014 1 commit
  9. 28 Sep, 2014 2 commits
  10. 23 Sep, 2014 2 commits
  11. 17 Sep, 2014 1 commit
    • Dmitry Kasatkin's avatar
      ima: provide 'ima_appraise=log' kernel option · 2faa6ef3
      Dmitry Kasatkin authored
      The kernel boot parameter "ima_appraise" currently defines 'off',
      'enforce' and 'fix' modes.  When designing a policy and labeling
      the system, access to files are either blocked in the default
      'enforce' mode or automatically fixed in the 'fix' mode.  It is
      beneficial to be able to run the system in a logging only mode,
      without fixing it, in order to properly analyze the system. This
      patch adds a 'log' mode to run the system in a permissive mode and
      log the appraisal results.
      Signed-off-by: default avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      2faa6ef3
  12. 16 Sep, 2014 2 commits
  13. 08 Sep, 2014 2 commits
  14. 07 Sep, 2014 2 commits
    • Paul E. McKenney's avatar
      rcu: Add stall-warning checks for RCU-tasks · 52db30ab
      Paul E. McKenney authored
      This commit adds a ten-minute RCU-tasks stall warning.  The actual
      time is controlled by the boot/sysfs parameter rcu_task_stall_timeout,
      with values less than or equal to zero disabling the stall warnings.
      The default value is ten minutes, which means that the tasks that have
      not yet responded will get their stacks dumped every ten minutes, until
      they pass through a voluntary context switch.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      52db30ab
    • Paul E. McKenney's avatar
      rcutorture: Add callback-flood test · 38706bc5
      Paul E. McKenney authored
      Although RCU is designed to handle arbitrary floods of callbacks, this
      capability is not routinely tested.   This commit therefore adds a
      cbflood capability in which kthreads repeatedly registers large numbers
      of callbacks.  One such kthread is created for each four CPUs (rounding
      up), and the test may be controlled by several cbflood_* kernel boot
      parameters, which control the number of bursts per flood, the number
      of callbacks per burst, the time between bursts, and the time between
      floods.  The default values are large enough to exercise RCU's emergency
      responses to callback flooding.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: David Miller <davem@davemloft.net>
      Reviewed-by: default avatarPranith Kumar <bobby.prani@gmail.com>
      38706bc5
  15. 06 Aug, 2014 1 commit
    • Luis R. Rodriguez's avatar
      printk: allow increasing the ring buffer depending on the number of CPUs · 23b2899f
      Luis R. Rodriguez authored
      The default size of the ring buffer is too small for machines with a
      large amount of CPUs under heavy load.  What ends up happening when
      debugging is the ring buffer overlaps and chews up old messages making
      debugging impossible unless the size is passed as a kernel parameter.
      An idle system upon boot up will on average spew out only about one or
      two extra lines but where this really matters is on heavy load and that
      will vary widely depending on the system and environment.
      
      There are mechanisms to help increase the kernel ring buffer for tracing
      through debugfs, and those interfaces even allow growing the kernel ring
      buffer per CPU.  We also have a static value which can be passed upon
      boot.  Relying on debugfs however is not ideal for production, and
      relying on the value passed upon bootup is can only used *after* an
      issue has creeped up.  Instead of being reactive this adds a proactive
      measure which lets you scale the amount of contributions you'd expect to
      the kernel ring buffer under load by each CPU in the worst case
      scenario.
      
      We use num_possible_cpus() to avoid complexities which could be
      introduced by dynamically changing the ring buffer size at run time,
      num_possible_cpus() lets us use the upper limit on possible number of
      CPUs therefore avoiding having to deal with hotplugging CPUs on and off.
      This introduces the kernel configuration option LOG_CPU_MAX_BUF_SHIFT
      which is used to specify the maximum amount of contributions to the
      kernel ring buffer in the worst case before the kernel ring buffer flips
      over, the size is specified as a power of 2.  The total amount of
      contributions made by each CPU must be greater than half of the default
      kernel ring buffer size (1 << LOG_BUF_SHIFT bytes) in order to trigger
      an increase upon bootup.  The kernel ring buffer is increased to the
      next power of two that would fit the required minimum kernel ring buffer
      size plus the additional CPU contribution.  For example if LOG_BUF_SHIFT
      is 18 (256 KB) you'd require at least 128 KB contributions by other CPUs
      in order to trigger an increase of the kernel ring buffer.  With a
      LOG_CPU_BUF_SHIFT of 12 (4 KB) you'd require at least anything over > 64
      possible CPUs to trigger an increase.  If you had 128 possible CPUs the
      amount of minimum required kernel ring buffer bumps to:
      
         ((1 << 18) + ((128 - 1) * (1 << 12))) / 1024 = 764 KB
      
      Since we require the ring buffer to be a power of two the new required
      size would be 1024 KB.
      
      This CPU contributions are ignored when the "log_buf_len" kernel
      parameter is used as it forces the exact size of the ring buffer to an
      expected power of two value.
      
      [pmladek@suse.cz: fix build]
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.cz>
      Tested-by: default avatarDavidlohr Bueso <davidlohr@hp.com>
      Tested-by: default avatarPetr Mladek <pmladek@suse.cz>
      Reviewed-by: default avatarDavidlohr Bueso <davidlohr@hp.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Arun KS <arunks.linux@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      23b2899f
  16. 01 Aug, 2014 1 commit
  17. 22 Jul, 2014 1 commit
  18. 17 Jul, 2014 4 commits
    • Dmitry Kasatkin's avatar
      KEYS: validate certificate trust only with builtin keys · 32c4741c
      Dmitry Kasatkin authored
      Instead of allowing public keys, with certificates signed by any
      key on the system trusted keyring, to be added to a trusted keyring,
      this patch further restricts the certificates to those signed only by
      builtin keys on the system keyring.
      
      This patch defines a new option 'builtin' for the kernel parameter
      'keys_ownerid' to allow trust validation using builtin keys.
      
      Simplified Mimi's "KEYS: define an owner trusted keyring" patch
      
      Changelog v7:
      - rename builtin_keys to use_builtin_keys
      Signed-off-by: default avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      32c4741c
    • Dmitry Kasatkin's avatar
      KEYS: validate certificate trust only with selected key · ffb70f61
      Dmitry Kasatkin authored
      Instead of allowing public keys, with certificates signed by any
      key on the system trusted keyring, to be added to a trusted keyring,
      this patch further restricts the certificates to those signed by a
      particular key on the system keyring.
      
      This patch defines a new kernel parameter 'ca_keys' to identify the
      specific key which must be used for trust validation of certificates.
      
      Simplified Mimi's "KEYS: define an owner trusted keyring" patch.
      
      Changelog:
      - support for builtin x509 public keys only
      - export "asymmetric_keyid_match"
      - remove ifndefs MODULE
      - rename kernel boot parameter from keys_ownerid to ca_keys
      Signed-off-by: default avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      ffb70f61
    • Dmitry Kasatkin's avatar
      ima: introduce multi-page collect buffers · 6edf7a89
      Dmitry Kasatkin authored
      Use of multiple-page collect buffers reduces:
      1) the number of block IO requests
      2) the number of asynchronous hash update requests
      
      Second is important for HW accelerated hashing, because significant
      amount of time is spent for preparation of hash update operation,
      which includes configuring acceleration HW, DMA engine, etc...
      Thus, HW accelerators are more efficient when working on large
      chunks of data.
      
      This patch introduces usage of multi-page collect buffers. Buffer size
      can be specified using 'ahash_bufsize' module parameter. Default buffer
      size is 4096 bytes.
      
      Changes in v3:
      - kernel parameter replaced with module parameter
      Signed-off-by: default avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      6edf7a89
    • Dmitry Kasatkin's avatar
      ima: use ahash API for file hash calculation · 3bcced39
      Dmitry Kasatkin authored
      Async hash API allows the use of HW acceleration for hash calculation.
      It may give significant performance gain and/or reduce power consumption,
      which might be very beneficial for battery powered devices.
      
      This patch introduces hash calculation using ahash API. ahash performance
      depends on the data size and the particular HW. Depending on the specific
      system, shash performance may be better.
      
      This patch defines 'ahash_minsize' module parameter, which is used to
      define the minimal file size to use with ahash.  If this minimum file size
      is not set or the file is smaller than defined by the parameter, shash will
      be used.
      
      Changes in v3:
      - kernel parameter replaced with module parameter
      - pr_crit replaced with pr_crit_ratelimited
      - more comment changes - Mimi
      
      Changes in v2:
      - ima_ahash_size became as ima_ahash
      - ahash pre-allocation moved out from __init code to be able to use
        ahash crypto modules. Ahash allocated once on the first use.
      - hash calculation falls back to shash if ahash allocation/calculation fails
      - complex initialization separated from variable declaration
      - improved comments
      Signed-off-by: default avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      3bcced39
  19. 14 Jul, 2014 2 commits
  20. 08 Jul, 2014 1 commit
  21. 07 Jul, 2014 1 commit
    • Paul E. McKenney's avatar
      rcu: Parallelize and economize NOCB kthread wakeups · fbce7497
      Paul E. McKenney authored
      An 80-CPU system with a context-switch-heavy workload can require so
      many NOCB kthread wakeups that the RCU grace-period kthreads spend several
      tens of percent of a CPU just awakening things.  This clearly will not
      scale well: If you add enough CPUs, the RCU grace-period kthreads would
      get behind, increasing grace-period latency.
      
      To avoid this problem, this commit divides the NOCB kthreads into leaders
      and followers, where the grace-period kthreads awaken the leaders each of
      whom in turn awakens its followers.  By default, the number of groups of
      kthreads is the square root of the number of CPUs, but this default may
      be overridden using the rcutree.rcu_nocb_leader_stride boot parameter.
      This reduces the number of wakeups done per grace period by the RCU
      grace-period kthread by the square root of the number of CPUs, but of
      course by shifting those wakeups to the leaders.  In addition, because
      the leaders do grace periods on behalf of their respective followers,
      the number of wakeups of the followers decreases by up to a factor of two.
      Instead of being awakened once when new callbacks arrive and again
      at the end of the grace period, the followers are awakened only at
      the end of the grace period.
      
      For a numerical example, in a 4096-CPU system, the grace-period kthread
      would awaken 64 leaders, each of which would awaken its 63 followers
      at the end of the grace period.  This compares favorably with the 79
      wakeups for the grace-period kthread on an 80-CPU system.
      Reported-by: default avatarRik van Riel <riel@redhat.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      fbce7497
  22. 01 Jul, 2014 1 commit
  23. 23 Jun, 2014 2 commits
    • Aaron Tomlin's avatar
      kernel/watchdog.c: print traces for all cpus on lockup detection · ed235875
      Aaron Tomlin authored
      A 'softlockup' is defined as a bug that causes the kernel to loop in
      kernel mode for more than a predefined period to time, without giving
      other tasks a chance to run.
      
      Currently, upon detection of this condition by the per-cpu watchdog
      task, debug information (including a stack trace) is sent to the system
      log.
      
      On some occasions, we have observed that the "victim" rather than the
      actual "culprit" (i.e.  the owner/holder of the contended resource) is
      reported to the user.  Often this information has proven to be
      insufficient to assist debugging efforts.
      
      To avoid loss of useful debug information, for architectures which
      support NMI, this patch makes it possible to improve soft lockup
      reporting.  This is accomplished by issuing an NMI to each cpu to obtain
      a stack trace.
      
      If NMI is not supported we just revert back to the old method.  A sysctl
      and boot-time parameter is available to toggle this feature.
      
      [dzickus@redhat.com: add CONFIG_SMP in certain areas]
      [akpm@linux-foundation.org: additional CONFIG_SMP=n optimisations]
      [mq@suse.cz: fix warning]
      Signed-off-by: default avatarAaron Tomlin <atomlin@redhat.com>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Mateusz Guzik <mguzik@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarJan Moskyto Matejka <mq@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ed235875
    • Paul E. McKenney's avatar
      rcu: Reduce overhead of cond_resched() checks for RCU · 4a81e832
      Paul E. McKenney authored
      Commit ac1bea85 (Make cond_resched() report RCU quiescent states)
      fixed a problem where a CPU looping in the kernel with but one runnable
      task would give RCU CPU stall warnings, even if the in-kernel loop
      contained cond_resched() calls.  Unfortunately, in so doing, it introduced
      performance regressions in Anton Blanchard's will-it-scale "open1" test.
      The problem appears to be not so much the increased cond_resched() path
      length as an increase in the rate at which grace periods complete, which
      increased per-update grace-period overhead.
      
      This commit takes a different approach to fixing this bug, mainly by
      moving the RCU-visible quiescent state from cond_resched() to
      rcu_note_context_switch(), and by further reducing the check to a
      simple non-zero test of a single per-CPU variable.  However, this
      approach requires that the force-quiescent-state processing send
      resched IPIs to the offending CPUs.  These will be sent only once
      the grace period has reached an age specified by the boot/sysfs
      parameter rcutree.jiffies_till_sched_qs, or once the grace period
      reaches an age halfway to the point at which RCU CPU stall warnings
      will be emitted, whichever comes first.
      Reported-by: default avatarDave Hansen <dave.hansen@intel.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Christoph Lameter <cl@gentwo.org>
      Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      [ paulmck: Made rcu_momentary_dyntick_idle() as suggested by the
        ktest build robot.  Also fixed smp_mb() comment as noted by
        Oleg Nesterov. ]
      
      Merge with e552592e (Reduce overhead of cond_resched() checks for RCU)
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      4a81e832
  24. 16 Jun, 2014 2 commits
  25. 06 Jun, 2014 1 commit
  26. 04 Jun, 2014 1 commit
    • Prarit Bhargava's avatar
      init/main.c: add initcall_blacklist kernel parameter · 7b0b73d7
      Prarit Bhargava authored
      When a module is built into the kernel the module_init() function
      becomes an initcall.  Sometimes debugging through dynamic debug can
      help, however, debugging built in kernel modules is typically done by
      changing the .config, recompiling, and booting the new kernel in an
      effort to determine exactly which module caused a problem.
      
      This patchset can be useful stand-alone or combined with initcall_debug.
      There are cases where some initcalls can hang the machine before the
      console can be flushed, which can make initcall_debug output inaccurate.
      Having the ability to skip initcalls can help further debugging of these
      scenarios.
      
      Usage: initcall_blacklist=<list of comma separated initcalls>
      
      ex) added "initcall_blacklist=sgi_uv_sysfs_init" as a kernel parameter and
      the log contains:
      
      	blacklisting initcall sgi_uv_sysfs_init
      	...
      	...
      	initcall sgi_uv_sysfs_init blacklisted
      
      ex) added "initcall_blacklist=foo_bar,sgi_uv_sysfs_init" as a kernel parameter
      and the log contains:
      
      	blacklisting initcall foo_bar
      	blacklisting initcall sgi_uv_sysfs_init
      	...
      	...
      	initcall sgi_uv_sysfs_init blacklisted
      
      [akpm@linux-foundation.org: tweak printk text]
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Cc: Richard Weinberger <richard.weinberger@gmail.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: Rob Landley <rob@landley.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7b0b73d7