1. 20 Nov, 2017 1 commit
  2. 18 Nov, 2017 1 commit
  3. 16 Nov, 2017 1 commit
  4. 10 Nov, 2017 1 commit
  5. 02 Nov, 2017 1 commit
    • Marc Zyngier's avatar
      irqchip/gic: Deal with broken firmware exposing only 4kB of GICv2 CPU interface · 0962289b
      Marc Zyngier authored
      
      
      There is a lot of broken firmware out there that don't really
      expose the information the kernel requires when it comes with dealing
      with GICv2:
      
      (1) Firmware that only describes the first 4kB of GICv2
      (2) Firmware that describe 128kB of CPU interface, while
          the usable portion of the address space is between
          60 and 68kB
      
      So far, we only deal with (2). But we have platforms exhibiting
      behaviour (1), resulting in two sub-cases:
      (a) The GIC is occupying 8kB, as required by the GICv2 architecture
      (b) It is actually spread 128kB, and this is likely to be a version
          of (2)
      
      This patch tries to work around both (a) and (b) by poking at
      the outside of the described memory region, and try to work out
      what is actually there. This is of course unsafe, and should
      only be enabled if there is no way to otherwise fix the DT provided
      by the firmware (we provide a "irqchip.gicv2_force_probe" option
      to that effect).
      
      Note that for the time being, we restrict ourselves to GICv2
      implementations provided by ARM, since there I have no knowledge
      of an alternative implementations. This could be relaxed if such
      an implementation comes to light on a broken platform.
      Reviewed-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      0962289b
  6. 31 Oct, 2017 2 commits
  7. 25 Oct, 2017 1 commit
    • Byungchul Park's avatar
      locking/lockdep: Add a boot parameter allowing unwind in cross-release and disable it by default · d141babe
      Byungchul Park authored
      Johan Hovold reported a heavy performance regression caused by lockdep
      cross-release:
      
       > Boot time (from "Linux version" to login prompt) had in fact doubled
       > since 4.13 where it took 17 seconds (with my current config) compared to
       > the 35 seconds I now see with 4.14-rc4.
       >
       > I quick bisect pointed to lockdep and specifically the following commit:
       >
       >	28a903f6 ("locking/lockdep: Handle non(or multi)-acquisition
       >	               of a crosslock")
       >
       > which I've verified is the commit which doubled the boot time (compared
       > to 28a903f6
      
      ^) (added by lockdep crossrelease series [1]).
      
      Currently cross-release performs unwind on every acquisition, but that
      is very expensive.
      
      This patch makes unwind optional and disables it by default and only
      records acquire_ip.
      
      Full stack traces are sometimes required for full analysis, in which
      case a boot paramter, crossrelease_fullstack, can be specified.
      
      On my qemu Ubuntu machine (x86_64, 4 cores, 512M), the regression was
      fixed. We measure boot times with 'perf stat --null --repeat 10 $QEMU',
      where $QEMU launches a kernel with init=/bin/true:
      
      1. No lockdep enabled:
      
       Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):
      
             2.756558155 seconds time elapsed                    ( +-  0.09% )
      
      2. Lockdep enabled:
      
       Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):
      
             2.968710420 seconds time elapsed                    ( +-  0.12% )
      
      3. Lockdep enabled + cross-release enabled:
      
       Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):
      
             3.153839636 seconds time elapsed                    ( +-  0.31% )
      
      4. Lockdep enabled + cross-release enabled + this patch applied:
      
       Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):
      
             2.963669551 seconds time elapsed                    ( +-  0.11% )
      
      I.e. lockdep cross-release performance is now indistinguishable from
      vanilla lockdep.
      Bisected-by: default avatarJohan Hovold <johan@kernel.org>
      Analyzed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reported-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarByungchul Park <byungchul.park@lge.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: amir73il@gmail.com
      Cc: axboe@kernel.dk
      Cc: darrick.wong@oracle.com
      Cc: david@fromorbit.com
      Cc: hch@infradead.org
      Cc: idryomov@gmail.com
      Cc: johannes.berg@intel.com
      Cc: kernel-team@lge.com
      Cc: linux-block@vger.kernel.org
      Cc: linux-fsdevel@vger.kernel.org
      Cc: linux-mm@kvack.org
      Cc: linux-xfs@vger.kernel.org
      Cc: oleg@redhat.com
      Cc: tj@kernel.org
      Link: http://lkml.kernel.org/r/1508921765-15396-5-git-send-email-byungchul.park@lge.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d141babe
  8. 20 Oct, 2017 1 commit
    • Cyril Bur's avatar
      powerpc/tm: Add commandline option to disable hardware transactional memory · 07fd1761
      Cyril Bur authored
      
      
      Currently the kernel relies on firmware to inform it whether or not the
      CPU supports HTM and as long as the kernel was built with
      CONFIG_PPC_TRANSACTIONAL_MEM=y then it will allow userspace to make
      use of the facility.
      
      There may be situations where it would be advantageous for the kernel
      to not allow userspace to use HTM, currently the only way to achieve
      this is to recompile the kernel with CONFIG_PPC_TRANSACTIONAL_MEM=n.
      
      This patch adds a simple commandline option so that HTM can be
      disabled at boot time.
      Signed-off-by: default avatarCyril Bur <cyrilbur@gmail.com>
      [mpe: Simplify to a bool, move to prom.c, put doco in the right place.
       Always disable, regardless of initial state, to avoid user confusion.]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      07fd1761
  9. 18 Oct, 2017 1 commit
    • Vasily Gorbik's avatar
      s390: introduce CPU alternatives · 686140a1
      Vasily Gorbik authored
      
      
      Implement CPU alternatives, which allows to optionally patch newer
      instructions at runtime, based on CPU facilities availability.
      
      A new kernel boot parameter "noaltinstr" disables patching.
      
      Current implementation is derived from x86 alternatives. Although
      ideal instructions padding (when altinstr is longer then oldinstr)
      is added at compile time, and no oldinstr nops optimization has to be
      done at runtime. Also couple of compile time sanity checks are done:
      1. oldinstr and altinstr must be <= 254 bytes long,
      2. oldinstr and altinstr must not have an odd length.
      
      alternative(oldinstr, altinstr, facility);
      alternative_2(oldinstr, altinstr1, facility1, altinstr2, facility2);
      
      Both compile time and runtime padding consists of either 6/4/2 bytes nop
      or a jump (brcl) + 2 bytes nop filler if padding is longer then 6 bytes.
      
      .altinstructions and .altinstr_replacement sections are part of
      __init_begin : __init_end region and are freed after initialization.
      Signed-off-by: default avatarVasily Gorbik <gor@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      686140a1
  10. 12 Oct, 2017 3 commits
  11. 10 Oct, 2017 1 commit
  12. 09 Oct, 2017 1 commit
  13. 07 Oct, 2017 1 commit
  14. 03 Oct, 2017 1 commit
  15. 02 Oct, 2017 1 commit
  16. 26 Sep, 2017 1 commit
  17. 20 Sep, 2017 1 commit
  18. 19 Sep, 2017 1 commit
  19. 07 Sep, 2017 1 commit
    • Michal Hocko's avatar
      mm, page_alloc: rip out ZONELIST_ORDER_ZONE · c9bff3ee
      Michal Hocko authored
      Patch series "cleanup zonelists initialization", v1.
      
      This is aimed at cleaning up the zonelists initialization code we have
      but the primary motivation was bug report [2] which got resolved but the
      usage of stop_machine is just too ugly to live.  Most patches are
      straightforward but 3 of them need a special consideration.
      
      Patch 1 removes zone ordered zonelists completely.  I am CCing linux-api
      because this is a user visible change.  As I argue in the patch
      description I do not think we have a strong usecase for it these days.
      I have kept sysctl in place and warn into the log if somebody tries to
      configure zone lists ordering.  If somebody has a real usecase for it we
      can revert this patch but I do not expect anybody will actually notice
      runtime differences.  This patch is not strictly needed for the rest but
      it made patch 6 easier to implement.
      
      Patch 7 removes stop_machine from build_all_zonelists without adding any
      special synchronization between iterators and updater which I _believe_
      is acceptable as explained in the changelog.  I hope I am not missing
      anything.
      
      Patch 8 then removes zonelists_mutex which is kind of ugly as well and
      not really needed AFAICS but a care should be taken when double checking
      my thinking.
      
      This patch (of 9):
      
      Supporting zone ordered zonelists costs us just a lot of code while the
      usefulness is arguable if existent at all.  Mel has already made node
      ordering default on 64b systems.  32b systems are still using
      ZONELIST_ORDER_ZONE because it is considered better to fallback to a
      different NUMA node rather than consume precious lowmem zones.
      
      This argument is, however, weaken by the fact that the memory reclaim
      has been reworked to be node rather than zone oriented.  This means that
      lowmem requests have to skip over all highmem pages on LRUs already and
      so zone ordering doesn't save the reclaim time much.  So the only
      advantage of the zone ordering is under a light memory pressure when
      highmem requests do not ever hit into lowmem zones and the lowmem
      pressure doesn't need to reclaim.
      
      Considering that 32b NUMA systems are rather suboptimal already and it
      is generally advisable to use 64b kernel on such a HW I believe we
      should rather care about the code maintainability and just get rid of
      ZONELIST_ORDER_ZONE altogether.  Keep systcl in place and warn if
      somebody tries to set zone ordering either from kernel command line or
      the sysctl.
      
      [mhocko@suse.com: reading vm.numa_zonelist_order will never terminate]
      Link: http://lkml.kernel.org/r/20170721143915.14161-2-mhocko@kernel.org
      
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Joonsoo Kim <js1304@gmail.com>
      Cc: Shaohua Li <shaohua.li@intel.com>
      Cc: Toshi Kani <toshi.kani@hpe.com>
      Cc: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
      Cc: <linux-api@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c9bff3ee
  20. 28 Aug, 2017 2 commits
  21. 25 Aug, 2017 1 commit
  22. 09 Aug, 2017 1 commit
    • Heiko Carstens's avatar
      s390/vmcp: make use of contiguous memory allocator · 3f429842
      Heiko Carstens authored
      
      
      If memory is fragmented it is unlikely that large order memory
      allocations succeed. This has been an issue with the vmcp device
      driver since a long time, since it requires large physical contiguous
      memory ares for large responses.
      
      To hopefully resolve this issue make use of the contiguous memory
      allocator (cma). This patch adds a vmcp specific vmcp cma area with a
      default size of 4MB. The size can be changed either via the
      VMCP_CMA_SIZE config option at compile time or with the "vmcp_cma"
      kernel parameter (e.g. "vmcp_cma=16m").
      
      For any vmcp response buffers larger than 16k memory from the cma area
      will be allocated. If such an allocation fails, there is a fallback to
      the buddy allocator.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      3f429842
  23. 27 Jul, 2017 1 commit
  24. 26 Jul, 2017 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Do not use PID-based P-state selection · 9d0ef7af
      Rafael J. Wysocki authored
      
      
      All systems with a defined ACPI preferred profile that are not
      "servers" have been using the load-based P-state selection algorithm
      in intel_pstate since 4.12-rc1 (mobile systems and laptops have been
      using it since 4.10-rc1) and no problems with it have been reported
      to date.  In particular, no regressions with respect to the PID-based
      P-state selection have been reported.  Also testing indicates that
      the P-state selection algorithm based on CPU load is generally on par
      with the PID-based algorithm performance-wise, and for some workloads
      it turns out to be better than the other one, while being more
      straightforward and easier to understand at the same time.
      
      Moreover, the PID-based P-state selection algorithm in intel_pstate
      is known to be unstable in some situation and generally problematic,
      the issues with it are hard to address and it has become a
      significant maintenance burden.
      
      For these reasons, make intel_pstate use the "powersave" P-state
      selection algorithm based on CPU load in the active mode on all
      systems and drop the PID-based P-state selection code along with
      all things related to it from the driver.  Also update the
      documentation accordingly.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9d0ef7af
  25. 25 Jul, 2017 1 commit
  26. 24 Jul, 2017 1 commit
    • Paul E. McKenney's avatar
      documentation: Fix relation between nohz_full and rcu_nocbs · f99bcb2c
      Paul E. McKenney authored
      
      
      If a CPU is specified in the nohz_full= kernel boot parameter to a
      kernel built with CONFIG_NO_HZ_FULL=y, then that CPU's callbacks will
      be offloaded, just as if that CPU had also been specified in the
      rcu_nocbs= kernel boot parameter.  But the current documentation
      states that the user must keep these two boot parameters manually
      synchronized.  This commit therefore updates the documentation to
      reflect reality.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      f99bcb2c
  27. 22 Jul, 2017 1 commit
    • Viresh Kumar's avatar
      cpufreq: governor: Drop min_sampling_rate · 2d045036
      Viresh Kumar authored
      
      
      The cpufreq core and governors aren't supposed to set a limit on how
      fast we want to try changing the frequency. This is currently done for
      the legacy governors with help of min_sampling_rate.
      
      At worst, we may end up setting the sampling rate to a value lower than
      the rate at which frequency can be changed and then one of the CPUs in
      the policy will be only changing frequency for ever.
      
      But that is something for the user to decide and there is no need to
      have special handling for such cases in the core. Leave it for the user
      to figure out.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2d045036
  28. 18 Jul, 2017 1 commit
    • Tom Lendacky's avatar
      x86/cpu/AMD: Document AMD Secure Memory Encryption (SME) · c262f3b9
      Tom Lendacky authored
      
      
      Create a Documentation entry to describe the AMD Secure Memory
      Encryption (SME) feature and add documentation for the mem_encrypt=
      kernel parameter.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brijesh Singh <brijesh.singh@amd.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Larry Woodman <lwoodman@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Toshimitsu Kani <toshi.kani@hpe.com>
      Cc: kasan-dev@googlegroups.com
      Cc: kvm@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: linux-doc@vger.kernel.org
      Cc: linux-efi@vger.kernel.org
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/ca0a0c13b055fd804cfc92cbaca8acd68057eed0.1500319216.git.thomas.lendacky@amd.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      c262f3b9
  29. 17 Jul, 2017 1 commit
    • Logan Gunthorpe's avatar
      char_dev: extend dynamic allocation of majors into a higher range · a5d31a3f
      Logan Gunthorpe authored
      
      
      We've run into problems with running out of dynamicly assign char
      device majors particullarly on automated test systems with
      all-yes-configs. Roughly 40 dynamic assignments can be made with such
      kernels at this time while space is reserved for only 20.
      
      Currently, the kernel only prints a warning when dynamic allocation
      overflows the reserved region. And when this happens drivers that have
      fixed assignments can randomly fail depending on the order of
      initialization of other drivers. Thus, adding a new char device can cause
      unexpected failures in completely unrelated parts of the kernel.
      
      This patch solves the problem by extending dynamic major number
      allocations down from 511 once the 234-254 region fills up. Fixed
      majors already exist above 255 so the infrastructure to support
      high number majors is already in place. The patch reserves an
      additional 128 major numbers which should hopefully last us a while.
      
      Kernels that don't require more than 20 dynamic majors assigned (which
      is pretty typical) should not be affected by this change.
      Signed-off-by: default avatarLogan Gunthorpe <logang@deltatee.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Link: https://lkml.org/lkml/2017/6/4/107
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5d31a3f
  30. 06 Jul, 2017 2 commits
    • Michal Hocko's avatar
      mm, memory_hotplug: drop CONFIG_MOVABLE_NODE · f70029bb
      Michal Hocko authored
      Commit 20b2f52b ("numa: add CONFIG_MOVABLE_NODE for
      movable-dedicated node") has introduced CONFIG_MOVABLE_NODE without a
      good explanation on why it is actually useful.
      
      It makes a lot of sense to make movable node semantic opt in but we
      already have that because the feature has to be explicitly enabled on
      the kernel command line.  A config option on top only makes the
      configuration space larger without a good reason.  It also adds an
      additional ifdefery that pollutes the code.
      
      Just drop the config option and make it de-facto always enabled.  This
      shouldn't introduce any change to the semantic.
      
      Link: http://lkml.kernel.org/r/20170529114141.536-3-mhocko@kernel.org
      
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarReza Arbab <arbab@linux.vnet.ibm.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: Yasuaki Ishimatsu <yasu.isimatu@gmail.com>
      Cc: Xishi Qiu <qiuxishi@huawei.com>
      Cc: Kani Toshimitsu <toshi.kani@hpe.com>
      Cc: Chen Yucong <slaoub@gmail.com>
      Cc: Joonsoo Kim <js1304@gmail.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Daniel Kiper <daniel.kiper@oracle.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f70029bb
    • Kees Cook's avatar
      mm: allow slab_nomerge to be set at build time · 7660a6fd
      Kees Cook authored
      Some hardened environments want to build kernels with slab_nomerge
      already set (so that they do not depend on remembering to set the kernel
      command line option).  This is desired to reduce the risk of kernel heap
      overflows being able to overwrite objects from merged caches and changes
      the requirements for cache layout control, increasing the difficulty of
      these attacks.  By keeping caches unmerged, these kinds of exploits can
      usually only damage objects in the same cache (though the risk to
      metadata exploitation is unchanged).
      
      Link: http://lkml.kernel.org/r/20170620230911.GA25238@beast
      
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Daniel Micay <danielmicay@gmail.com>
      Cc: David Windsor <dave@nullcore.net>
      Cc: Eric Biggers <ebiggers3@gmail.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Daniel Micay <danielmicay@gmail.com>
      Cc: David Windsor <dave@nullcore.net>
      Cc: Eric Biggers <ebiggers3@gmail.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Daniel Mack <daniel@zonque.org>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7660a6fd
  31. 05 Jul, 2017 1 commit
  32. 29 Jun, 2017 2 commits
  33. 23 Jun, 2017 1 commit
  34. 22 Jun, 2017 1 commit