1. 28 Jun, 2016 1 commit
  2. 20 May, 2016 1 commit
  3. 05 May, 2016 1 commit
  4. 04 May, 2016 1 commit
  5. 30 Apr, 2016 1 commit
  6. 27 Apr, 2016 2 commits
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Enable PPC enforcement for servers · 2b3ec765
      Srinivas Pandruvada authored
      For platforms which are controlled via remove node manager, enable _PPC by
      default. These platforms are mostly categorized as enterprise server or
      performance servers. These platforms needs to go through some
      certifications tests, which tests control via _PPC.
      The relative risk of enabling by default is  low as this is is less likely
      that these systems have broken _PSS table.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Enforce _PPC limits · 9522a2ff
      Srinivas Pandruvada authored
      Use ACPI _PPC notification to limit max P state driver will request.
      ACPI _PPC change notification is sent by BIOS to limit max P state
      in several cases:
      - Reduce impact of platform thermal condition
      - When Config TDP feature is used, a changed _PPC is sent to
      follow TDP change
      - Remote node managers in server want to control platform power
      via baseboard management controller (BMC)
      This change registers with ACPI processor performance lib so that
      _PPC changes are notified to cpufreq core, which in turns will
      result in call to .setpolicy() callback. Also the way _PSS
      table identifies a turbo frequency is not compatible to max turbo
      frequency in intel_pstate, so the very first entry in _PSS needs
      to be adjusted.
      This feature can be turned on by using kernel parameters:
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      [ rjw: Minor cleanups ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  7. 26 Apr, 2016 1 commit
  8. 15 Apr, 2016 1 commit
  9. 13 Apr, 2016 1 commit
  10. 07 Apr, 2016 1 commit
  11. 04 Apr, 2016 1 commit
  12. 01 Apr, 2016 1 commit
    • Alex Thorlton's avatar
      x86/platform/uv: Disable UV BAU by default · 1c532e00
      Alex Thorlton authored
      For several years, the common practice has been to boot UVs with the
      "nobau" parameter on the command line, to disable the BAU.  We've
      decided that it makes more sense to just disable the BAU by default in
      the kernel, and provide the option to turn it on, if desired.
      For now, having the on/off switch doesn't buy us any more than just
      reversing the logic would, but we're working towards having the BAU
      enabled by default on UV4.  When those changes are in place, having the
      on/off switch will make more sense than an enable flag, since the
      default behavior will be different depending on the system version.
      I've also added a bit of documentation for the new parameter to
      Signed-off-by: default avatarAlex Thorlton <athorlton@sgi.com>
      Reviewed-by: default avatarHedi Berriche <hedi@sgi.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      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/1459451909-121845-1-git-send-email-athorlton@sgi.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  13. 31 Mar, 2016 2 commits
  14. 15 Mar, 2016 2 commits
    • Laura Abbott's avatar
      mm/page_poison.c: enable PAGE_POISONING as a separate option · 8823b1db
      Laura Abbott authored
      Page poisoning is currently set up as a feature if architectures don't
      have architecture debug page_alloc to allow unmapping of pages.  It has
      uses apart from that though.  Clearing of the pages on free provides an
      increase in security as it helps to limit the risk of information leaks.
      Allow page poisoning to be enabled as a separate option independent of
      kernel_map pages since the two features do separate work.  Because of
      how hiberanation is implemented, the checks on alloc cannot occur if
      hibernation is enabled.  The runtime alloc checks can also be enabled
      with an option when !HIBERNATION.
      Credit to Grsecurity/PaX team for inspiring this work
      Signed-off-by: default avatarLaura Abbott <labbott@fedoraproject.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mathias Krause <minipli@googlemail.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Jianyu Zhan <nasa4836@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Taku Izumi's avatar
      mm/page_alloc.c: introduce kernelcore=mirror option · 342332e6
      Taku Izumi authored
      This patch extends existing "kernelcore" option and introduces
      kernelcore=mirror option.  By specifying "mirror" instead of specifying
      the amount of memory, non-mirrored (non-reliable) region will be
      arranged into ZONE_MOVABLE.
      [akpm@linux-foundation.org: fix build with CONFIG_HAVE_MEMBLOCK_NODE_MAP=n]
      Signed-off-by: default avatarTaku Izumi <izumi.taku@jp.fujitsu.com>
      Tested-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Xishi Qiu <qiuxishi@huawei.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Steve Capper <steve.capper@linaro.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  15. 11 Mar, 2016 1 commit
  16. 09 Mar, 2016 1 commit
  17. 08 Mar, 2016 1 commit
  18. 01 Mar, 2016 1 commit
    • Heiko Stuebner's avatar
      phy: rockchip-usb: add handler for usb-uart functionality · 605df8af
      Heiko Stuebner authored
      Most newer Rockchip SoCs provide the possibility to use a usb-phy
      as passthrough for the debug uart (uart2), making it possible to
      for example get console output without needing to open the device.
      This patch adds an early_initcall to enable this functionality
      conditionally via the commandline and also disables the corresponding
      usb controller in the devicetree.
      Currently only data for the rk3288 is provided, but at least the
      rk3188 and arm64 rk3368 also provide this functionality and will be
      enabled later.
      On a spliced usb cable the signals are tx on white wire(D+) and
      rx on green wire(D-).
      The one caveat is that currently the reconfiguration of the phy
      happens as early_initcall, as the code depends on the unflattened
      devicetree being available. Everything is fine if only a regular
      console is active as the console-replay will happen after the
      reconfiguation. But with earlycon active output up to smp-init
      currently will get lost.
      The phy is an optional property for the connected dwc2 controller,
      so we still provide the phy device but fail all phy-ops with -EBUSY
      to make sure the dwc2 does not try to transmit anything on the
      repurposed phy.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
  19. 22 Feb, 2016 1 commit
    • Kees Cook's avatar
      mm/init: Add 'rodata=off' boot cmdline parameter to disable read-only kernel mappings · d2aa1aca
      Kees Cook authored
      It may be useful to debug writes to the readonly sections of memory,
      so provide a cmdline "rodata=off" to allow for this. This can be
      expanded in the future to support "log" and "write" modes, but that
      will need to be architecture-specific.
      This also makes KDB software breakpoints more usable, as read-only
      mappings can now be disabled on any kernel.
      Suggested-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David Brown <david.brown@linaro.org>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Emese Revfy <re.emese@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mathias Krause <minipli@googlemail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: PaX Team <pageexec@freemail.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kernel-hardening@lists.openwall.com
      Cc: linux-arch <linux-arch@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1455748879-21872-3-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  20. 18 Feb, 2016 1 commit
    • Dave Hansen's avatar
      x86/mm/pkeys: Actually enable Memory Protection Keys in the CPU · 06976945
      Dave Hansen authored
      This sets the bit in 'cr4' to actually enable the protection
      keys feature.  We also include a boot-time disable for the
      feature "nopku".
      Seting X86_CR4_PKE will cause the X86_FEATURE_OSPKE cpuid
      bit to appear set.  At this point in boot, identify_cpu()
      has already run the actual CPUID instructions and populated
      the "cpu features" structures.  We need to go back and
      re-run identify_cpu() to make sure it gets updated values.
      We *could* simply re-populate the 11th word of the cpuid
      data, but this is probably quick enough.
      Also note that with the cpu_has() check and X86_FEATURE_PKU
      present in disabled-features.h, we do not need an #ifdef
      for setup_pku().
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20160212210229.6708027C@viggo.jf.intel.com
      [ Small readability edits. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  21. 16 Feb, 2016 1 commit
  22. 09 Feb, 2016 3 commits
    • Tejun Heo's avatar
      workqueue: implement "workqueue.debug_force_rr_cpu" debug feature · f303fccb
      Tejun Heo authored
      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: default avatarTejun Heo <tj@kernel.org>
    • Andy Lutomirski's avatar
      x86/mm: Add a 'noinvpcid' boot option to turn off INVPCID · d12a72b8
      Andy Lutomirski authored
      This adds a chicken bit to turn off INVPCID in case something goes
      wrong.  It's an early_param() because we do TLB flushes before we
      parse __setup() parameters.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/f586317ed1bc2b87aee652267e515b90051af385.1454096309.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • Mel Gorman's avatar
      sched/debug: Make schedstats a runtime tunable that is disabled by default · cb251765
      Mel Gorman authored
      schedstats is very useful during debugging and performance tuning but it
      incurs overhead to calculate the stats. As such, even though it can be
      disabled at build time, it is often enabled as the information is useful.
      This patch adds a kernel command-line and sysctl tunable to enable or
      disable schedstats on demand (when it's built in). It is disabled
      by default as someone who knows they need it can also learn to enable
      it when necessary.
      The benefits are dependent on how scheduler-intensive the workload is.
      If it is then the patch reduces the number of cycles spent calculating
      the stats with a small benefit from reducing the cache footprint of the
      These measurements were taken from a 48-core 2-socket
      machine with Xeon(R) E5-2670 v3 cpus although they were also tested on a
      single socket machine 8-core machine with Intel i7-3770 processors.
                                 4.5.0-rc1             4.5.0-rc1
                                   vanilla          nostats-v3r1
      Hmean    64         560.45 (  0.00%)      575.98 (  2.77%)
      Hmean    128        766.66 (  0.00%)      795.79 (  3.80%)
      Hmean    256        950.51 (  0.00%)      981.50 (  3.26%)
      Hmean    1024      1433.25 (  0.00%)     1466.51 (  2.32%)
      Hmean    2048      2810.54 (  0.00%)     2879.75 (  2.46%)
      Hmean    3312      4618.18 (  0.00%)     4682.09 (  1.38%)
      Hmean    4096      5306.42 (  0.00%)     5346.39 (  0.75%)
      Hmean    8192     10581.44 (  0.00%)    10698.15 (  1.10%)
      Hmean    16384    18857.70 (  0.00%)    18937.61 (  0.42%)
      Small gains here, UDP_STREAM showed nothing intresting and neither did
      the TCP_RR tests. The gains on the 8-core machine were very similar.
                                       4.5.0-rc1             4.5.0-rc1
                                         vanilla          nostats-v3r1
      Hmean    mb/sec-1         500.85 (  0.00%)      522.43 (  4.31%)
      Hmean    mb/sec-2         984.66 (  0.00%)     1018.19 (  3.41%)
      Hmean    mb/sec-4        1827.91 (  0.00%)     1847.78 (  1.09%)
      Hmean    mb/sec-8        3561.36 (  0.00%)     3611.28 (  1.40%)
      Hmean    mb/sec-16       5824.52 (  0.00%)     5929.03 (  1.79%)
      Hmean    mb/sec-32      10943.10 (  0.00%)    10802.83 ( -1.28%)
      Hmean    mb/sec-64      15950.81 (  0.00%)    16211.31 (  1.63%)
      Hmean    mb/sec-128     15302.17 (  0.00%)    15445.11 (  0.93%)
      Hmean    mb/sec-256     14866.18 (  0.00%)    15088.73 (  1.50%)
      Hmean    mb/sec-512     15223.31 (  0.00%)    15373.69 (  0.99%)
      Hmean    mb/sec-1024    14574.25 (  0.00%)    14598.02 (  0.16%)
      Hmean    mb/sec-2048    13569.02 (  0.00%)    13733.86 (  1.21%)
      Hmean    mb/sec-3072    12865.98 (  0.00%)    13209.23 (  2.67%)
      Small gains of 2-4% at low thread counts and otherwise flat.  The
      gains on the 8-core machine were slightly different
      tbench4 on 8-core i7-3770 single socket machine
      Hmean    mb/sec-1        442.59 (  0.00%)      448.73 (  1.39%)
      Hmean    mb/sec-2        796.68 (  0.00%)      794.39 ( -0.29%)
      Hmean    mb/sec-4       1322.52 (  0.00%)     1343.66 (  1.60%)
      Hmean    mb/sec-8       2611.65 (  0.00%)     2694.86 (  3.19%)
      Hmean    mb/sec-16      2537.07 (  0.00%)     2609.34 (  2.85%)
      Hmean    mb/sec-32      2506.02 (  0.00%)     2578.18 (  2.88%)
      Hmean    mb/sec-64      2511.06 (  0.00%)     2569.16 (  2.31%)
      Hmean    mb/sec-128     2313.38 (  0.00%)     2395.50 (  3.55%)
      Hmean    mb/sec-256     2110.04 (  0.00%)     2177.45 (  3.19%)
      Hmean    mb/sec-512     2072.51 (  0.00%)     2053.97 ( -0.89%)
      In constract, this shows a relatively steady 2-3% gain at higher thread
      counts. Due to the nature of the patch and the type of workload, it's
      not a surprise that the result will depend on the CPU used.
                               4.5.0-rc1             4.5.0-rc1
                                 vanilla          nostats-v3r1
      Amean    1        0.0637 (  0.00%)      0.0660 ( -3.59%)
      Amean    4        0.1229 (  0.00%)      0.1181 (  3.84%)
      Amean    7        0.1921 (  0.00%)      0.1911 (  0.52%)
      Amean    12       0.3117 (  0.00%)      0.2923 (  6.23%)
      Amean    21       0.4050 (  0.00%)      0.3899 (  3.74%)
      Amean    30       0.4586 (  0.00%)      0.4433 (  3.33%)
      Amean    48       0.5910 (  0.00%)      0.5694 (  3.65%)
      Amean    79       0.8663 (  0.00%)      0.8626 (  0.43%)
      Amean    110      1.1543 (  0.00%)      1.1517 (  0.22%)
      Amean    141      1.4457 (  0.00%)      1.4290 (  1.16%)
      Amean    172      1.7090 (  0.00%)      1.6924 (  0.97%)
      Amean    192      1.9126 (  0.00%)      1.9089 (  0.19%)
      Some small gains and losses and while the variance data is not included,
      it's close to the noise. The UMA machine did not show anything particularly
                                   4.5.0-rc1             4.5.0-rc1
                                     vanilla          nostats-v2r2
      Min         Time        4.13 (  0.00%)        3.99 (  3.39%)
      1st-qrtle   Time        4.38 (  0.00%)        4.27 (  2.51%)
      2nd-qrtle   Time        4.46 (  0.00%)        4.39 (  1.57%)
      3rd-qrtle   Time        4.56 (  0.00%)        4.51 (  1.10%)
      Max-90%     Time        4.67 (  0.00%)        4.60 (  1.50%)
      Max-93%     Time        4.71 (  0.00%)        4.65 (  1.27%)
      Max-95%     Time        4.74 (  0.00%)        4.71 (  0.63%)
      Max-99%     Time        4.88 (  0.00%)        4.79 (  1.84%)
      Max         Time        4.93 (  0.00%)        4.83 (  2.03%)
      Mean        Time        4.48 (  0.00%)        4.39 (  1.91%)
      Best99%Mean Time        4.47 (  0.00%)        4.39 (  1.91%)
      Best95%Mean Time        4.46 (  0.00%)        4.38 (  1.93%)
      Best90%Mean Time        4.45 (  0.00%)        4.36 (  1.98%)
      Best50%Mean Time        4.36 (  0.00%)        4.25 (  2.49%)
      Best10%Mean Time        4.23 (  0.00%)        4.10 (  3.13%)
      Best5%Mean  Time        4.19 (  0.00%)        4.06 (  3.20%)
      Best1%Mean  Time        4.13 (  0.00%)        4.00 (  3.39%)
      Small improvement and similar gains were seen on the UMA machine.
      The gain is small but it stands to reason that doing less work in the
      scheduler is a good thing. The downside is that the lack of schedstats and
      tracepoints may be surprising to experts doing performance analysis until
      they find the existence of the schedstats= parameter or schedstats sysctl.
      It will be automatically activated for latencytop and sleep profiling to
      alleviate the problem. For tracepoints, there is a simple warning as it's
      not safe to activate schedstats in the context when it's known the tracepoint
      may be wanted but is unavailable.
      Signed-off-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Reviewed-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Reviewed-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <mgalbraith@suse.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1454663316-22048-1-git-send-email-mgorman@techsingularity.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  23. 08 Feb, 2016 1 commit
  24. 03 Feb, 2016 1 commit
    • Konstantin Khlebnikov's avatar
      mm: warn about VmData over RLIMIT_DATA · d977d56c
      Konstantin Khlebnikov authored
      This patch provides a way of working around a slight regression
      introduced by commit 84638335 ("mm: rework virtual memory
      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: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Link: http://lkml.kernel.org/r/20151228211015.GL2194@uranusReported-by: default avatarChristian 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  25. 30 Jan, 2016 1 commit
  26. 21 Jan, 2016 1 commit
  27. 19 Jan, 2016 1 commit
    • Maciej W. Rozycki's avatar
      MIPS: Add IEEE Std 754 conformance mode selection · 503943e0
      Maciej W. Rozycki authored
      Add an `ieee754=' kernel parameter to control IEEE Std 754 conformance
      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: default avatarMaciej 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: default avatarRalf Baechle <ralf@linux-mips.org>
  28. 15 Jan, 2016 1 commit
  29. 14 Jan, 2016 1 commit
  30. 07 Jan, 2016 1 commit
  31. 26 Dec, 2015 1 commit
  32. 19 Dec, 2015 1 commit
    • Hidehiro Kawai's avatar
      x86/apic: Introduce apic_extnmi command line parameter · b7c4948e
      Hidehiro Kawai authored
      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: default avatarHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Acked-by: default avatarMichal 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: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  33. 14 Dec, 2015 1 commit
  34. 08 Dec, 2015 2 commits
    • Tejun Heo's avatar
      workqueue: implement lockup detector · 82607adc
      Tejun Heo authored
      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: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarDon 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>
    • Paul E. McKenney's avatar
      rcu: Remove TINY_RCU bloat from pointless boot parameters · 79cfea02
      Paul E. McKenney authored
      The rcu_expedited, rcu_normal, and rcu_normal_after_boot kernel boot
      parameters are pointless in the case of TINY_RCU because in that case
      synchronous grace periods, both expedited and normal, are no-ops.
      However, these three symbols contribute several hundred bytes of bloat.
      This commit therefore uses CPP directives to avoid compiling this code
      in TINY_RCU kernels.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: Josh Triplett's avatarJosh Triplett <josh@joshtriplett.org>