21 Mar, 2018

22 commits

  • commit 76600428c3677659e3c3633bb4f2ea302220a275 upstream.

    On my GICv3 system, the following is printed to the kernel log at boot:

    kvm [1]: 8-bit VMID
    kvm [1]: IDMAP page: d20e35000
    kvm [1]: HYP VA range: 800000000000:ffffffffffff
    kvm [1]: vgic-v2@2c020000
    kvm [1]: GIC system register CPU interface enabled
    kvm [1]: vgic interrupt IRQ1
    kvm [1]: virtual timer IRQ4
    kvm [1]: Hyp mode initialized successfully

    The KVM IDMAP is a mapping of a statically allocated kernel structure,
    and so printing its physical address leaks the physical placement of
    the kernel when physical KASLR in effect. So change the kvm_info() to
    kvm_debug() to remove it from the log output.

    While at it, trim the output a bit more: IRQ numbers can be found in
    /proc/interrupts, and the HYP VA and vgic-v2 lines are not highly
    informational either.

    Cc:
    Acked-by: Will Deacon
    Acked-by: Christoffer Dall
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Marc Zyngier
    Signed-off-by: Greg Kroah-Hartman

    Ard Biesheuvel
     
  • commit 95dd77580ccd66a0da96e6d4696945b8cea39431 upstream.

    On nfsv2 and nfsv3 the nfs server can export subsets of the same
    filesystem and report the same filesystem identifier, so that the nfs
    client can know they are the same filesystem. The subsets can be from
    disjoint directory trees. The nfsv2 and nfsv3 filesystems provides no
    way to find the common root of all directory trees exported form the
    server with the same filesystem identifier.

    The practical result is that in struct super s_root for nfs s_root is
    not necessarily the root of the filesystem. The nfs mount code sets
    s_root to the root of the first subset of the nfs filesystem that the
    kernel mounts.

    This effects the dcache invalidation code in generic_shutdown_super
    currently called shrunk_dcache_for_umount and that code for years
    has gone through an additional list of dentries that might be dentry
    trees that need to be freed to accomodate nfs.

    When I wrote path_connected I did not realize nfs was so special, and
    it's hueristic for avoiding calling is_subdir can fail.

    The practical case where this fails is when there is a move of a
    directory from the subtree exposed by one nfs mount to the subtree
    exposed by another nfs mount. This move can happen either locally or
    remotely. With the remote case requiring that the move directory be cached
    before the move and that after the move someone walks the path
    to where the move directory now exists and in so doing causes the
    already cached directory to be moved in the dcache through the magic
    of d_splice_alias.

    If someone whose working directory is in the move directory or a
    subdirectory and now starts calling .. from the initial mount of nfs
    (where s_root == mnt_root), then path_connected as a heuristic will
    not bother with the is_subdir check. As s_root really is not the root
    of the nfs filesystem this heuristic is wrong, and the path may
    actually not be connected and path_connected can fail.

    The is_subdir function might be cheap enough that we can call it
    unconditionally. Verifying that will take some benchmarking and
    the result may not be the same on all kernels this fix needs
    to be backported to. So I am avoiding that for now.

    Filesystems with snapshots such as nilfs and btrfs do something
    similar. But as the directory tree of the snapshots are disjoint
    from one another and from the main directory tree rename won't move
    things between them and this problem will not occur.

    Cc: stable@vger.kernel.org
    Reported-by: Al Viro
    Fixes: 397d425dc26d ("vfs: Test for and handle paths that are unreachable from their mnt_root")
    Signed-off-by: "Eric W. Biederman"
    Signed-off-by: Al Viro
    Signed-off-by: Greg Kroah-Hartman

    Eric W. Biederman
     
  • commit 7d617264eb22b18d979eac6e85877a141253034e upstream.

    Turning off the sink in this case causes various issues, because
    userspace expects it to stay on until it turns it off explicitly.

    Instead, turn the sink off and back on when a display is connected
    again. This dance seems necessary for link training to work correctly.

    Bugzilla: https://bugs.freedesktop.org/105308
    Cc: stable@vger.kernel.org
    Reviewed-by: Alex Deucher
    Signed-off-by: Michel Dänzer
    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Michel Dänzer
     
  • commit 0f4f715bc6bed3bf14c5cd7d5fe88d443e756b14 upstream.

    We unmapped imported DMA-bufs when the GEM handle was dropped, not when the
    hardware was done with the buffere.

    Signed-off-by: Christian König
    Reviewed-by: Michel Dänzer
    CC: stable@vger.kernel.org
    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Christian König
     
  • commit 342038d92403b3efa1138a8599666b9f026279d6 upstream.

    We unmapped imported DMA-bufs when the GEM handle was dropped, not when the
    hardware was done with the buffere.

    Signed-off-by: Christian König
    Reviewed-by: Michel Dänzer
    CC: stable@vger.kernel.org
    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Christian König
     
  • commit 76f2e2bc627f7d08360ac731b6277d744d4eb599 upstream.

    Unbinding nouveau on a dual GPU MacBook Pro oopses because we iterate
    over the bl_connectors list in nouveau_backlight_exit() but skipped
    initializing it in nouveau_backlight_init(). Stacktrace for posterity:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
    IP: nouveau_backlight_exit+0x2b/0x70 [nouveau]
    nouveau_display_destroy+0x29/0x80 [nouveau]
    nouveau_drm_unload+0x65/0xe0 [nouveau]
    drm_dev_unregister+0x3c/0xe0 [drm]
    drm_put_dev+0x2e/0x60 [drm]
    nouveau_drm_device_remove+0x47/0x70 [nouveau]
    pci_device_remove+0x36/0xb0
    device_release_driver_internal+0x157/0x220
    driver_detach+0x39/0x70
    bus_remove_driver+0x51/0xd0
    pci_unregister_driver+0x2a/0xa0
    nouveau_drm_exit+0x15/0xfb0 [nouveau]
    SyS_delete_module+0x18c/0x290
    system_call_fast_compare_end+0xc/0x6f

    Fixes: b53ac1ee12a3 ("drm/nouveau/bl: Do not register interface if Apple GMUX detected")
    Cc: stable@vger.kernel.org # v4.10+
    Cc: Pierre Moreau
    Signed-off-by: Lukas Wunner
    Signed-off-by: Ben Skeggs
    Signed-off-by: Greg Kroah-Hartman

    Lukas Wunner
     
  • commit a2ff19f7b70118ced291a28d5313469914de451b upstream.

    When releasing a client, we need to clear the clienttab[] entry at
    first, then call snd_seq_queue_client_leave(). Otherwise, the
    in-flight cell in the queue might be picked up by the timer interrupt
    via snd_seq_check_queue() before calling snd_seq_queue_client_leave(),
    and it's delivered to another queue while the client is clearing
    queues. This may eventually result in an uncleared cell remaining in
    a queue, and the later snd_seq_pool_delete() may need to wait for a
    long time until the event gets really processed.

    By moving the clienttab[] clearance at the beginning of release, any
    event delivery of a cell belonging to this client will fail at a later
    point, since snd_seq_client_ptr() returns NULL. Thus the cell that
    was picked up by the timer interrupt will be returned immediately
    without further delivery, and the long stall of snd_seq_delete_pool()
    can be avoided, too.

    Cc:
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit d0f833065221cbfcbadf19fd4102bcfa9330006a upstream.

    Although we've covered the races between concurrent write() and
    ioctl() in the previous patch series, there is still a possible UAF in
    the following scenario:

    A: user client closed B: timer irq
    -> snd_seq_release() -> snd_seq_timer_interrupt()
    -> snd_seq_free_client() -> snd_seq_check_queue()
    -> cell = snd_seq_prioq_cell_peek()
    -> snd_seq_prioq_leave()
    .... removing all cells
    -> snd_seq_pool_done()
    .... vfree()
    -> snd_seq_compare_tick_time(cell)
    ... Oops

    So the problem is that a cell is peeked and accessed without any
    protection until it's retrieved from the queue again via
    snd_seq_prioq_cell_out().

    This patch tries to address it, also cleans up the code by a slight
    refactoring. snd_seq_prioq_cell_out() now receives an extra pointer
    argument. When it's non-NULL, the function checks the event timestamp
    with the given pointer. The caller needs to pass the right reference
    either to snd_seq_tick or snd_seq_realtime depending on the event
    timestamp type.

    A good news is that the above change allows us to remove the
    snd_seq_prioq_cell_peek(), too, thus the patch actually reduces the
    code size.

    Reviewed-by: Nicolai Stange
    Cc:
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 40088dc4e1ead7df31728c73f5b51d71da18831d upstream.

    With the commit 1ba8f9d30817 ("ALSA: hda: Add a power_save
    blacklist"), we changed the default value of power_save option to -1
    for processing the power-save blacklist.
    Unfortunately, this seems breaking user-space applications that
    actually read the power_save parameter value via sysfs and judge /
    adjust the power-saving status. They see the value -1 as if the
    power-save is turned off, although the actual value is taken from
    CONFIG_SND_HDA_POWER_SAVE_DEFAULT and it can be a positive.

    So, overall, passing -1 there was no good idea. Let's partially
    revert it -- at least for power_save option default value is restored
    again to CONFIG_SND_HDA_POWER_SAVE_DEFAULT. Meanwhile, in this patch,
    we keep the blacklist behavior and make is adjustable via the new
    option, pm_blacklist.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073
    Fixes: 1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist")
    Acked-by: Hans de Goede
    Cc:
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 01c0b4265cc16bc1f43f475c5944c55c10d5768f upstream.

    snd_pcm_oss_get_formats() has an obvious use-after-free around
    snd_mask_test() calls, as spotted by syzbot. The passed format_mask
    argument is a pointer to the hw_params object that is freed before the
    loop. What a surprise that it has been present since the original
    code of decades ago...

    Reported-by: syzbot+4090700a4f13fccaf648@syzkaller.appspotmail.com
    Cc:
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 9ef0f88fe5466c2ca1d2975549ba6be502c464c1 upstream.

    Just when I had decided that flush_cache_range() was always called with
    a valid context, Helge reported two cases where the
    "BUG_ON(!vma->vm_mm->context);" was hit on the phantom buildd:

    kernel BUG at /mnt/sdb6/linux/linux-4.15.4/arch/parisc/kernel/cache.c:587!
    CPU: 1 PID: 3254 Comm: kworker/1:2 Tainted: G D 4.15.0-1-parisc64-smp #1 Debian 4.15.4-1+b1
    Workqueue: events free_ioctx
      IAOQ[0]: flush_cache_range+0x164/0x168
      IAOQ[1]: flush_cache_page+0x0/0x1c8
      RP(r2): unmap_page_range+0xae8/0xb88
    Backtrace:
      [] unmap_page_range+0xae8/0xb88
      [] unmap_single_vma+0xc0/0x188
      [] zap_page_range_single+0x134/0x1f8
      [] unmap_mapping_range+0x1cc/0x208
      [] truncate_pagecache+0x98/0x108
      [] truncate_setsize+0x9c/0xb8
      [] put_aio_ring_file+0x80/0x100
      [] aio_free_ring+0x8c/0x290
      [] free_ioctx+0x80/0x180
      [] process_one_work+0x21c/0x668
      [] worker_thread+0x20c/0x778
      [] kthread+0x2d4/0x2e0
      [] end_fault_vector+0x20/0xc0

    This indicates that we need to handle the no context case in
    flush_cache_range() as we do in flush_cache_mm().

    In thinking about this, I realized that we don't need to flush the TLB
    when there is no context. So, I added context checks to the large flush
    cases in flush_cache_mm() and flush_cache_range(). The large flush case
    occurs frequently in flush_cache_mm() and the change should improve fork
    performance.

    The v2 version of this change removes the BUG_ON from flush_cache_page()
    by skipping the TLB flush when there is no context.  I also added code
    to flush the TLB in flush_cache_mm() and flush_cache_range() when we
    have a context that's not current.  Now all three routines handle TLB
    flushes in a similar manner.

    Signed-off-by: John David Anglin
    Cc: stable@vger.kernel.org # 4.9+
    Signed-off-by: Helge Deller
    Signed-off-by: Greg Kroah-Hartman

    John David Anglin
     
  • commit 18a955219bf7d9008ce480d4451b6b8bf4483a22 upstream.

    Gratian Crisan reported that vmalloc_fault() crashes when CONFIG_HUGETLBFS
    is not set since the function inadvertently uses pXn_huge(), which always
    return 0 in this case. ioremap() does not depend on CONFIG_HUGETLBFS.

    Fix vmalloc_fault() to call pXd_large() instead.

    Fixes: f4eafd8bcd52 ("x86/mm: Fix vmalloc_fault() to handle large pages properly")
    Reported-by: Gratian Crisan
    Signed-off-by: Toshi Kani
    Signed-off-by: Thomas Gleixner
    Cc: stable@vger.kernel.org
    Cc: linux-mm@kvack.org
    Cc: Borislav Petkov
    Cc: Andy Lutomirski
    Link: https://lkml.kernel.org/r/20180313170347.3829-2-toshi.kani@hpe.com
    Signed-off-by: Greg Kroah-Hartman

    Toshi Kani
     
  • commit daaf216c06fba4ee4dc3f62715667da929d68774 upstream.

    When using device passthrough with SME active, the MMIO range that is
    mapped for the device should not be mapped encrypted. Add a check in
    set_spte() to insure that a page is not mapped encrypted if that page
    is a device MMIO page as indicated by kvm_is_mmio_pfn().

    Cc: # 4.14.x-
    Signed-off-by: Tom Lendacky
    Signed-off-by: Paolo Bonzini
    Signed-off-by: Greg Kroah-Hartman

    Tom Lendacky
     
  • commit e3b3121fa8da94cb20f9e0c64ab7981ae47fd085 upstream.

    In accordance with Intel's microcode revision guidance from March 6 MCU
    rev 0xc2 is cleared on both Skylake H/S and Skylake Xeon E3 processors
    that share CPUID 506E3.

    Signed-off-by: Alexander Sergeyev
    Signed-off-by: Thomas Gleixner
    Cc: Jia Zhang
    Cc: Greg Kroah-Hartman
    Cc: Kyle Huey
    Cc: David Woodhouse
    Link: https://lkml.kernel.org/r/20180313193856.GA8580@localhost.localdomain
    Signed-off-by: Greg Kroah-Hartman

    Alexander Sergeyev
     
  • commit a14bff131108faf50cc0cf864589fd71ee216c96 upstream.

    In the following commit:

    9e0e3c5130e9 ("x86/speculation, objtool: Annotate indirect calls/jumps for objtool")

    ... we added annotations for CALL_NOSPEC/JMP_NOSPEC on 64-bit x86 kernels,
    but we did not annotate the 32-bit path.

    Annotate it similarly.

    Signed-off-by: Andy Whitcroft
    Acked-by: Peter Zijlstra (Intel)
    Cc: Andy Lutomirski
    Cc: Arjan van de Ven
    Cc: Borislav Petkov
    Cc: Dan Williams
    Cc: Dave Hansen
    Cc: David Woodhouse
    Cc: David Woodhouse
    Cc: Greg Kroah-Hartman
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/20180314112427.22351-1-apw@canonical.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Andy Whitcroft
     
  • commit b5069782453459f6ec1fdeb495d9901a4545fcb5 upstream.

    POPF would trap if VIP was set regardless of whether IF was set. Fix it.

    Suggested-by: Stas Sergeev
    Reported-by: Bart Oldeman
    Signed-off-by: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: stable@vger.kernel.org
    Fixes: 5ed92a8ab71f ("x86/vm86: Use the normal pt_regs area for vm86")
    Link: http://lkml.kernel.org/r/ce95f40556e7b2178b6bc06ee9557827ff94bd28.1521003603.git.luto@kernel.org
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Andy Lutomirski
     
  • commit 78393fdde2a456cafa414b171c90f26a3df98b20 upstream.

    POPF is currently broken -- add tests to catch the error. This
    results in:

    [RUN] POPF with VIP set and IF clear from vm86 mode
    [INFO] Exited vm86 mode due to STI
    [FAIL] Incorrect return reason (started at eip = 0xd, ended at eip = 0xf)

    because POPF currently fails to check IF before reporting a pending
    interrupt.

    This patch also makes the FAIL message a bit more informative.

    Reported-by: Bart Oldeman
    Signed-off-by: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Stas Sergeev
    Cc: Thomas Gleixner
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/a16270b5cfe7832d6d00c479d0f871066cbdb52b.1521003603.git.luto@kernel.org
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Andy Lutomirski
     
  • commit a9e017d5619eb371460c8e516f4684def62bef3a upstream.

    The STR and SLDT instructions are not valid when running on virtual-8086
    mode and generate an invalid operand exception. These two instructions are
    protected by the Intel User-Mode Instruction Prevention (UMIP) security
    feature. In protected mode, if UMIP is enabled, these instructions generate
    a general protection fault if called from CPL > 0. Linux traps the general
    protection fault and emulates the instructions sgdt, sidt and smsw; but not
    str and sldt.

    These tests are added to verify that the emulation code does not emulate
    these two instructions but the expected invalid operand exception is
    seen.

    Tests fallback to exit with INT3 in case emulation does happen.

    Signed-off-by: Ricardo Neri
    Reviewed-by: Thomas Gleixner
    Cc: Andrew Morton
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Chen Yucong
    Cc: Chris Metcalf
    Cc: Dave Hansen
    Cc: Denys Vlasenko
    Cc: Fenghua Yu
    Cc: H. Peter Anvin
    Cc: Huang Rui
    Cc: Jiri Slaby
    Cc: Jonathan Corbet
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Masami Hiramatsu
    Cc: Michael S. Tsirkin
    Cc: Paolo Bonzini
    Cc: Paul Gortmaker
    Cc: Peter Zijlstra
    Cc: Ravi V. Shankar
    Cc: Shuah Khan
    Cc: Tony Luck
    Cc: Vlastimil Babka
    Cc: ricardo.neri@intel.com
    Link: http://lkml.kernel.org/r/1509935277-22138-13-git-send-email-ricardo.neri-calderon@linux.intel.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Ricardo Neri
     
  • commit 9390afebe1d3f5a0be18b1afdd0ce09d67cebf9e upstream.

    Certain user space programs that run on virtual-8086 mode may utilize
    instructions protected by the User-Mode Instruction Prevention (UMIP)
    security feature present in new Intel processors: SGDT, SIDT and SMSW. In
    such a case, a general protection fault is issued if UMIP is enabled. When
    such a fault happens, the kernel traps it and emulates the results of
    these instructions with dummy values. The purpose of this new
    test is to verify whether the impacted instructions can be executed
    without causing such #GP. If no #GP exceptions occur, we expect to exit
    virtual-8086 mode from INT3.

    The instructions protected by UMIP are executed in representative use
    cases:

    a) displacement-only memory addressing
    b) register-indirect memory addressing
    c) results stored directly in operands

    Unfortunately, it is not possible to check the results against a set of
    expected values because no emulation will occur in systems that do not
    have the UMIP feature. Instead, results are printed for verification. A
    simple verification is done to ensure that results of all tests are
    identical.

    Signed-off-by: Ricardo Neri
    Reviewed-by: Thomas Gleixner
    Cc: Andrew Morton
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Chen Yucong
    Cc: Chris Metcalf
    Cc: Dave Hansen
    Cc: Denys Vlasenko
    Cc: Fenghua Yu
    Cc: H. Peter Anvin
    Cc: Huang Rui
    Cc: Jiri Slaby
    Cc: Jonathan Corbet
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Masami Hiramatsu
    Cc: Michael S. Tsirkin
    Cc: Paolo Bonzini
    Cc: Paul Gortmaker
    Cc: Peter Zijlstra
    Cc: Ravi V. Shankar
    Cc: Shuah Khan
    Cc: Tony Luck
    Cc: Vlastimil Babka
    Cc: ricardo.neri@intel.com
    Link: http://lkml.kernel.org/r/1509935277-22138-12-git-send-email-ricardo.neri-calderon@linux.intel.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Ricardo Neri
     
  • commit 327d53d005ca47b10eae940616ed11c569f75a9b upstream.

    Fix a logic error that caused the test to exit with 0 even if test
    cases failed.

    Signed-off-by: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Stas Sergeev
    Cc: Thomas Gleixner
    Cc: bartoldeman@gmail.com
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/b1cc37144038958a469c8f70a5f47a6a5638636a.1521003603.git.luto@kernel.org
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Andy Lutomirski
     
  • commit 7958b2246fadf54b7ff820a2a5a2c5ca1554716f upstream.

    CPUID.0x7.0x0:EDX[18] indicates whether Intel CPU support PCONFIG instruction.

    Signed-off-by: Kirill A. Shutemov
    Cc: Dave Hansen
    Cc: Kai Huang
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: Tom Lendacky
    Cc: linux-mm@kvack.org
    Link: http://lkml.kernel.org/r/20180305162610.37510-4-kirill.shutemov@linux.intel.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Kirill A. Shutemov
     
  • commit 1da961d72ab0cfbe8b7c26cba731dc2bb6b9494b upstream.

    CPUID.0x7.0x0:ECX[13] indicates whether CPU supports Intel Total Memory
    Encryption.

    Signed-off-by: Kirill A. Shutemov
    Cc: Dave Hansen
    Cc: Kai Huang
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: Tom Lendacky
    Cc: linux-mm@kvack.org
    Link: http://lkml.kernel.org/r/20180305162610.37510-2-kirill.shutemov@linux.intel.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Kirill A. Shutemov
     

19 Mar, 2018

18 commits

  • Greg Kroah-Hartman
     
  • commit 2afba81c7909ac259720c0d3e7616cf54d4a5368 upstream.

    Since the firmwares are not yet released to public repo,
    disable them on Geminilake.

    v2: Remove the firmware versions (Michal)

    v3: Remove unwanted defines (Rodrigo)
    Correct commit message (Michal)

    Cc: Michal Wajdeczko
    Cc: Rodrigo Vivi
    Cc:
    Signed-off-by: Anusha Srivatsa
    Fixes: 90f192c8241e ("drm/i915/GuC/GLK: Load GuC on GLK")
    Fixes: db5ba0d8931e ("drm/i915/GLK/HuC: Load HuC on GLK")
    Reviewed-by: Michal Wajdeczko
    Signed-off-by: Rodrigo Vivi
    Link: https://patchwork.freedesktop.org/patch/msgid/1515006225-13003-1-git-send-email-anusha.srivatsa@intel.com
    (cherry picked from commit a76050a4837860fcadb6ca11d69d41e08f4090d8)
    Signed-off-by: Rodrigo Vivi
    Signed-off-by: Greg Kroah-Hartman

    Anusha Srivatsa
     
  • [ Upstream commit 38680bc6b1e3592bc9e18adc1d6e259667df27ce ]

    Driver is missing the interrupts if two requests are queued up at the same
    time as the interrupt handler is servicing a request that was just
    delivered.

    The ISR clears the interrupt at the end but it could be clearing the
    interrupt for an outstanding event. Therefore, second interrupt never
    arrives.

    Clear the interrupt first and then check for completions.

    Also, make sure that request start and interrupt clear do not overlap in
    time by using a spinlock.

    Signed-off-by: Sinan Kaya
    Signed-off-by: Vinod Koul
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sinan Kaya
     
  • [ Upstream commit 1b19b95169cd52fe82cd442fec0b279fe25cc838 ]

    A warning that I thought I had fixed before occasionally comes
    back in rare randconfig builds (I found 7 instances in the last
    100000 builds, originally it was much more frequent):

    drivers/infiniband/hw/mlx5/mr.c: In function 'mlx5_ib_reg_user_mr':
    drivers/infiniband/hw/mlx5/mr.c:1229:5: error: 'order' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    if (order
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann
     
  • [ Upstream commit b7e27bc1d42e8e0cc58b602b529c25cd0071b336 ]

    Custom policies can require file signatures based on LSM labels. These
    files are normally created and only afterwards labeled, requiring them
    to be signed.

    Instead of requiring file signatures based on LSM labels, entire
    filesystems could require file signatures. In this case, we need the
    ability of writing new files without requiring file signatures.

    The definition of a "new" file was originally defined as any file with
    a length of zero. Subsequent patches redefined a "new" file to be based
    on the FILE_CREATE open flag. By combining the open flag with a file
    size of zero, this patch relaxes the file signature requirement.

    Fixes: 1ac202e978e1 ima: accept previously set IMA_NEW_FILE
    Signed-off-by: Mimi Zohar
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Mimi Zohar
     
  • [ Upstream commit 2ce77d16db4240dd2e422fc0a5c26d3e2ec03446 ]

    Things can explode for locktorture if the user does combinations
    of nwriters_stress=0 nreaders_stress=0. Fix this by not assuming
    we always want to torture writer threads.

    Reported-by: Jeremy Linton
    Signed-off-by: Davidlohr Bueso
    Signed-off-by: Paul E. McKenney
    Reviewed-by: Jeremy Linton
    Tested-by: Jeremy Linton
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Davidlohr Bueso
     
  • [ Upstream commit 2adfa4210f8f35cdfb4e08318cc06b99752964c2 ]

    The 'configinit.sh' script checks the format of optional argument for the
    build directory, printing an error message if the format is not valid.
    However, the error message uses the wrong variable, indicating an empty
    string even though the user entered a non-empty (but erroneous) string.
    This commit fixes the script to use the correct variable.

    Fixes: c87b9c601ac8 ("rcutorture: Add KVM-based test framework")

    Signed-off-by: SeongJae Park
    Signed-off-by: Paul E. McKenney
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    SeongJae Park
     
  • [ Upstream commit 92ff42645028fa6f9b8aa767718457b9264316b4 ]

    Packets that don't have dest mac as the mac of the master device should
    not be entertained by the IPvlan rx-handler. This is mostly true as the
    packet path mostly takes care of that, except when the master device is
    a virtual device. As demonstrated in the following case -

    ip netns add ns1
    ip link add ve1 type veth peer name ve2
    ip link add link ve2 name iv1 type ipvlan mode l2
    ip link set dev iv1 netns ns1
    ip link set ve1 up
    ip link set ve2 up
    ip -n ns1 link set iv1 up
    ip addr add 192.168.10.1/24 dev ve1
    ip -n ns1 addr 192.168.10.2/24 dev iv1
    ping -c2 192.168.10.2

    ip neigh show dev ve1
    ip neigh show 192.168.10.2 lladdr dev ve1
    ping -c2 192.168.10.2

    This patch adds that missing check in the IPvlan rx-handler.

    Reported-by: Amit Sikka
    Signed-off-by: Mahesh Bandewar
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Mahesh Bandewar
     
  • [ Upstream commit a0e94598e6b6c0d1df6a5fa14eb7c767ca817a20 ]

    Destination is a kernel pointer and source - a userland one
    in _copy_from_user(); _copy_to_user() is the other way round.

    Fixes: d597580d37377 ("generic ...copy_..._user primitives")
    Signed-off-by: Christophe Leroy
    Signed-off-by: Al Viro
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Christophe Leroy
     
  • [ Upstream commit 23a185254ace8e63dc4ca36e0315aed9440ae749 ]

    mmc_test disables the command queue because none of the tests use the
    command queue. However the Reset Test will re-enable it, so disable it in
    that case too.

    Fixes: 9d4579a85c84 ("mmc: mmc_test: Disable Command Queue while mmc_test is used")
    Signed-off-by: Adrian Hunter
    Signed-off-by: Ulf Hansson
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Adrian Hunter
     
  • [ Upstream commit 65a12b3aafed5fc59f4ce41b22b752b1729e6701 ]

    We should be finishing the loop with timeout set to zero but because
    this is a post-op we finish with timeout == -1.

    Fixes: 1082e2703a2d ("ASoC: NUC900/audio: add nuc900 audio driver support")
    Signed-off-by: Dan Carpenter
    Signed-off-by: Mark Brown
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Dan Carpenter
     
  • [ Upstream commit 9db09e3bad65393dc23b0279beb7f3754d77065c ]

    Fix below warnings on ARMv7 by using %zu for printing size_t values:

    drivers/crypto/caam/caamalg_qi.c: In function aead_edesc_alloc:
    drivers/crypto/caam/caamalg_qi.c:417:17: warning: format %lu expects argument of type long unsigned int, but argument 4 has type unsigned int [-Wformat=]
    sizeof(struct qm_sg_entry))
    ^
    drivers/crypto/caam/caamalg_qi.c:672:16: note: in expansion of macro CAAM_QI_MAX_AEAD_SG
    qm_sg_ents, CAAM_QI_MAX_AEAD_SG);
    ^
    drivers/crypto/caam/caamalg_qi.c: In function ablkcipher_edesc_alloc:
    drivers/crypto/caam/caamalg_qi.c:440:17: warning: format %lu expects argument of type long unsigned int, but argument 4 has type unsigned int [-Wformat=]
    sizeof(struct qm_sg_entry))
    ^
    drivers/crypto/caam/caamalg_qi.c:909:16: note: in expansion of macro CAAM_QI_MAX_ABLKCIPHER_SG
    qm_sg_ents, CAAM_QI_MAX_ABLKCIPHER_SG);
    ^
    drivers/crypto/caam/caamalg_qi.c: In function ablkcipher_giv_edesc_alloc:
    drivers/crypto/caam/caamalg_qi.c:440:17: warning: format %lu expects argument of type long unsigned int, but argument 4 has type unsigned int [-Wformat=]
    sizeof(struct qm_sg_entry))
    ^
    drivers/crypto/caam/caamalg_qi.c:1062:16: note: in expansion of macro CAAM_QI_MAX_ABLKCIPHER_SG
    qm_sg_ents, CAAM_QI_MAX_ABLKCIPHER_SG);
    ^

    Fixes: eb9ba37dc15a ("crypto: caam/qi - handle large number of S/Gs case")
    Signed-off-by: Horia Geantă
    Signed-off-by: Herbert Xu
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Horia Geantă
     
  • [ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]

    In the ieee80211_setup_sdata() we check if the interface type is valid
    and, if not, call BUG(). This should never happen, but if there is
    something wrong with the code, it will not be caught until the bug
    happens when an interface is being set up. Calling BUG() is too
    extreme for this and a WARN_ON() would be better used instead. Change
    that.

    Signed-off-by: Luca Coelho
    Signed-off-by: Johannes Berg
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Luca Coelho
     
  • [ Upstream commit e16ea4bb516bc21ea2202f2107718b29218bea59 ]

    Enforce using PS_MANUAL_POLL in ps hwsim debugfs to trigger a poll,
    only if PS_ENABLED was set before.
    This is required due to commit c9491367b759 ("mac80211: always update the
    PM state of a peer on MGMT / DATA frames") that enforces the ap to
    check only mgmt/data frames ps bit, and then update station's power save
    accordingly.
    When sending only ps-poll (control frame) the ap will not be aware that
    the station entered power save.
    Setting ps enable before triggering ps_poll, will send NDP with PM bit
    enabled first.

    Signed-off-by: Adiel Aloni
    Signed-off-by: Luca Coelho
    Signed-off-by: Johannes Berg
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Adiel Aloni
     
  • [ Upstream commit 8516673a996870ea0ceb337ee4f83c33c5ec3111 ]

    Before accessing the GGTT we must flush the PTE writes and make them
    visible to the chipset, or else the indirect access may end up in the
    wrong page. In commit 3497971a71d8 ("agp/intel: Flush chipset writes
    after updating a single PTE"), we noticed corruption of the uploads for
    pwrite and for capturing GPU error states, but it was presumed that the
    explicit calls to intel_gtt_chipset_flush() were sufficient for the
    execbuffer path. However, we have not been flushing the chipset between
    the PTE writes and access via the GTT itself.

    For simplicity, do the flush after any PTE update rather than try and
    batch the flushes on a just-in-time basis.

    References: 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE")
    Signed-off-by: Chris Wilson
    Cc: Tvrtko Ursulin
    Cc: Mika Kuoppala
    Cc: drm-intel-fixes@lists.freedesktop.org
    Reviewed-by: Joonas Lahtinen
    Link: https://patchwork.freedesktop.org/patch/msgid/20171208214616.30147-1-chris@chris-wilson.co.uk
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Chris Wilson
     
  • [ Upstream commit f5bbcd533a9d1af97b8a0862a421bb8455f1bf6d ]

    Describe the GPIO used to reset the Ethernet PHY for EthernetAVB.
    This allows the driver to reset the PHY during probe and after system
    resume.

    This fixes Ethernet operation after resume from s2ram on Salvator-XS,
    where the enable pin of the regulator providing PHY power is connected
    to PRESETn, and PSCI powers down the SoC during system suspend.

    On Salvator-X, the enable pin is always pulled high, but the driver may
    still need to reset the PHY if this wasn't done by the bootloader
    before.

    Inspired by patches in the BSP for the individual Salvator-X/XS boards
    by Kazuya Mizuguchi.

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Simon Horman
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Geert Uytterhoeven
     
  • [ Upstream commit acb1feab320e38588fccc568e3767761f494976f ]

    When an interrupt is returning to a soft-disabled context (which can
    happen for non-maskable interrupts or synchronous interrupts), it goes
    through the motions of soft-disabling again, including calling
    TRACE_DISABLE_INTS (i.e., trace_hardirqs_off()).

    This is not necessary, because we must already be soft-disabled in the
    interrupt context, it also may be causing crashes in the irq tracing
    code to re-enter as an nmi. Replace it with a warning to ensure that
    soft-interrupts are still disabled.

    Fixes: 7c0482e3d055 ("powerpc/irq: Fix another case of lazy IRQ state getting out of sync")
    Signed-off-by: Nicholas Piggin
    Signed-off-by: Michael Ellerman
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Nicholas Piggin
     
  • [ Upstream commit b9eab08d012fa093947b230f9a87257c27fb829b ]

    When attempting to load a livepatch module, I got the following error:

    module_64: patch_module: Expect noop after relocate, got 3c820000

    The error was triggered by the following code in
    unregister_netdevice_queue():

    14c: 00 00 00 48 b 14c
    14c: R_PPC64_REL24 net_set_todo
    150: 00 00 82 3c addis r4,r2,0

    GCC didn't insert a nop after the branch to net_set_todo() because it's
    a sibling call, so it never returns. The nop isn't needed after the
    branch in that case.

    Signed-off-by: Josh Poimboeuf
    Acked-by: Naveen N. Rao
    Reviewed-and-tested-by: Kamalesh Babulal
    Signed-off-by: Michael Ellerman
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf