1. 06 Feb, 2017 1 commit
    • Rafael J. Wysocki's avatar
      Merge branches 'pm-core-fixes' and 'pm-cpufreq-fixes' · cbf304e4
      Rafael J. Wysocki authored
      * pm-core-fixes:
        PM / runtime: Avoid false-positive warnings from might_sleep_if()
      
      * pm-cpufreq-fixes:
        cpufreq: intel_pstate: Disable energy efficiency optimization
        cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend
        cpufreq: brcmstb-avs-cpufreq: extend sysfs entry brcm_avs_pmap
      cbf304e4
  2. 05 Feb, 2017 1 commit
  3. 04 Feb, 2017 6 commits
  4. 03 Feb, 2017 29 commits
    • Rafael J. Wysocki's avatar
      PM / runtime: Avoid false-positive warnings from might_sleep_if() · a9306a63
      Rafael J. Wysocki authored
      The might_sleep_if() assertions in __pm_runtime_idle(),
      __pm_runtime_suspend() and __pm_runtime_resume() may generate
      false-positive warnings in some situations.  For example, that
      happens if a nested pm_runtime_get_sync()/pm_runtime_put() pair
      is executed with disabled interrupts within an outer
      pm_runtime_get_sync()/pm_runtime_put() section for the same device.
      [Generally, pm_runtime_get_sync() may sleep, so it should not be
      called with disabled interrupts, but in this particular case the
      previous pm_runtime_get_sync() guarantees that the device will not
      be suspended, so the inner pm_runtime_get_sync() will return
      immediately after incrementing the device's usage counter.]
      
      That started to happen in the i915 driver in 4.10-rc, leading to
      the following splat:
      
       BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1032
       in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
       1 lock held by Xorg/1500:
        #0:  (&dev->struct_mutex){+.+.+.}, at:
        [<ffffffffa0680c13>] i915_mutex_lock_interruptible+0x43/0x140 [i915]
       CPU: 0 PID: 1500 Comm: Xorg Not tainted
       Call Trace:
        dump_stack+0x85/0xc2
        ___might_sleep+0x196/0x260
        __might_sleep+0x53/0xb0
        __pm_runtime_resume+0x7a/0x90
        intel_runtime_pm_get+0x25/0x90 [i915]
        aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
        i915_vma_bind+0xaf/0x1e0 [i915]
        i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
        i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
        ? trace_hardirqs_on+0xd/0x10
        ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
        ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
        i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
        ? __might_fault+0x4e/0xb0
        i915_gem_execbuffer2+0xc5/0x260 [i915]
        ? __might_fault+0x4e/0xb0
        drm_ioctl+0x206/0x450 [drm]
        ? i915_gem_execbuffer+0x340/0x340 [i915]
        ? __fget+0x5/0x200
        do_vfs_ioctl+0x91/0x6f0
        ? __fget+0x111/0x200
        ? __fget+0x5/0x200
        SyS_ioctl+0x79/0x90
        entry_SYSCALL_64_fastpath+0x23/0xc6
      
      even though the code triggering it is correct.
      
      Unfortunately, the might_sleep_if() assertions in question are
      too coarse-grained to cover such cases correctly, so make them
      a bit less sensitive in order to avoid the false-positives.
      Reported-and-tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a9306a63
    • Linus Torvalds's avatar
      Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost · a49e6f58
      Linus Torvalds authored
      Pull virtio/vhost fixes from Michael S. Tsirkin:
       "Last minute fixes:
      
         - ARM DMA fix revert
      
         - vhost endian-ness fix
      
         - MAINTAINERS: email address change for Amit"
      
      * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
        MAINTAINERS: update email address for Amit Shah
        vhost: fix initialization for vq->is_le
        Revert "vring: Force use of DMA API for ARM-based systems with legacy devices"
      a49e6f58
    • Linus Torvalds's avatar
      Merge tag 'vfio-v4.10-rc7' of git://github.com/awilliam/linux-vfio · e9f7f17d
      Linus Torvalds authored
      Pull VFIO fix from Alex Williamson:
       "Fix an error path in SPAPR IOMMU backend (Alexey Kardashevskiy)"
      
      * tag 'vfio-v4.10-rc7' of git://github.com/awilliam/linux-vfio:
        vfio/spapr: Fix missing mutex unlock when creating a window
      e9f7f17d
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Disable energy efficiency optimization · 6e978b22
      Srinivas Pandruvada authored
      Some Kabylake desktop processors may not reach max turbo when running in
      HWP mode, even if running under sustained 100% utilization.
      
      This occurs when the HWP.EPP (Energy Performance Preference) is set to
      "balance_power" (0x80) -- the default on most systems.
      
      It occurs because the platform BIOS may erroneously enable an
      energy-efficiency setting -- MSR_IA32_POWER_CTL BIT-EE, which is not
      recommended to be enabled on this SKU.
      
      On the failing systems, this BIOS issue was not discovered when the
      desktop motherboard was tested with Windows, because the BIOS also
      neglects to provide the ACPI/CPPC table, that Windows requires to enable
      HWP, and so Windows runs in legacy P-state mode, where this setting has
      no effect.
      
      Linux' intel_pstate driver does not require ACPI/CPPC to enable HWP, and
      so it runs in HWP mode, exposing this incorrect BIOS configuration.
      
      There are several ways to address this problem.
      
      First, Linux can also run in legacy P-state mode on this system.
      As intel_pstate is how Linux enables HWP, booting with
      "intel_pstate=disable"
      will run in acpi-cpufreq/ondemand legacy p-state mode.
      
      Or second, the "performance" governor can be used with intel_pstate,
      which will modify HWP.EPP to 0.
      
      Or third, starting in 4.10, the
      /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference
      attribute in can be updated from "balance_power" to "performance".
      
      Or fourth, apply this patch, which fixes the erroneous setting of
      MSR_IA32_POWER_CTL BIT_EE on this model, allowing the default
      configuration to function as designed.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Reviewed-by: default avatarLen Brown <len.brown@intel.com>
      Cc: 4.6+ <stable@vger.kernel.org> # 4.6+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6e978b22
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · 7a92cc6b
      Linus Torvalds authored
      Merge fixes from Andrew Morton:
       "8 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        mm, fs: check for fatal signals in do_generic_file_read()
        fs: break out of iomap_file_buffered_write on fatal signals
        base/memory, hotplug: fix a kernel oops in show_valid_zones()
        mm/memory_hotplug.c: check start_pfn in test_pages_in_a_zone()
        jump label: pass kbuild_cflags when checking for asm goto support
        shmem: fix sleeping from atomic context
        kasan: respect /proc/sys/kernel/traceoff_on_warning
        zswap: disable changing params if init fails
      7a92cc6b
    • Michal Hocko's avatar
      mm, fs: check for fatal signals in do_generic_file_read() · 5abf186a
      Michal Hocko authored
      do_generic_file_read() can be told to perform a large request from
      userspace.  If the system is under OOM and the reading task is the OOM
      victim then it has an access to memory reserves and finishing the full
      request can lead to the full memory depletion which is dangerous.  Make
      sure we rather go with a short read and allow the killed task to
      terminate.
      
      Link: http://lkml.kernel.org/r/20170201092706.9966-3-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5abf186a
    • Michal Hocko's avatar
      fs: break out of iomap_file_buffered_write on fatal signals · d1908f52
      Michal Hocko authored
      Tetsuo has noticed that an OOM stress test which performs large write
      requests can cause the full memory reserves depletion.  He has tracked
      this down to the following path
      
      	__alloc_pages_nodemask+0x436/0x4d0
      	alloc_pages_current+0x97/0x1b0
      	__page_cache_alloc+0x15d/0x1a0          mm/filemap.c:728
      	pagecache_get_page+0x5a/0x2b0           mm/filemap.c:1331
      	grab_cache_page_write_begin+0x23/0x40   mm/filemap.c:2773
      	iomap_write_begin+0x50/0xd0             fs/iomap.c:118
      	iomap_write_actor+0xb5/0x1a0            fs/iomap.c:190
      	? iomap_write_end+0x80/0x80             fs/iomap.c:150
      	iomap_apply+0xb3/0x130                  fs/iomap.c:79
      	iomap_file_buffered_write+0x68/0xa0     fs/iomap.c:243
      	? iomap_write_end+0x80/0x80
      	xfs_file_buffered_aio_write+0x132/0x390 [xfs]
      	? remove_wait_queue+0x59/0x60
      	xfs_file_write_iter+0x90/0x130 [xfs]
      	__vfs_write+0xe5/0x140
      	vfs_write+0xc7/0x1f0
      	? syscall_trace_enter+0x1d0/0x380
      	SyS_write+0x58/0xc0
      	do_syscall_64+0x6c/0x200
      	entry_SYSCALL64_slow_path+0x25/0x25
      
      the oom victim has access to all memory reserves to make a forward
      progress to exit easier.  But iomap_file_buffered_write and other
      callers of iomap_apply loop to complete the full request.  We need to
      check for fatal signals and back off with a short write instead.
      
      As the iomap_apply delegates all the work down to the actor we have to
      hook into those.  All callers that work with the page cache are calling
      iomap_write_begin so we will check for signals there.  dax_iomap_actor
      has to handle the situation explicitly because it copies data to the
      userspace directly.  Other callers like iomap_page_mkwrite work on a
      single page or iomap_fiemap_actor do not allocate memory based on the
      given len.
      
      Fixes: 68a9f5e7 ("xfs: implement iomap based buffered write path")
      Link: http://lkml.kernel.org/r/20170201092706.9966-2-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reported-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <stable@vger.kernel.org>	[4.8+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d1908f52
    • Toshi Kani's avatar
      base/memory, hotplug: fix a kernel oops in show_valid_zones() · a96dfddb
      Toshi Kani authored
      Reading a sysfs "memoryN/valid_zones" file leads to the following oops
      when the first page of a range is not backed by struct page.
      show_valid_zones() assumes that 'start_pfn' is always valid for
      page_zone().
      
       BUG: unable to handle kernel paging request at ffffea017a000000
       IP: show_valid_zones+0x6f/0x160
      
      This issue may happen on x86-64 systems with 64GiB or more memory since
      their memory block size is bumped up to 2GiB.  [1] An example of such
      systems is desribed below.  0x3240000000 is only aligned by 1GiB and
      this memory block starts from 0x3200000000, which is not backed by
      struct page.
      
       BIOS-e820: [mem 0x0000003240000000-0x000000603fffffff] usable
      
      Since test_pages_in_a_zone() already checks holes, fix this issue by
      extending this function to return 'valid_start' and 'valid_end' for a
      given range.  show_valid_zones() then proceeds with the valid range.
      
      [1] 'Commit bdee237c ("x86: mm: Use 2GB memory block size on
          large-memory x86-64 systems")'
      
      Link: http://lkml.kernel.org/r/20170127222149.30893-3-toshi.kani@hpe.comSigned-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Zhang Zhen <zhenzhang.zhang@huawei.com>
      Cc: Reza Arbab <arbab@linux.vnet.ibm.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: <stable@vger.kernel.org>	[4.4+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a96dfddb
    • Toshi Kani's avatar
      mm/memory_hotplug.c: check start_pfn in test_pages_in_a_zone() · deb88a2a
      Toshi Kani authored
      Patch series "fix a kernel oops when reading sysfs valid_zones", v2.
      
      A sysfs memory file is created for each 2GiB memory block on x86-64 when
      the system has 64GiB or more memory.  [1] When the start address of a
      memory block is not backed by struct page, i.e.  a memory range is not
      aligned by 2GiB, reading its 'valid_zones' attribute file leads to a
      kernel oops.  This issue was observed on multiple x86-64 systems with
      more than 64GiB of memory.  This patch-set fixes this issue.
      
      Patch 1 first fixes an issue in test_pages_in_a_zone(), which does not
      test the start section.
      
      Patch 2 then fixes the kernel oops by extending test_pages_in_a_zone()
      to return valid [start, end).
      
      Note for stable kernels: The memory block size change was made by commit
      bdee237c ("x86: mm: Use 2GB memory block size on large-memory x86-64
      systems"), which was accepted to 3.9.  However, this patch-set depends
      on (and fixes) the change to test_pages_in_a_zone() made by commit
      5f0f2887 ("mm/memory_hotplug.c: check for missing sections in
      test_pages_in_a_zone()"), which was accepted to 4.4.
      
      So, I recommend that we backport it up to 4.4.
      
      [1] 'Commit bdee237c ("x86: mm: Use 2GB memory block size on
          large-memory x86-64 systems")'
      
      This patch (of 2):
      
      test_pages_in_a_zone() does not check 'start_pfn' when it is aligned by
      section since 'sec_end_pfn' is set equal to 'pfn'.  Since this function
      is called for testing the range of a sysfs memory file, 'start_pfn' is
      always aligned by section.
      
      Fix it by properly setting 'sec_end_pfn' to the next section pfn.
      
      Also make sure that this function returns 1 only when the range belongs
      to a zone.
      
      Link: http://lkml.kernel.org/r/20170127222149.30893-2-toshi.kani@hpe.comSigned-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Cc: Andrew Banman <abanman@sgi.com>
      Cc: Reza Arbab <arbab@linux.vnet.ibm.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: <stable@vger.kernel.org>	[4.4+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      deb88a2a
    • David Lin's avatar
      jump label: pass kbuild_cflags when checking for asm goto support · 35f860f9
      David Lin authored
      Some versions of ARM GCC compiler such as Android toolchain throws in a
      '-fpic' flag by default.  This causes the gcc-goto check script to fail
      although some config would have '-fno-pic' flag in the KBUILD_CFLAGS.
      
      This patch passes the KBUILD_CFLAGS to the check script so that the
      script does not rely on the default config from different compilers.
      
      Link: http://lkml.kernel.org/r/20170120234329.78868-1-dtwlin@google.comSigned-off-by: default avatarDavid Lin <dtwlin@google.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Michal Marek <mmarek@suse.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      35f860f9
    • Kirill A. Shutemov's avatar
      shmem: fix sleeping from atomic context · 253fd0f0
      Kirill A. Shutemov authored
      Syzkaller fuzzer managed to trigger this:
      
          BUG: sleeping function called from invalid context at mm/shmem.c:852
          in_atomic(): 1, irqs_disabled(): 0, pid: 529, name: khugepaged
          3 locks held by khugepaged/529:
           #0:  (shrinker_rwsem){++++..}, at: [<ffffffff818d7ef1>] shrink_slab.part.59+0x121/0xd30 mm/vmscan.c:451
           #1:  (&type->s_umount_key#29){++++..}, at: [<ffffffff81a63630>] trylock_super+0x20/0x100 fs/super.c:392
           #2:  (&(&sbinfo->shrinklist_lock)->rlock){+.+.-.}, at: [<ffffffff818fd83e>] spin_lock include/linux/spinlock.h:302 [inline]
           #2:  (&(&sbinfo->shrinklist_lock)->rlock){+.+.-.}, at: [<ffffffff818fd83e>] shmem_unused_huge_shrink+0x28e/0x1490 mm/shmem.c:427
          CPU: 2 PID: 529 Comm: khugepaged Not tainted 4.10.0-rc5+ #201
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
          Call Trace:
             shmem_undo_range+0xb20/0x2710 mm/shmem.c:852
             shmem_truncate_range+0x27/0xa0 mm/shmem.c:939
             shmem_evict_inode+0x35f/0xca0 mm/shmem.c:1030
             evict+0x46e/0x980 fs/inode.c:553
             iput_final fs/inode.c:1515 [inline]
             iput+0x589/0xb20 fs/inode.c:1542
             shmem_unused_huge_shrink+0xbad/0x1490 mm/shmem.c:446
             shmem_unused_huge_scan+0x10c/0x170 mm/shmem.c:512
             super_cache_scan+0x376/0x450 fs/super.c:106
             do_shrink_slab mm/vmscan.c:378 [inline]
             shrink_slab.part.59+0x543/0xd30 mm/vmscan.c:481
             shrink_slab mm/vmscan.c:2592 [inline]
             shrink_node+0x2c7/0x870 mm/vmscan.c:2592
             shrink_zones mm/vmscan.c:2734 [inline]
             do_try_to_free_pages+0x369/0xc80 mm/vmscan.c:2776
             try_to_free_pages+0x3c6/0x900 mm/vmscan.c:2982
             __perform_reclaim mm/page_alloc.c:3301 [inline]
             __alloc_pages_direct_reclaim mm/page_alloc.c:3322 [inline]
             __alloc_pages_slowpath+0xa24/0x1c30 mm/page_alloc.c:3683
             __alloc_pages_nodemask+0x544/0xae0 mm/page_alloc.c:3848
             __alloc_pages include/linux/gfp.h:426 [inline]
             __alloc_pages_node include/linux/gfp.h:439 [inline]
             khugepaged_alloc_page+0xc2/0x1b0 mm/khugepaged.c:750
             collapse_huge_page+0x182/0x1fe0 mm/khugepaged.c:955
             khugepaged_scan_pmd+0xfdf/0x12a0 mm/khugepaged.c:1208
             khugepaged_scan_mm_slot mm/khugepaged.c:1727 [inline]
             khugepaged_do_scan mm/khugepaged.c:1808 [inline]
             khugepaged+0xe9b/0x1590 mm/khugepaged.c:1853
             kthread+0x326/0x3f0 kernel/kthread.c:227
             ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
      
      The iput() from atomic context was a bad idea: if after igrab() somebody
      else calls iput() and we left with the last inode reference, our iput()
      would lead to inode eviction and therefore sleeping.
      
      This patch should fix the situation.
      
      Link: http://lkml.kernel.org/r/20170131093141.GA15899@node.shutemov.nameSigned-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      253fd0f0
    • Peter Zijlstra's avatar
      kasan: respect /proc/sys/kernel/traceoff_on_warning · 4f40c6e5
      Peter Zijlstra authored
      After much waiting I finally reproduced a KASAN issue, only to find my
      trace-buffer empty of useful information because it got spooled out :/
      
      Make kasan_report honour the /proc/sys/kernel/traceoff_on_warning
      interface.
      
      Link: http://lkml.kernel.org/r/20170125164106.3514-1-aryabinin@virtuozzo.comSigned-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Acked-by: default avatarAlexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4f40c6e5
    • Dan Streetman's avatar
      zswap: disable changing params if init fails · d7b028f5
      Dan Streetman authored
      Add zswap_init_failed bool that prevents changing any of the module
      params, if init_zswap() fails, and set zswap_enabled to false.  Change
      'enabled' param to a callback, and check zswap_init_failed before
      allowing any change to 'enabled', 'zpool', or 'compressor' params.
      
      Any driver that is built-in to the kernel will not be unloaded if its
      init function returns error, and its module params remain accessible for
      users to change via sysfs.  Since zswap uses param callbacks, which
      assume that zswap has been initialized, changing the zswap params after
      a failed initialization will result in WARNING due to the param
      callbacks expecting a pool to already exist.  This prevents that by
      immediately exiting any of the param callbacks if initialization failed.
      
      This was reported here:
        https://marc.info/?l=linux-mm&m=147004228125528&w=4
      
      And fixes this WARNING:
        [  429.723476] WARNING: CPU: 0 PID: 5140 at mm/zswap.c:503 __zswap_pool_current+0x56/0x60
      
      The warning is just noise, and not serious.  However, when init fails,
      zswap frees all its percpu dstmem pages and its kmem cache.  The kmem
      cache might be serious, if kmem_cache_alloc(NULL, gfp) has problems; but
      the percpu dstmem pages are definitely a problem, as they're used as
      temporary buffer for compressed pages before copying into place in the
      zpool.
      
      If the user does get zswap enabled after an init failure, then zswap
      will likely Oops on the first page it tries to compress (or worse, start
      corrupting memory).
      
      Fixes: 90b0fc26 ("zswap: change zpool/compressor at runtime")
      Link: http://lkml.kernel.org/r/20170124200259.16191-2-ddstreet@ieee.orgSigned-off-by: default avatarDan Streetman <dan.streetman@canonical.com>
      Reported-by: default avatarMarcin Miroslaw <marcin@mejor.pl>
      Cc: Seth Jennings <sjenning@redhat.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d7b028f5
    • Linus Torvalds's avatar
      Merge tag 'regulator-fix-v4.10-rc6' of... · 3f67790d
      Linus Torvalds authored
      Merge tag 'regulator-fix-v4.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
      
      Pull regulator fixes from Mark Brown:
       "Three changes here: two run of the mill driver specific fixes and a
        change from Mark Rutland which reverts some new device specific ACPI
        binding code which was added during the merge window as there are
        concerns about this sending the wrong signal about usage of regulators
        in ACPI systems"
      
      * tag 'regulator-fix-v4.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
        regulator: fixed: Revert support for ACPI interface
        regulator: axp20x: AXP806: Fix dcdcb being set instead of dcdce
        regulator: twl6030: fix range comparison, allowing vsel = 59
      3f67790d
    • Amit Shah's avatar
      MAINTAINERS: update email address for Amit Shah · 79134d11
      Amit Shah authored
      I'm leaving my job at Red Hat, this email address will stop working next week.
      Update it to one that I will have access to later.
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      79134d11
    • Halil Pasic's avatar
      vhost: fix initialization for vq->is_le · cda8bba0
      Halil Pasic authored
      Currently, under certain circumstances vhost_init_is_le does just a part
      of the initialization job, and depends on vhost_reset_is_le being called
      too. For this reason vhost_vq_init_access used to call vhost_reset_is_le
      when vq->private_data is NULL. This is not only counter intuitive, but
      also real a problem because it breaks vhost_net. The bug was introduced to
      vhost_net with commit 2751c988 ("vhost: cross-endian support for
      legacy devices"). The symptom is corruption of the vq's used.idx field
      (virtio) after VHOST_NET_SET_BACKEND was issued as a part of the vhost
      shutdown on a vq with pending descriptors.
      
      Let us make sure the outcome of vhost_init_is_le never depend on the state
      it is actually supposed to initialize, and fix virtio_net by removing the
      reset from vhost_vq_init_access.
      
      With the above, there is no reason for vhost_reset_is_le to do just half
      of the job. Let us make vhost_reset_is_le reinitialize is_le.
      Signed-off-by: default avatarHalil Pasic <pasic@linux.vnet.ibm.com>
      Reported-by: default avatarMichael A. Tebolt <miket@us.ibm.com>
      Reported-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
      Fixes: commit 2751c988 ("vhost: cross-endian support for legacy devices")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarGreg Kurz <groug@kaod.org>
      Tested-by: default avatarMichael A. Tebolt <miket@us.ibm.com>
      cda8bba0
    • Michael S. Tsirkin's avatar
      Revert "vring: Force use of DMA API for ARM-based systems with legacy devices" · 0d5415b4
      Michael S. Tsirkin authored
      This reverts commit c7070619.
      
      This has been shown to regress on some ARM systems:
      
      by forcing on DMA API usage for ARM systems, we have inadvertently
      kicked open a hornets' nest in terms of cache-coherency. Namely that
      unless the virtio device is explicitly described as capable of coherent
      DMA by firmware, the DMA APIs on ARM and other DT-based platforms will
      assume it is non-coherent. This turns out to cause a big problem for the
      likes of QEMU and kvmtool, which generate virtio-mmio devices in their
      guest DTs but neglect to add the often-overlooked "dma-coherent"
      property; as a result, we end up with the guest making non-cacheable
      accesses to the vring, the host doing so cacheably, both talking past
      each other and things going horribly wrong.
      
      We are working on a safer work-around.
      
      Fixes: c7070619 ("vring: Force use of DMA API for ARM-based systems with legacy devices")
      Reported-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      0d5415b4
    • Greg Kroah-Hartman's avatar
      Merge tag 'usb-serial-4.10-rc7' of... · 42441494
      Greg Kroah-Hartman authored
      Merge tag 'usb-serial-4.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
      
      Johan writes:
      
      USB-serial fixes for v4.10-rc7
      
      One more device ID for pl2303.
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      42441494
    • Linus Torvalds's avatar
      Merge tag 'mmc-v4.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc · cd44691f
      Linus Torvalds authored
      Pull MMC fix from Ulf Hansson:
       "MMC host: sdhci: Avoid hang when receiving spurious CARD_INT
        interrupts"
      
      * tag 'mmc-v4.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
        mmc: sdhci: Ignore unexpected CARD_INT interrupts
      cd44691f
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-for-v4.10-rc7' of git://people.freedesktop.org/~airlied/linux · 79c9089f
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Another fixes pull for v4.10, it's a bit big due to the backport of
        the VMA fixes for i915 that should fix the oops on shutdown problems
        that you've worked around.
      
        There are also two drm core connector registration fixes, a bunch of
        nouveau regression fixes and two AMD fixes"
      
      * tag 'drm-fixes-for-v4.10-rc7' of git://people.freedesktop.org/~airlied/linux:
        drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl
        drm/amdgpu/si: fix crash on headless asics
        drm/i915: Track pinned vma in intel_plane_state
        drm/atomic: Unconditionally call prepare_fb.
        drm/atomic: Fix double free in drm_atomic_state_default_clear
        drm/nouveau/kms/nv50: request vblank events for commits that send completion events
        drm/nouveau/nv1a,nv1f/disp: fix memory clock rate retrieval
        drm/nouveau/disp/gt215: Fix HDA ELD handling (thus, HDMI audio) on gt215
        drm/nouveau/nouveau/led: prevent compiling the led-code if nouveau=y and leds=m
        drm/nouveau/disp/mcp7x: disable dptmds workaround
        drm/nouveau: prevent userspace from deleting client object
        drm/nouveau/fence/g84-: protect against concurrent access to semaphore buffers
        drm: Don't race connector registration
        drm: prevent double-(un)registration for connectors
      79c9089f
    • Linus Torvalds's avatar
      Merge tag 'powerpc-4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux · 57480b98
      Linus Torvalds authored
      Pull powerpc fixes from Michael Ellerman:
       "The main change is we're reverting the initial stack protector support
        we merged this cycle. It turns out to not work on toolchains built
        with libc support, and fixing it will be need to wait for another
        release.
      
        And the rest are all fairly minor:
      
         - Some pasemi machines were not booting due to a missing error check
           in prom_find_boot_cpu()
      
         - In EEH we were checking a pointer rather than the bool it pointed
           to
      
         - The clang build was broken by a BUILD_BUG_ON() we added.
      
         - The radix (Power9 only) version of map_kernel_page() was broken if
           our memory size was a multiple of 2MB, which it generally isn't
      
        Thanks to: Darren Stevens, Gavin Shan, Reza Arbab"
      
      * tag 'powerpc-4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
        powerpc/mm: Use the correct pointer when setting a 2MB pte
        powerpc: Fix build failure with clang due to BUILD_BUG_ON()
        powerpc: Revert the initial stack protector support
        powerpc/eeh: Fix wrong flag passed to eeh_unfreeze_pe()
        powerpc: Add missing error check to prom_find_boot_cpu()
      57480b98
    • Linus Torvalds's avatar
      Merge tag 'trace-v4.10-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 2d47b8aa
      Linus Torvalds authored
      Pull tracing fix from Steven Rostedt:
       "Simple fix of s/static struct __init/static __init struct/"
      
      * tag 'trace-v4.10-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing/kprobes: Fix __init annotation
      2d47b8aa
    • Linus Torvalds's avatar
      Merge branch 'modversions' (modversions fixes for powerpc from Ard) · 2cb54ce9
      Linus Torvalds authored
      Merge kcrctab entry fixes from Ard Biesheuvel:
       "This is a followup to [0] 'modversions: redefine kcrctab entries as
        relative CRC pointers', but since relative CRC pointers do not work in
        modules, and are actually only needed by powerpc with
        CONFIG_RELOCATABLE=y, I have made it a Kconfig selectable feature
        instead.
      
        First it introduces the MODULE_REL_CRCS Kconfig symbol, and adds the
        kbuild handling of it, i.e., modpost, genksyms and kallsyms.
      
        Then it switches all architectures to 32-bit CRC entries in kcrctab,
        where all architectures except powerpc with CONFIG_RELOCATABLE=y use
        absolute ELF symbol references as before"
      
      [0] http://marc.info/?l=linux-arch&m=148493613415294&w=2
      
      * emailed patches from Ard Biesheuvel:
        module: unify absolute krctab definitions for 32-bit and 64-bit
        modversions: treat symbol CRCs as 32 bit quantities
        kbuild: modversions: add infrastructure for emitting relative CRCs
      2cb54ce9
    • Ard Biesheuvel's avatar
      log2: make order_base_2() behave correctly on const input value zero · 29905b52
      Ard Biesheuvel authored
      The function order_base_2() is defined (according to the comment block)
      as returning zero on input zero, but subsequently passes the input into
      roundup_pow_of_two(), which is explicitly undefined for input zero.
      
      This has gone unnoticed until now, but optimization passes in GCC 7 may
      produce constant folded function instances where a constant value of
      zero is passed into order_base_2(), resulting in link errors against the
      deliberately undefined '____ilog2_NaN'.
      
      So update order_base_2() to adhere to its own documented interface.
      
      [ See
      
           http://marc.info/?l=linux-kernel&m=147672952517795&w=2
      
        and follow-up discussion for more background. The gcc "optimization
        pass" is really just broken, but now the GCC trunk problem seems to
        have escaped out of just specially built daily images, so we need to
        work around it in mainline.    - Linus ]
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      29905b52
    • Radim Krčmář's avatar
      KVM: x86: do not save guest-unsupported XSAVE state · 00c87e9a
      Radim Krčmář authored
      Saving unsupported state prevents migration when the new host does not
      support a XSAVE feature of the original host, even if the feature is not
      exposed to the guest.
      
      We've masked host features with guest-visible features before, with
      4344ee98 ("KVM: x86: only copy XSAVE state for the supported
      features") and dropped it when implementing XSAVES.  Do it again.
      
      Fixes: df1daba7 ("KVM: x86: support XSAVES usage in the host")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      00c87e9a
    • Ard Biesheuvel's avatar
      module: unify absolute krctab definitions for 32-bit and 64-bit · 4b9eee96
      Ard Biesheuvel authored
      The previous patch introduced a separate inline asm version of the
      krcrctab declaration template for use with 64-bit architectures, which
      cannot refer to ELF symbols using 32-bit quantities.
      
      This declaration should be equivalent to the C one for 32-bit
      architectures, but just in case - unify them in a separate patch, which
      can simply be dropped if it turns out to break anything.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4b9eee96
    • Ard Biesheuvel's avatar
      modversions: treat symbol CRCs as 32 bit quantities · 71810db2
      Ard Biesheuvel authored
      The modversion symbol CRCs are emitted as ELF symbols, which allows us
      to easily populate the kcrctab sections by relying on the linker to
      associate each kcrctab slot with the correct value.
      
      This has a couple of downsides:
      
       - Given that the CRCs are treated as memory addresses, we waste 4 bytes
         for each CRC on 64 bit architectures,
      
       - On architectures that support runtime relocation, a R_<arch>_RELATIVE
         relocation entry is emitted for each CRC value, which identifies it
         as a quantity that requires fixing up based on the actual runtime
         load offset of the kernel. This results in corrupted CRCs unless we
         explicitly undo the fixup (and this is currently being handled in the
         core module code)
      
       - Such runtime relocation entries take up 24 bytes of __init space
         each, resulting in a x8 overhead in [uncompressed] kernel size for
         CRCs.
      
      Switching to explicit 32 bit values on 64 bit architectures fixes most
      of these issues, given that 32 bit values are not treated as quantities
      that require fixing up based on the actual runtime load offset.  Note
      that on some ELF64 architectures [such as PPC64], these 32-bit values
      are still emitted as [absolute] runtime relocatable quantities, even if
      the value resolves to a build time constant.  Since relative relocations
      are always resolved at build time, this patch enables MODULE_REL_CRCS on
      powerpc when CONFIG_RELOCATABLE=y, which turns the absolute CRC
      references into relative references into .rodata where the actual CRC
      value is stored.
      
      So redefine all CRC fields and variables as u32, and redefine the
      __CRC_SYMBOL() macro for 64 bit builds to emit the CRC reference using
      inline assembler (which is necessary since 64-bit C code cannot use
      32-bit types to hold memory addresses, even if they are ultimately
      resolved using values that do not exceed 0xffffffff).  To avoid
      potential problems with legacy 32-bit architectures using legacy
      toolchains, the equivalent C definition of the kcrctab entry is retained
      for 32-bit architectures.
      
      Note that this mostly reverts commit d4703aef ("module: handle ppc64
      relocating kcrctabs when CONFIG_RELOCATABLE=y")
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      71810db2
    • Ard Biesheuvel's avatar
      kbuild: modversions: add infrastructure for emitting relative CRCs · 56067812
      Ard Biesheuvel authored
      This add the kbuild infrastructure that will allow architectures to emit
      vmlinux symbol CRCs as 32-bit offsets to another location in the kernel
      where the actual value is stored. This works around problems with CRCs
      being mistaken for relocatable symbols on kernels that self relocate at
      runtime (i.e., powerpc with CONFIG_RELOCATABLE=y)
      
      For the kbuild side of things, this comes down to the following:
      
       - introducing a Kconfig symbol MODULE_REL_CRCS
      
       - adding a -R switch to genksyms to instruct it to emit the CRC symbols
         as references into the .rodata section
      
       - making modpost distinguish such references from absolute CRC symbols
         by the section index (SHN_ABS)
      
       - making kallsyms disregard non-absolute symbols with a __crc_ prefix
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      56067812
    • Mark Brown's avatar
      Merge remote-tracking branches 'regulator/fix/fixed' and... · 206c4720
      Mark Brown authored
      Merge remote-tracking branches 'regulator/fix/fixed' and 'regulator/fix/twl6040' into regulator-linus
      206c4720
  5. 02 Feb, 2017 3 commits