1. 10 2月, 2016 1 次提交
    • T
      workqueue: implement "workqueue.debug_force_rr_cpu" debug feature · f303fccb
      Tejun Heo 提交于
      Workqueue used to guarantee local execution for work items queued
      without explicit target CPU.  The guarantee is gone now which can
      break some usages in subtle ways.  To flush out those cases, this
      patch implements a debug feature which forces round-robin CPU
      selection for all such work items.
      
      The debug feature defaults to off and can be enabled with a kernel
      parameter.  The default can be flipped with a debug config option.
      
      If you hit this commit during bisection, please refer to 041bd12e
      ("Revert "workqueue: make sure delayed work run in local cpu"") for
      more information and ping me.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      f303fccb
  2. 04 2月, 2016 1 次提交
    • K
      mm: warn about VmData over RLIMIT_DATA · d977d56c
      Konstantin Khlebnikov 提交于
      This patch provides a way of working around a slight regression
      introduced by commit 84638335 ("mm: rework virtual memory
      accounting").
      
      Before that commit RLIMIT_DATA have control only over size of the brk
      region.  But that change have caused problems with all existing versions
      of valgrind, because it set RLIMIT_DATA to zero.
      
      This patch fixes rlimit check (limit actually in bytes, not pages) and
      by default turns it into warning which prints at first VmData misuse:
      
        "mmap: top (795): VmData 516096 exceed data ulimit 512000.  Will be forbidden soon."
      
      Behavior is controlled by boot param ignore_rlimit_data=y/n and by sysfs
      /sys/module/kernel/parameters/ignore_rlimit_data.  For now it set to "y".
      
      [akpm@linux-foundation.org: tweak kernel-parameters.txt text[
      Signed-off-by: NKonstantin Khlebnikov <koct9i@gmail.com>
      Link: http://lkml.kernel.org/r/20151228211015.GL2194@uranusReported-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Vegard Nossum <vegard.nossum@oracle.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Vladimir Davydov <vdavydov@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Kees Cook <keescook@google.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Pavel Emelyanov <xemul@virtuozzo.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d977d56c
  3. 21 1月, 2016 1 次提交
  4. 20 1月, 2016 1 次提交
    • M
      MIPS: Add IEEE Std 754 conformance mode selection · 503943e0
      Maciej W. Rozycki 提交于
      Add an `ieee754=' kernel parameter to control IEEE Std 754 conformance
      mode.
      
      Use separate flags copied from the respective CPU feature flags, and
      adjusted according to the conformance mode selected, to make binaries
      requesting individual NaN encoding modes accepted or rejected as needed.
      Update the initial setting for FCSR and, in the full FPU emulation mode,
      its read-only mask accordingly.  Accept the mode selection requested for
      legacy processors as well.
      
      As with the EF_MIPS_NAN2008 ELF file header flag adjust both ABS2008 and
      NAN2008 bits at the same time, to match the choice made for hardware
      currently implemented.
      Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Matthew Fortune <Matthew.Fortune@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/11481/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      503943e0
  5. 15 1月, 2016 2 次提交
  6. 07 1月, 2016 1 次提交
  7. 26 12月, 2015 1 次提交
  8. 19 12月, 2015 1 次提交
    • H
      x86/apic: Introduce apic_extnmi command line parameter · b7c4948e
      Hidehiro Kawai 提交于
      This patch introduces a command line parameter apic_extnmi:
      
       apic_extnmi=( bsp|all|none )
      
      The default value is "bsp" and this is the current behavior: only the
      Boot-Strapping Processor receives an external NMI.
      
      "all" allows external NMIs to be broadcast to all CPUs. This would
      raise the success rate of panic on NMI when BSP hangs in NMI context
      or the external NMI is swallowed by other NMI handlers on the BSP.
      
      If you specify "none", no CPUs receive external NMIs. This is useful for
      the dump capture kernel so that it cannot be shot down by accidentally
      pressing the external NMI button (on platforms which have it) while
      saving a crash dump.
      Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Bandan Das <bsd@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: kexec@lists.infradead.org
      Cc: linux-doc@vger.kernel.org
      Cc: "Maciej W. Rozycki" <macro@linux-mips.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: x86-ml <x86@kernel.org>
      Link: http://lkml.kernel.org/r/20151210014632.25437.43778.stgit@softrsSigned-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      b7c4948e
  9. 14 12月, 2015 1 次提交
  10. 09 12月, 2015 1 次提交
    • T
      workqueue: implement lockup detector · 82607adc
      Tejun Heo 提交于
      Workqueue stalls can happen from a variety of usage bugs such as
      missing WQ_MEM_RECLAIM flag or concurrency managed work item
      indefinitely staying RUNNING.  These stalls can be extremely difficult
      to hunt down because the usual warning mechanisms can't detect
      workqueue stalls and the internal state is pretty opaque.
      
      To alleviate the situation, this patch implements workqueue lockup
      detector.  It periodically monitors all worker_pools periodically and,
      if any pool failed to make forward progress longer than the threshold
      duration, triggers warning and dumps workqueue state as follows.
      
       BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 31s!
       Showing busy workqueues and worker pools:
       workqueue events: flags=0x0
         pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=17/256
           pending: monkey_wrench_fn, e1000_watchdog, cache_reap, vmstat_shepherd, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, cgroup_release_agent
       workqueue events_power_efficient: flags=0x80
         pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
           pending: check_lifetime, neigh_periodic_work
       workqueue cgroup_pidlist_destroy: flags=0x0
         pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
           pending: cgroup_pidlist_destroy_work_fn
       ...
      
      The detection mechanism is controller through kernel parameter
      workqueue.watchdog_thresh and can be updated at runtime through the
      sysfs module parameter file.
      
      v2: Decoupled from softlockup control knobs.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NDon Zickus <dzickus@redhat.com>
      Cc: Ulrich Obergfell <uobergfe@redhat.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Chris Mason <clm@fb.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      82607adc
  11. 08 12月, 2015 1 次提交
  12. 05 12月, 2015 3 次提交
  13. 02 12月, 2015 1 次提交
    • A
      USB: limit usbfs snooping of URB contents · 0290cc9f
      Alan Stern 提交于
      The usbfs_snoop facility can be very useful for debugging problems
      involving usbfs.  However, it always prints out the entire contents of
      every URB.  When dealing with large quantities of data, this can be
      less than helpful.
      
      This patch ameliorates the situation by adding a module parameter to
      usbcore for controlling the maximum number of bytes to print when
      snooping an URB.  This makes debugging much easier.  For backward
      compatibility, the default value is set unreasonably high.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0290cc9f
  14. 01 12月, 2015 1 次提交
  15. 19 11月, 2015 1 次提交
  16. 06 11月, 2015 1 次提交
  17. 26 10月, 2015 1 次提交
  18. 18 10月, 2015 1 次提交
  19. 15 10月, 2015 1 次提交
  20. 12 10月, 2015 2 次提交
    • T
      efi: Add "efi_fake_mem" boot option · 0f96a99d
      Taku Izumi 提交于
      This patch introduces new boot option named "efi_fake_mem".
      By specifying this parameter, you can add arbitrary attribute
      to specific memory range.
      This is useful for debugging of Address Range Mirroring feature.
      
      For example, if "efi_fake_mem=2G@4G:0x10000,2G@0x10a0000000:0x10000"
      is specified, the original (firmware provided) EFI memmap will be
      updated so that the specified memory regions have
      EFI_MEMORY_MORE_RELIABLE attribute (0x10000):
      
       <original>
         efi: mem36: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000100000000-0x00000020a0000000) (129536MB)
      
       <updated>
         efi: mem36: [Conventional Memory|  |MR|  |  |  |   |WB|WT|WC|UC] range=[0x0000000100000000-0x0000000180000000) (2048MB)
         efi: mem37: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000180000000-0x00000010a0000000) (61952MB)
         efi: mem38: [Conventional Memory|  |MR|  |  |  |   |WB|WT|WC|UC] range=[0x00000010a0000000-0x0000001120000000) (2048MB)
         efi: mem39: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000001120000000-0x00000020a0000000) (63488MB)
      
      And you will find that the following message is output:
      
         efi: Memory: 4096M/131455M mirrored memory
      Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Xishi Qiu <qiuxishi@huawei.com>
      Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      0f96a99d
    • P
      doc: Clarify that nmi_watchdog param is for hardlockups · 334bb79c
      Pranith Kumar 提交于
      The kernel NMI watchdog acts as both a hardlockup and softlockup detector.
      However, the kernel parameter nmi_watchdog can only enable or disable the
      hardlockup detector. Clarify that in the documentation.
      Signed-off-by: NPranith Kumar <bobby.prani@gmail.com>
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      334bb79c
  21. 07 10月, 2015 1 次提交
  22. 01 10月, 2015 1 次提交
  23. 25 9月, 2015 2 次提交
  24. 08 9月, 2015 1 次提交
  25. 28 8月, 2015 1 次提交
  26. 26 8月, 2015 1 次提交
  27. 20 8月, 2015 1 次提交
    • J
      xen: allow more than 512 GB of RAM for 64 bit pv-domains · c70727a5
      Juergen Gross 提交于
      64 bit pv-domains under Xen are limited to 512 GB of RAM today. The
      main reason has been the 3 level p2m tree, which was replaced by the
      virtual mapped linear p2m list. Parallel to the p2m list which is
      being used by the kernel itself there is a 3 level mfn tree for usage
      by the Xen tools and eventually for crash dump analysis. For this tree
      the linear p2m list can serve as a replacement, too. As the kernel
      can't know whether the tools are capable of dealing with the p2m list
      instead of the mfn tree, the limit of 512 GB can't be dropped in all
      cases.
      
      This patch replaces the hard limit by a kernel parameter which tells
      the kernel to obey the 512 GB limit or not. The default is selected by
      a configuration parameter which specifies whether the 512 GB limit
      should be active per default for domUs (domain save/restore/migration
      and crash dump analysis are affected).
      
      Memory above the domain limit is returned to the hypervisor instead of
      being identity mapped, which was wrong anyway.
      
      The kernel configuration parameter to specify the maximum size of a
      domain can be deleted, as it is not relevant any more.
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Acked-by: NKonrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      c70727a5
  28. 17 7月, 2015 1 次提交
  29. 16 7月, 2015 1 次提交
  30. 03 7月, 2015 1 次提交
    • R
      ACPI / init: Make it possible to override _REV · 18d78b64
      Rafael J. Wysocki 提交于
      The platform firmware on some systems expects Linux to return "5" as
      the supported ACPI revision which makes it expose system configuration
      information in a special way.
      
      For example, based on what ACPI exports as the supported revision,
      Dell XPS 13 (2015) configures its audio device to either work in HDA
      mode or in I2S mode, where the former is supposed to be used on Linux
      until the latter is fully supported (in the kernel as well as in user
      space).
      
      Since ACPI 6 mandates that _REV should return "2" if ACPI 2 or later
      is supported by the OS, a subsequent change will make that happen, so
      make it possible to override that on systems where "5" is expected to
      be returned for Linux to work correctly one them (such as the Dell
      machine mentioned above).
      Original-by: NDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      18d78b64
  31. 23 6月, 2015 1 次提交
  32. 16 6月, 2015 1 次提交
    • M
      ima: update builtin policies · 24fd03c8
      Mimi Zohar 提交于
      This patch defines a builtin measurement policy "tcb", similar to the
      existing "ima_tcb", but with additional rules to also measure files
      based on the effective uid and to measure files opened with the "read"
      mode bit set (eg. read, read-write).
      
      Changing the builtin "ima_tcb" policy could potentially break existing
      users.  Instead of defining a new separate boot command line option each
      time the builtin measurement policy is modified, this patch defines a
      single generic boot command line option "ima_policy=" to specify the
      builtin policy and deprecates the use of the builtin ima_tcb policy.
      
      [The "ima_policy=" boot command line option is based on Roberto Sassu's
      "ima: added new policy type exec" patch.]
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NDr. Greg Wettstein <gw@idfusion.org>
      Cc: stable@vger.kernel.org
      24fd03c8
  33. 12 6月, 2015 1 次提交
    • D
      iommu/vt-d: Only enable extended context tables if PASID is supported · c83b2f20
      David Woodhouse 提交于
      Although the extended tables are theoretically a completely orthogonal
      feature to PASID and anything else that *uses* the newly-available bits,
      some of the early hardware has problems even when all we do is enable
      them and use only the same bits that were in the old context tables.
      
      For now, there's no motivation to support extended tables unless we're
      going to use PASID support to do SVM. So just don't use them unless
      PASID support is advertised too. Also add a command-line bailout just in
      case later chips also have issues.
      
      The equivalent problem for PASID support has already been fixed with the
      upcoming VT-d spec update and commit bd00c606 ("iommu/vt-d: Change
      PASID support to bit 40 of Extended Capability Register"), because the
      problematic platforms use the old definition of the PASID-capable bit,
      which is now marked as reserved and meaningless.
      
      So with this change, we'll magically start using ECS again only when we
      see the new hardware advertising "hey, we have PASID support and we
      actually tested it this time" on bit 40.
      
      The VT-d hardware architect has promised that we are not going to have
      any reason to support ECS *without* PASID any time soon, and he'll make
      sure he checks with us before changing that.
      
      In the future, if hypothetical new features also use new bits in the
      context tables and can be seen on implementations *without* PASID support,
      we might need to add their feature bits to the ecs_enabled() macro.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      c83b2f20
  34. 09 6月, 2015 1 次提交
    • D
      x86/mpx: Introduce a boot-time disable flag · 8c3641e9
      Dave Hansen 提交于
      MPX has the _potential_ to cause some issues.  Say part of your
      init system tried to protect one of its components from buffer
      overflows with MPX.  If there were a false positive, it's
      possible that MPX could keep a system from booting.
      
      MPX could also potentially cause performance issues since it is
      present in hot paths like the unmap path.
      
      Allow it to be disabled at boot time.
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Reviewed-by: Thomas Gleixner <tglx@linutronix.de
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave@sr71.net>
      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>
      Link: http://lkml.kernel.org/r/20150607183702.2E8B77AB@viggo.jf.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      8c3641e9
  35. 01 6月, 2015 1 次提交