commit 4b3a3ab00fa7a951eb1d7568c71855e75fd5af85
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 3 06:26:31 2019 +0200

    Linux 4.19.33

commit 11008a9b0fc7883e180484dcb9165062a746f558
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Thu Sep 20 14:23:45 2018 +0300

    platform: x86: intel_cht_int33fe: Remove the old connections for the muxes
    
    commit 148b0aa78e4e1077e38f928124bbc9c2d2d24006 upstream.
    
    USB Type-C class driver now expects the muxes to be always
    assigned to the ports and not controllers, so the
    connections for the mux and fusb302 can be removed.
    
    Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 056cda45cfed27432e40b0269888580060912791
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Thu Sep 20 14:23:44 2018 +0300

    usb: typec: class: Don't use port parent for getting mux handles
    
    commit 23481121c81d984193edf1532f5e123637e50903 upstream.
    
    It is not possible to use the parent of the port device when
    requesting mux handles as the parent may be a multiport USB
    Type-C or PD controller. The muxes must be assigned to the
    ports, not the controllers.
    
    This will also move the requesting of the muxes after the
    port device is initialized.
    
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6875404a12f8f33d52eaa49d1fe80072a88ccb8e
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Thu Sep 20 14:23:43 2018 +0300

    platform: x86: intel_cht_int33fe: Add connections for the USB Type-C port
    
    commit 495965a1002a0b301bf4fbfd1aed3233f3e7db1b upstream.
    
    Assigning the mux to the USB Type-C port on top of fusb302.
    That will prepare this driver for the change in the USB
    Type-C class code, where the class driver will assume the
    muxes to be always assigned to the ports and not the
    controllers.
    
    Once the USB Type-C class driver has been updated, the
    connections between the mux and fusb302 can be dropped.
    
    Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 681a9fc184b30062ff4e1677540cb6d512c2e455
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Thu Sep 20 14:23:42 2018 +0300

    platform: x86: intel_cht_int33fe: Add connection for the DP alt mode
    
    commit 78d2b54b134ea6059e2b1554ad53fab2300a4cc6 upstream.
    
    Adding a connection for the DisplayPort alternate mode.
    PI3USB30532 is used for muxing the port to DisplayPort on
    CHT platforms. The connection allows the alternate mode
    device to get handle to the mux, and therefore make it
    possible to use the USB Type-C connector as DisplayPort.
    
    Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bb446a3fe87e85623de08682367a5ac0e1d2c64
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Thu Sep 20 14:23:41 2018 +0300

    platform: x86: intel_cht_int33fe: Register all connections at once
    
    commit 140a4ec4adddda615b4e8e8055ca37a30c7fe5e8 upstream.
    
    We can register all device connection descriptors with a
    single call to device_connections_add().
    
    Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e99d90ce77500f7b9b706bf2b632cc631ca2e307
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Thu Sep 20 14:23:40 2018 +0300

    drivers: base: Helpers for adding device connection descriptions
    
    commit cd7753d371388e712e3ee52b693459f9b71aaac2 upstream.
    
    Introducing helpers for adding and removing multiple device
    connection descriptions at once.
    
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5959dec081a59d1019509fa21320def183f78c8
Author: Xu Yu <xuyu@linux.alibaba.com>
Date:   Thu Mar 21 18:00:35 2019 +0800

    bpf: do not restore dst_reg when cur_state is freed
    
    commit 0803278b0b4d8eeb2b461fb698785df65a725d9e upstream.
    
    Syzkaller hit 'KASAN: use-after-free Write in sanitize_ptr_alu' bug.
    
    Call trace:
    
      dump_stack+0xbf/0x12e
      print_address_description+0x6a/0x280
      kasan_report+0x237/0x360
      sanitize_ptr_alu+0x85a/0x8d0
      adjust_ptr_min_max_vals+0x8f2/0x1ca0
      adjust_reg_min_max_vals+0x8ed/0x22e0
      do_check+0x1ca6/0x5d00
      bpf_check+0x9ca/0x2570
      bpf_prog_load+0xc91/0x1030
      __se_sys_bpf+0x61e/0x1f00
      do_syscall_64+0xc8/0x550
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Fault injection trace:
    
      kfree+0xea/0x290
      free_func_state+0x4a/0x60
      free_verifier_state+0x61/0xe0
      push_stack+0x216/0x2f0                  <- inject failslab
      sanitize_ptr_alu+0x2b1/0x8d0
      adjust_ptr_min_max_vals+0x8f2/0x1ca0
      adjust_reg_min_max_vals+0x8ed/0x22e0
      do_check+0x1ca6/0x5d00
      bpf_check+0x9ca/0x2570
      bpf_prog_load+0xc91/0x1030
      __se_sys_bpf+0x61e/0x1f00
      do_syscall_64+0xc8/0x550
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    When kzalloc() fails in push_stack(), free_verifier_state() will free
    current verifier state. As push_stack() returns, dst_reg was restored
    if ptr_is_dst_reg is false. However, as member of the cur_state,
    dst_reg is also freed, and error occurs when dereferencing dst_reg.
    Simply fix it by testing ret of push_stack() before restoring dst_reg.
    
    Fixes: 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic")
    Signed-off-by: Xu Yu <xuyu@linux.alibaba.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 738dda85d18180a9e3a47ba9939ca00e9e95d318
Author: Gao Xiang <gaoxiang25@huawei.com>
Date:   Fri Mar 29 04:14:58 2019 +0800

    staging: erofs: keep corrupted fs from crashing kernel in erofs_readdir()
    
    commit 33bac912840fe64dbc15556302537dc6a17cac63 upstream.
    
    After commit 419d6efc50e9, kernel cannot be crashed in the namei
    path. However, corrupted nameoff can do harm in the process of
    readdir for scenerios without dm-verity as well. Fix it now.
    
    Fixes: 3aa8ec716e52 ("staging: erofs: add directory operations")
    Cc: <stable@vger.kernel.org> # 4.19+
    Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83bbd66b375341b71bcb8f096039923260c92d1a
Author: Gao Xiang <gaoxiang25@huawei.com>
Date:   Mon Mar 25 11:40:07 2019 +0800

    staging: erofs: fix error handling when failed to read compresssed data
    
    commit b6391ac73400eff38377a4a7364bd3df5efb5178 upstream.
    
    Complete read error handling paths for all three kinds of
    compressed pages:
    
     1) For cache-managed pages, PG_uptodate will be checked since
        read_endio will unlock and SetPageUptodate for these pages;
    
     2) For inplaced pages, read_endio cannot SetPageUptodate directly
        since it should be used to mark the final decompressed data,
        PG_error will be set with page locked for IO error instead;
    
     3) For staging pages, PG_error is used, which is similar to
        what we do for inplaced pages.
    
    Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
    Cc: <stable@vger.kernel.org> # 4.19+
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a18eabaa712312d4bb127bd798e3a95631318f0
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Thu Mar 7 15:43:02 2019 -0800

    KVM: x86: Emulate MSR_IA32_ARCH_CAPABILITIES on AMD hosts
    
    commit 0cf9135b773bf32fba9dd8e6699c1b331ee4b749 upstream.
    
    The CPUID flag ARCH_CAPABILITIES is unconditioinally exposed to host
    userspace for all x86 hosts, i.e. KVM advertises ARCH_CAPABILITIES
    regardless of hardware support under the pretense that KVM fully
    emulates MSR_IA32_ARCH_CAPABILITIES.  Unfortunately, only VMX hosts
    handle accesses to MSR_IA32_ARCH_CAPABILITIES (despite KVM_GET_MSRS
    also reporting MSR_IA32_ARCH_CAPABILITIES for all hosts).
    
    Move the MSR_IA32_ARCH_CAPABILITIES handling to common x86 code so
    that it's emulated on AMD hosts.
    
    Fixes: 1eaafe91a0df4 ("kvm: x86: IA32_ARCH_CAPABILITIES is always supported")
    Cc: stable@vger.kernel.org
    Reported-by: Xiaoyao Li <xiaoyao.li@linux.intel.com>
    Cc: Jim Mattson <jmattson@google.com>
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9733a74350d6ab2e1a36bface0e3b36866945de
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Mon Mar 11 20:01:05 2019 -0700

    KVM: x86: update %rip after emulating IO
    
    commit 45def77ebf79e2e8942b89ed79294d97ce914fa0 upstream.
    
    Most (all?) x86 platforms provide a port IO based reset mechanism, e.g.
    OUT 92h or CF9h.  Userspace may emulate said mechanism, i.e. reset a
    vCPU in response to KVM_EXIT_IO, without explicitly announcing to KVM
    that it is doing a reset, e.g. Qemu jams vCPU state and resumes running.
    
    To avoid corruping %rip after such a reset, commit 0967b7bf1c22 ("KVM:
    Skip pio instruction when it is emulated, not executed") changed the
    behavior of PIO handlers, i.e. today's "fast" PIO handling to skip the
    instruction prior to exiting to userspace.  Full emulation doesn't need
    such tricks becase re-emulating the instruction will naturally handle
    %rip being changed to point at the reset vector.
    
    Updating %rip prior to executing to userspace has several drawbacks:
    
      - Userspace sees the wrong %rip on the exit, e.g. if PIO emulation
        fails it will likely yell about the wrong address.
      - Single step exits to userspace for are effectively dropped as
        KVM_EXIT_DEBUG is overwritten with KVM_EXIT_IO.
      - Behavior of PIO emulation is different depending on whether it
        goes down the fast path or the slow path.
    
    Rather than skip the PIO instruction before exiting to userspace,
    snapshot the linear %rip and cancel PIO completion if the current
    value does not match the snapshot.  For a 64-bit vCPU, i.e. the most
    common scenario, the snapshot and comparison has negligible overhead
    as VMCS.GUEST_RIP will be cached regardless, i.e. there is no extra
    VMREAD in this case.
    
    All other alternatives to snapshotting the linear %rip that don't
    rely on an explicit reset announcenment suffer from one corner case
    or another.  For example, canceling PIO completion on any write to
    %rip fails if userspace does a save/restore of %rip, and attempting to
    avoid that issue by canceling PIO only if %rip changed then fails if PIO
    collides with the reset %rip.  Attempting to zero in on the exact reset
    vector won't work for APs, which means adding more hooks such as the
    vCPU's MP_STATE, and so on and so forth.
    
    Checking for a linear %rip match technically suffers from corner cases,
    e.g. userspace could theoretically rewrite the underlying code page and
    expect a different instruction to execute, or the guest hardcodes a PIO
    reset at 0xfffffff0, but those are far, far outside of what can be
    considered normal operation.
    
    Fixes: 432baf60eee3 ("KVM: VMX: use kvm_fast_pio_in for handling IN I/O")
    Cc: <stable@vger.kernel.org>
    Reported-by: Jim Mattson <jmattson@google.com>
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ceedcefc2d2506536f634f1887521be51d598c2
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Fri Feb 15 12:48:39 2019 -0800

    KVM: Reject device ioctls from processes other than the VM's creator
    
    commit ddba91801aeb5c160b660caed1800eb3aef403f8 upstream.
    
    KVM's API requires thats ioctls must be issued from the same process
    that created the VM.  In other words, userspace can play games with a
    VM's file descriptors, e.g. fork(), SCM_RIGHTS, etc..., but only the
    creator can do anything useful.  Explicitly reject device ioctls that
    are issued by a process other than the VM's creator, and update KVM's
    API documentation to extend its requirements to device ioctls.
    
    Fixes: 852b6d57dc7f ("kvm: add device control API")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0713e8103d127f4b5231a22b92c87b9dc0caa77
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Mar 26 17:36:06 2019 +0100

    x86/smp: Enforce CONFIG_HOTPLUG_CPU when SMP=y
    
    commit bebd024e4815b1a170fcd21ead9c2222b23ce9e6 upstream.
    
    The SMT disable 'nosmt' command line argument is not working properly when
    CONFIG_HOTPLUG_CPU is disabled. The teardown of the sibling CPUs which are
    required to be brought up due to the MCE issues, cannot work. The CPUs are
    then kept in a half dead state.
    
    As the 'nosmt' functionality has become popular due to the speculative
    hardware vulnerabilities, the half torn down state is not a proper solution
    to the problem.
    
    Enforce CONFIG_HOTPLUG_CPU=y when SMP is enabled so the full operation is
    possible.
    
    Reported-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Konrad Wilk <konrad.wilk@oracle.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Mukesh Ojha <mojha@codeaurora.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Micheal Kelley <michael.h.kelley@microsoft.com>
    Cc: "K. Y. Srinivasan" <kys@microsoft.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: K. Y. Srinivasan <kys@microsoft.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190326163811.598166056@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a56aa02e6f154ff83d8271244402a6392cde7b0f
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Mar 26 17:36:05 2019 +0100

    cpu/hotplug: Prevent crash when CPU bringup fails on CONFIG_HOTPLUG_CPU=n
    
    commit 206b92353c839c0b27a0b9bec24195f93fd6cf7a upstream.
    
    Tianyu reported a crash in a CPU hotplug teardown callback when booting a
    kernel which has CONFIG_HOTPLUG_CPU disabled with the 'nosmt' boot
    parameter.
    
    It turns out that the SMP=y CONFIG_HOTPLUG_CPU=n case has been broken
    forever in case that a bringup callback fails. Unfortunately this issue was
    not recognized when the CPU hotplug code was reworked, so the shortcoming
    just stayed in place.
    
    When a bringup callback fails, the CPU hotplug code rolls back the
    operation and takes the CPU offline.
    
    The 'nosmt' command line argument uses a bringup failure to abort the
    bringup of SMT sibling CPUs. This partial bringup is required due to the
    MCE misdesign on Intel CPUs.
    
    With CONFIG_HOTPLUG_CPU=y the rollback works perfectly fine, but
    CONFIG_HOTPLUG_CPU=n lacks essential mechanisms to exercise the low level
    teardown of a CPU including the synchronizations in various facilities like
    RCU, NOHZ and others.
    
    As a consequence the teardown callbacks which must be executed on the
    outgoing CPU within stop machine with interrupts disabled are executed on
    the control CPU in interrupt enabled and preemptible context causing the
    kernel to crash and burn. The pre state machine code has a different
    failure mode which is more subtle and resulting in a less obvious use after
    free crash because the control side frees resources which are still in use
    by the undead CPU.
    
    But this is not a x86 only problem. Any architecture which supports the
    SMP=y HOTPLUG_CPU=n combination suffers from the same issue. It's just less
    likely to be triggered because in 99.99999% of the cases all bringup
    callbacks succeed.
    
    The easy solution of making HOTPLUG_CPU mandatory for SMP is not working on
    all architectures as the following architectures have either no hotplug
    support at all or not all subarchitectures support it:
    
     alpha, arc, hexagon, openrisc, riscv, sparc (32bit), mips (partial).
    
    Crashing the kernel in such a situation is not an acceptable state
    either.
    
    Implement a minimal rollback variant by limiting the teardown to the point
    where all regular teardown callbacks have been invoked and leave the CPU in
    the 'dead' idle state. This has the following consequences:
    
     - the CPU is brought down to the point where the stop_machine takedown
       would happen.
    
     - the CPU stays there forever and is idle
    
     - The CPU is cleared in the CPU active mask, but not in the CPU online
       mask which is a legit state.
    
     - Interrupts are not forced away from the CPU
    
     - All facilities which only look at online mask would still see it, but
       that is the case during normal hotplug/unplug operations as well. It's
       just a (way) longer time frame.
    
    This will expose issues, which haven't been exposed before or only seldom,
    because now the normally transient state of being non active but online is
    a permanent state. In testing this exposed already an issue vs. work queues
    where the vmstat code schedules work on the almost dead CPU which ends up
    in an unbound workqueue and triggers 'preemtible context' warnings. This is
    not a problem of this change, it merily exposes an already existing issue.
    Still this is better than crashing fully without a chance to debug it.
    
    This is mainly thought as workaround for those architectures which do not
    support HOTPLUG_CPU. All others should enforce HOTPLUG_CPU for SMP.
    
    Fixes: 2e1a3483ce74 ("cpu/hotplug: Split out the state walk into functions")
    Reported-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Konrad Wilk <konrad.wilk@oracle.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Mukesh Ojha <mojha@codeaurora.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Micheal Kelley <michael.h.kelley@microsoft.com>
    Cc: "K. Y. Srinivasan" <kys@microsoft.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: K. Y. Srinivasan <kys@microsoft.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190326163811.503390616@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 336f6b23b5b842df367b2e78879a7605dd5c180c
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Mar 26 22:51:02 2019 +0100

    watchdog: Respect watchdog cpumask on CPU hotplug
    
    commit 7dd47617114921fdd8c095509e5e7b4373cc44a1 upstream.
    
    The rework of the watchdog core to use cpu_stop_work broke the watchdog
    cpumask on CPU hotplug.
    
    The watchdog_enable/disable() functions are now called unconditionally from
    the hotplug callback, i.e. even on CPUs which are not in the watchdog
    cpumask. As a consequence the watchdog can become unstoppable.
    
    Only invoke them when the plugged CPU is in the watchdog cpumask.
    
    Fixes: 9cf57731b63e ("watchdog/softlockup: Replace "watchdog/%u" threads with cpu_stop_work")
    Reported-by: Maxime Coquelin <maxime.coquelin@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Maxime Coquelin <maxime.coquelin@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Don Zickus <dzickus@redhat.com>
    Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1903262245490.1789@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c91d07ad34d76dfe65de02a87aced707c0a27da0
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Fri Mar 22 23:37:24 2019 +1100

    powerpc/64: Fix memcmp reading past the end of src/dest
    
    commit d9470757398a700d9450a43508000bcfd010c7a4 upstream.
    
    Chandan reported that fstests' generic/026 test hit a crash:
    
      BUG: Unable to handle kernel data access at 0xc00000062ac40000
      Faulting instruction address: 0xc000000000092240
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries
      CPU: 0 PID: 27828 Comm: chacl Not tainted 5.0.0-rc2-next-20190115-00001-g6de6dba64dda #1
      NIP:  c000000000092240 LR: c00000000066a55c CTR: 0000000000000000
      REGS: c00000062c0c3430 TRAP: 0300   Not tainted  (5.0.0-rc2-next-20190115-00001-g6de6dba64dda)
      MSR:  8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 44000842  XER: 20000000
      CFAR: 00007fff7f3108ac DAR: c00000062ac40000 DSISR: 40000000 IRQMASK: 0
      GPR00: 0000000000000000 c00000062c0c36c0 c0000000017f4c00 c00000000121a660
      GPR04: c00000062ac3fff9 0000000000000004 0000000000000020 00000000275b19c4
      GPR08: 000000000000000c 46494c4500000000 5347495f41434c5f c0000000026073a0
      GPR12: 0000000000000000 c0000000027a0000 0000000000000000 0000000000000000
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: c00000062ea70020 c00000062c0c38d0 0000000000000002 0000000000000002
      GPR24: c00000062ac3ffe8 00000000275b19c4 0000000000000001 c00000062ac30000
      GPR28: c00000062c0c38d0 c00000062ac30050 c00000062ac30058 0000000000000000
      NIP memcmp+0x120/0x690
      LR  xfs_attr3_leaf_lookup_int+0x53c/0x5b0
      Call Trace:
        xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable)
        xfs_da3_node_lookup_int+0x32c/0x5a0
        xfs_attr_node_addname+0x170/0x6b0
        xfs_attr_set+0x2ac/0x340
        __xfs_set_acl+0xf0/0x230
        xfs_set_acl+0xd0/0x160
        set_posix_acl+0xc0/0x130
        posix_acl_xattr_set+0x68/0x110
        __vfs_setxattr+0xa4/0x110
        __vfs_setxattr_noperm+0xac/0x240
        vfs_setxattr+0x128/0x130
        setxattr+0x248/0x600
        path_setxattr+0x108/0x120
        sys_setxattr+0x28/0x40
        system_call+0x5c/0x70
      Instruction dump:
      7d201c28 7d402428 7c295040 38630008 38840008 408201f0 4200ffe8 2c050000
      4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 7d4a3436 7c295040
    
    The instruction dump decodes as:
      subfic  r6,r5,8
      rlwinm  r6,r6,3,0,28
      ldbrx   r9,0,r3
      ldbrx   r10,0,r4      <-
    
    Which shows us doing an 8 byte load from c00000062ac3fff9, which
    crosses the page boundary at c00000062ac40000 and faults.
    
    It's not OK for memcmp to read past the end of the source or
    destination buffers if that would cross a page boundary, because we
    don't know that the next page is mapped.
    
    As pointed out by Segher, we can read past the end of the source or
    destination as long as we don't cross a 4K boundary, because that's
    our minimum page size on all platforms.
    
    The bug is in the code at the .Lcmp_rest_lt8bytes label. When we get
    there we know that s1 is 8-byte aligned and we have at least 1 byte to
    read, so a single 8-byte load won't read past the end of s1 and cross
    a page boundary.
    
    But we have to be more careful with s2. So check if it's within 8
    bytes of a 4K boundary and if so go to the byte-by-byte loop.
    
    Fixes: 2d9ee327adce ("powerpc/64: Align bytes before fall back to .Lshort in powerpc64 memcmp()")
    Cc: stable@vger.kernel.org # v4.19+
    Reported-by: Chandan Rajendra <chandan@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
    Tested-by: Chandan Rajendra <chandan@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7c00bbbfac42b1de08aba0130f2ece2be38c5aa
Author: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Date:   Fri Mar 8 21:03:24 2019 +0530

    powerpc/pseries/energy: Use OF accessor functions to read ibm,drc-indexes
    
    commit ce9afe08e71e3f7d64f337a6e932e50849230fc2 upstream.
    
    In cpu_to_drc_index() in the case when FW_FEATURE_DRC_INFO is absent,
    we currently use of_read_property() to obtain the pointer to the array
    corresponding to the property "ibm,drc-indexes". The elements of this
    array are of type __be32, but are accessed without any conversion to
    the OS-endianness, which is buggy on a Little Endian OS.
    
    Fix this by using of_property_read_u32_index() accessor function to
    safely read the elements of the array.
    
    Fixes: e83636ac3334 ("pseries/drc-info: Search DRC properties for CPU indexes")
    Cc: stable@vger.kernel.org # v4.16+
    Reported-by: Pavithra R. Prakash <pavrampu@in.ibm.com>
    Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
    Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
    [mpe: Make the WARN_ON a WARN_ON_ONCE so it's not retriggerable]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0603e3a9281debbb2ce8fcc19d4844686289d9b4
Author: Rolf Eike Beer <eb@emlix.com>
Date:   Tue Mar 26 12:48:39 2019 -0500

    objtool: Query pkg-config for libelf location
    
    commit 056d28d135bca0b1d0908990338e00e9dadaf057 upstream.
    
    If it is not in the default location, compilation fails at several points.
    
    Signed-off-by: Rolf Eike Beer <eb@emlix.com>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/91a25e992566a7968fedc89ec80e7f4c83ad0548.1553622500.git.jpoimboe@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a436cf6479c007489aed766567eb90cd4c170e00
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Mar 25 15:51:35 2019 +0200

    perf intel-pt: Fix TSC slip
    
    commit f3b4e06b3bda759afd042d3d5fa86bea8f1fe278 upstream.
    
    A TSC packet can slip past MTC packets so that the timestamp appears to
    go backwards. One estimate is that can be up to about 40 CPU cycles,
    which is certainly less than 0x1000 TSC ticks, but accept slippage an
    order of magnitude more to be on the safe side.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 79b58424b821c ("perf tools: Add Intel PT support for decoding MTC packets")
    Link: http://lkml.kernel.org/r/20190325135135.18348-1-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f9366330950b4e180c973155b855d218b605dfb
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Fri Mar 15 11:00:14 2019 -0700

    perf pmu: Fix parser error for uncore event alias
    
    commit e94d6b7f615e6dfbaf9fba7db6011db561461d0c upstream.
    
    Perf fails to parse uncore event alias, for example:
    
      # perf stat -e unc_m_clockticks -a --no-merge sleep 1
      event syntax error: 'unc_m_clockticks'
                           \___ parser error
    
    Current code assumes that the event alias is from one specific PMU.
    
    To find the PMU, perf strcmps the PMU name of event alias with the real
    PMU name on the system.
    
    However, the uncore event alias may be from multiple PMUs with common
    prefix. The PMU name of uncore event alias is the common prefix.
    
    For example, UNC_M_CLOCKTICKS is clock event for iMC, which include 6
    PMUs with the same prefix "uncore_imc" on a skylake server.
    
    The real PMU names on the system for iMC are uncore_imc_0 ...
    uncore_imc_5.
    
    The strncmp is used to only check the common prefix for uncore event
    alias.
    
    With the patch:
    
      # perf stat -e unc_m_clockticks -a --no-merge sleep 1
      Performance counter stats for 'system wide':
    
           723,594,722      unc_m_clockticks [uncore_imc_5]
           724,001,954      unc_m_clockticks [uncore_imc_3]
           724,042,655      unc_m_clockticks [uncore_imc_1]
           724,161,001      unc_m_clockticks [uncore_imc_4]
           724,293,713      unc_m_clockticks [uncore_imc_2]
           724,340,901      unc_m_clockticks [uncore_imc_0]
    
           1.002090060 seconds time elapsed
    
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Thomas Richter <tmricht@linux.ibm.com>
    Cc: stable@vger.kernel.org
    Fixes: ea1fa48c055f ("perf stat: Handle different PMU names with common prefix")
    Link: http://lkml.kernel.org/r/1552672814-156173-1-git-send-email-kan.liang@linux.intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f70ddae24bdfe267a920852d8d327eda653846bd
Author: Lars Persson <lars.persson@axis.com>
Date:   Thu Mar 28 20:44:28 2019 -0700

    mm/migrate.c: add missing flush_dcache_page for non-mapped page migrate
    
    commit d2b2c6dd227ba5b8a802858748ec9a780cb75b47 upstream.
    
    Our MIPS 1004Kc SoCs were seeing random userspace crashes with SIGILL
    and SIGSEGV that could not be traced back to a userspace code bug.  They
    had all the magic signs of an I/D cache coherency issue.
    
    Now recently we noticed that the /proc/sys/vm/compact_memory interface
    was quite efficient at provoking this class of userspace crashes.
    
    Studying the code in mm/migrate.c there is a distinction made between
    migrating a page that is mapped at the instant of migration and one that
    is not mapped.  Our problem turned out to be the non-mapped pages.
    
    For the non-mapped page the code performs a copy of the page content and
    all relevant meta-data of the page without doing the required D-cache
    maintenance.  This leaves dirty data in the D-cache of the CPU and on
    the 1004K cores this data is not visible to the I-cache.  A subsequent
    page-fault that triggers a mapping of the page will happily serve the
    process with potentially stale code.
    
    What about ARM then, this bug should have seen greater exposure? Well
    ARM became immune to this flaw back in 2010, see commit c01778001a4f
    ("ARM: 6379/1: Assume new page cache pages have dirty D-cache").
    
    My proposed fix moves the D-cache maintenance inside move_to_new_page to
    make it common for both cases.
    
    Link: http://lkml.kernel.org/r/20190315083502.11849-1-larper@axis.com
    Fixes: 97ee0524614 ("flush cache before installing new page at migraton")
    Signed-off-by: Lars Persson <larper@axis.com>
    Reviewed-by: Paul Burton <paul.burton@mips.com>
    Acked-by: Mel Gorman <mgorman@techsingularity.net>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5966777dd807a0525a99ba2473d7f9e84af309cb
Author: Yang Shi <yang.shi@linux.alibaba.com>
Date:   Thu Mar 28 20:43:55 2019 -0700

    mm: mempolicy: make mbind() return -EIO when MPOL_MF_STRICT is specified
    
    commit a7f40cfe3b7ada57af9b62fd28430eeb4a7cfcb7 upstream.
    
    When MPOL_MF_STRICT was specified and an existing page was already on a
    node that does not follow the policy, mbind() should return -EIO.  But
    commit 6f4576e3687b ("mempolicy: apply page table walker on
    queue_pages_range()") broke the rule.
    
    And commit c8633798497c ("mm: mempolicy: mbind and migrate_pages support
    thp migration") didn't return the correct value for THP mbind() too.
    
    If MPOL_MF_STRICT is set, ignore vma_migratable() to make sure it
    reaches queue_pages_to_pte_range() or queue_pages_pmd() to check if an
    existing page was already on a node that does not follow the policy.
    And, non-migratable vma may be used, return -EIO too if MPOL_MF_MOVE or
    MPOL_MF_MOVE_ALL was specified.
    
    Tested with https://github.com/metan-ucw/ltp/blob/master/testcases/kernel/syscalls/mbind/mbind02.c
    
    [akpm@linux-foundation.org: tweak code comment]
    Link: http://lkml.kernel.org/r/1553020556-38583-1-git-send-email-yang.shi@linux.alibaba.com
    Fixes: 6f4576e3687b ("mempolicy: apply page table walker on queue_pages_range()")
    Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
    Signed-off-by: Oscar Salvador <osalvador@suse.de>
    Reported-by: Cyril Hrubis <chrubis@suse.cz>
    Suggested-by: Kirill A. Shutemov <kirill@shutemov.name>
    Acked-by: Rafael Aquini <aquini@redhat.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9874d397807ef5a5dbcbb1f5ac60e10b346ac7b
Author: Nicolas Boichat <drinkcat@chromium.org>
Date:   Thu Mar 28 20:43:46 2019 -0700

    iommu/io-pgtable-arm-v7s: request DMA32 memory, and improve debugging
    
    commit 0a352554da69b02f75ca3389c885c741f1f63235 upstream.
    
    IOMMUs using ARMv7 short-descriptor format require page tables (level 1
    and 2) to be allocated within the first 4GB of RAM, even on 64-bit
    systems.
    
    For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32 is
    defined (e.g.  on arm64 platforms).
    
    For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32.  Note that
    we do not explicitly pass GFP_DMA[32] to kmem_cache_zalloc, as this is
    not strictly necessary, and would cause a warning in mm/sl*b.c, as we
    did not update GFP_SLAB_BUG_MASK.
    
    Also, print an error when the physical address does not fit in
    32-bit, to make debugging easier in the future.
    
    Link: http://lkml.kernel.org/r/20181210011504.122604-3-drinkcat@chromium.org
    Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Hsin-Yi Wang <hsinyi@chromium.org>
    Cc: Huaisheng Ye <yehs1@lenovo.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Matthias Brugger <matthias.bgg@gmail.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Sasha Levin <Alexander.Levin@microsoft.com>
    Cc: Tomasz Figa <tfiga@google.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
    Cc: Yong Wu <yong.wu@mediatek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62d342d6706069b4257611cb1a855f53b3fb4b02
Author: Nicolas Boichat <drinkcat@chromium.org>
Date:   Thu Mar 28 20:43:42 2019 -0700

    mm: add support for kmem caches in DMA32 zone
    
    commit 6d6ea1e967a246f12cfe2f5fb743b70b2e608d4a upstream.
    
    Patch series "iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables",
    v6.
    
    This is a followup to the discussion in [1], [2].
    
    IOMMUs using ARMv7 short-descriptor format require page tables (level 1
    and 2) to be allocated within the first 4GB of RAM, even on 64-bit
    systems.
    
    For L1 tables that are bigger than a page, we can just use
    __get_free_pages with GFP_DMA32 (on arm64 systems only, arm would still
    use GFP_DMA).
    
    For L2 tables that only take 1KB, it would be a waste to allocate a full
    page, so we considered 3 approaches:
     1. This series, adding support for GFP_DMA32 slab caches.
     2. genalloc, which requires pre-allocating the maximum number of L2 page
        tables (4096, so 4MB of memory).
     3. page_frag, which is not very memory-efficient as it is unable to reuse
        freed fragments until the whole page is freed. [3]
    
    This series is the most memory-efficient approach.
    
    stable@ note:
      We confirmed that this is a regression, and IOMMU errors happen on 4.19
      and linux-next/master on MT8173 (elm, Acer Chromebook R13). The issue
      most likely starts from commit ad67f5a6545f ("arm64: replace ZONE_DMA
      with ZONE_DMA32"), i.e. 4.15, and presumably breaks a number of Mediatek
      platforms (and maybe others?).
    
    [1] https://lists.linuxfoundation.org/pipermail/iommu/2018-November/030876.html
    [2] https://lists.linuxfoundation.org/pipermail/iommu/2018-December/031696.html
    [3] https://patchwork.codeaurora.org/patch/671639/
    
    This patch (of 3):
    
    IOMMUs using ARMv7 short-descriptor format require page tables to be
    allocated within the first 4GB of RAM, even on 64-bit systems.  On arm64,
    this is done by passing GFP_DMA32 flag to memory allocation functions.
    
    For IOMMU L2 tables that only take 1KB, it would be a waste to allocate
    a full page using get_free_pages, so we considered 3 approaches:
     1. This patch, adding support for GFP_DMA32 slab caches.
     2. genalloc, which requires pre-allocating the maximum number of L2
        page tables (4096, so 4MB of memory).
     3. page_frag, which is not very memory-efficient as it is unable
        to reuse freed fragments until the whole page is freed.
    
    This change makes it possible to create a custom cache in DMA32 zone using
    kmem_cache_create, then allocate memory using kmem_cache_alloc.
    
    We do not create a DMA32 kmalloc cache array, as there are currently no
    users of kmalloc(..., GFP_DMA32).  These calls will continue to trigger a
    warning, as we keep GFP_DMA32 in GFP_SLAB_BUG_MASK.
    
    This implies that calls to kmem_cache_*alloc on a SLAB_CACHE_DMA32
    kmem_cache must _not_ use GFP_DMA32 (it is anyway redundant and
    unnecessary).
    
    Link: http://lkml.kernel.org/r/20181210011504.122604-2-drinkcat@chromium.org
    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Sasha Levin <Alexander.Levin@microsoft.com>
    Cc: Huaisheng Ye <yehs1@lenovo.com>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Yong Wu <yong.wu@mediatek.com>
    Cc: Matthias Brugger <matthias.bgg@gmail.com>
    Cc: Tomasz Figa <tfiga@google.com>
    Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Hsin-Yi Wang <hsinyi@chromium.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2392ffab085a8300f1db73bfd130265715488af2
Author: Romain Izard <romain.izard.pro@gmail.com>
Date:   Fri Mar 22 16:53:02 2019 +0100

    usb: cdc-acm: fix race during wakeup blocking TX traffic
    
    commit 93e1c8a638308980309e009cc40b5a57ef87caf1 upstream.
    
    When the kernel is compiled with preemption enabled, the URB completion
    handler can run in parallel with the work responsible for waking up the
    tty layer. If the URB handler sets the EVENT_TTY_WAKEUP bit during the
    call to tty_port_tty_wakeup() to signal that there is room for additional
    input, it will be cleared at the end of this call. As a result, TX traffic
    on the upper layer will be blocked.
    
    This can be seen with a kernel configured with CONFIG_PREEMPT, and a fast
    modem connected with PPP running over a USB CDC-ACM port.
    
    Use test_and_clear_bit() instead, which ensures that each wakeup requested
    by the URB completion code will trigger a call to tty_port_tty_wakeup().
    
    Fixes: 1aba579f3cf5 cdc-acm: handle read pipe errors
    Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82a5090aad84e452dcf86864ffae71843607bff4
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Mar 22 17:50:17 2019 +0200

    xhci: Don't let USB3 ports stuck in polling state prevent suspend
    
    commit d92f2c59cc2cbca6bfb2cc54882b58ba76b15fd4 upstream.
    
    Commit 2f31a67f01a8 ("usb: xhci: Prevent bus suspend if a port connect
    change or polling state is detected") was intended to prevent ports that
    were still link training from being forced to U3 suspend state mid
    enumeration.
    This solved enumeration issues for devices with slow link training.
    
    Turns out some devices are stuck in the link training/polling state,
    and thus that patch will prevent suspend completely for these devices.
    This is seen with USB3 card readers in some MacBooks.
    
    Instead of preventing suspend, give some time to complete the link
    training. On successful training the port will end up as connected
    and enabled.
    If port instead is stuck in link training the bus suspend will continue
    suspending after 360ms (10 * 36ms) timeout (tPollingLFPSTimeout).
    
    Original patch was sent to stable, this one should go there as well
    
    Fixes: 2f31a67f01a8 ("usb: xhci: Prevent bus suspend if a port connect change or polling state is detected")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20a09a2e8703b9ea458fd6de3c5cf563501e571a
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Mar 22 17:50:16 2019 +0200

    usb: xhci: dbc: Don't free all memory with spinlock held
    
    commit 8867ea262196a6945c24a0fb739575af646ec0e9 upstream.
    
    The xhci debug capability (DbC) feature did its memory cleanup with
    spinlock held. dma_free_coherent() warns if called with interrupts
    disabled
    
    move the memory cleanup outside the spinlock
    
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c81b872281a12a26a945f8acc31d84544e1a222a
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Mar 22 17:50:15 2019 +0200

    xhci: Fix port resume done detection for SS ports with LPM enabled
    
    commit 6cbcf596934c8e16d6288c7cc62dfb7ad8eadf15 upstream.
    
    A suspended SS port in U3 link state will go to U0 when resumed, but
    can almost immediately after that enter U1 or U2 link power save
    states before host controller driver reads the port status.
    
    Host controller driver only checks for U0 state, and might miss
    the finished resume, leaving flags unclear and skip notifying usb
    code of the wake.
    
    Add U1 and U2 to the possible link states when checking for finished
    port resume.
    
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 093ccda1a041393c0588466a078e1f59837097cb
Author: Yasushi Asano <yasano@jp.adit-jv.com>
Date:   Mon Feb 18 11:26:34 2019 +0100

    usb: host: xhci-rcar: Add XHCI_TRUST_TX_LENGTH quirk
    
    commit 40fc165304f0faaae78b761f8ee30b5d216b1850 upstream.
    
    When plugging BUFFALO LUA4-U3-AGT USB3.0 to Gigabit Ethernet LAN
    Adapter, warning messages filled up dmesg.
    
    [  101.098287] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?
    [  101.117463] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?
    [  101.136513] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?
    
    Adding the XHCI_TRUST_TX_LENGTH quirk resolves the issue.
    
    Signed-off-by: Yasushi Asano <yasano@jp.adit-jv.com>
    Signed-off-by: Spyridon Papageorgiou <spapageorgiou@de.adit-jv.com>
    Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 015e5c17617a83351370af268e7484aa145144cb
Author: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Date:   Fri Mar 1 11:05:45 2019 +0000

    usb: common: Consider only available nodes for dr_mode
    
    commit 238e0268c82789e4c107a37045d529a6dbce51a9 upstream.
    
    There are cases where multiple device tree nodes point to the
    same phy node by means of the "phys" property, but we should
    only consider those nodes that are marked as available rather
    than just any node.
    
    Fixes: 98bfb3946695 ("usb: of: add an api to get dr_mode by the phy node")
    Cc: stable@vger.kernel.org # v4.4+
    Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef4df134e77eff719805941db4b1d304be1bf1e0
Author: Radoslav Gerganov <rgerganov@vmware.com>
Date:   Tue Mar 5 10:10:34 2019 +0000

    USB: gadget: f_hid: fix deadlock in f_hidg_write()
    
    commit 072684e8c58d17e853f8e8b9f6d9ce2e58d2b036 upstream.
    
    In f_hidg_write() the write_spinlock is acquired before calling
    usb_ep_queue() which causes a deadlock when dummy_hcd is being used.
    This is because dummy_queue() callbacks into f_hidg_req_complete() which
    tries to acquire the same spinlock. This is (part of) the backtrace when
    the deadlock occurs:
    
      0xffffffffc06b1410 in f_hidg_req_complete
      0xffffffffc06a590a in usb_gadget_giveback_request
      0xffffffffc06cfff2 in dummy_queue
      0xffffffffc06a4b96 in usb_ep_queue
      0xffffffffc06b1eb6 in f_hidg_write
      0xffffffff8127730b in __vfs_write
      0xffffffff812774d1 in vfs_write
      0xffffffff81277725 in SYSC_write
    
    Fix this by releasing the write_spinlock before calling usb_ep_queue()
    
    Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Tested-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: stable@vger.kernel.org # 4.11+
    Fixes: 749494b6bdbb ("usb: gadget: f_hid: fix: Move IN request allocation to set_alt()")
    Signed-off-by: Radoslav Gerganov <rgerganov@vmware.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 614ac345bfecfd7cb83537a6127a9dd3f0ee4003
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Mar 25 14:54:30 2019 +0100

    usb: mtu3: fix EXTCON dependency
    
    commit 3d54d10c6afed34fd45b852bf76f55e8da31d8ef upstream.
    
    When EXTCON is a loadable module, mtu3 fails to link as built-in:
    
    drivers/usb/mtu3/mtu3_plat.o: In function `mtu3_probe':
    mtu3_plat.c:(.text+0x690): undefined reference to `extcon_get_edev_by_phandle'
    
    Add a Kconfig dependency to force mtu3 also to be a loadable module
    if extconn is, but still allow it to be built without extcon.
    
    Fixes: d0ed062a8b75 ("usb: mtu3: dual-role mode support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66e44981de0e1cfd7f9331157ef4e7868d149327
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Fri Mar 22 16:51:07 2019 +0800

    phy: sun4i-usb: Support set_mode to USB_HOST for non-OTG PHYs
    
    commit 1396929e8a903db80425343cacca766a18ad6409 upstream.
    
    While only the first PHY supports mode switching, the remaining PHYs
    work in USB host mode. They should support set_mode with mode=USB_HOST
    instead of failing. This is especially needed now that the USB core does
    set_mode for all USB ports, which was added in commit b97a31348379 ("usb:
    core: comply to PHY framework").
    
    Make set_mode with mode=USB_HOST a no-op instead of failing for the
    non-OTG USB PHYs.
    
    Fixes: 6ba43c291961 ("phy-sun4i-usb: Add support for phy_set_mode")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ebe03734361063f665fb3b2478406abedd8eb04
Author: Axel Lin <axel.lin@ingics.com>
Date:   Mon Mar 11 21:29:37 2019 +0800

    gpio: adnp: Fix testing wrong value in adnp_gpio_direction_input
    
    commit c5bc6e526d3f217ed2cc3681d256dc4a2af4cc2b upstream.
    
    Current code test wrong value so it does not verify if the written
    data is correctly read back. Fix it.
    Also make it return -EPERM if read value does not match written bit,
    just like it done for adnp_gpio_direction_output().
    
    Fixes: 5e969a401a01 ("gpio: Add Avionic Design N-bit GPIO expander support")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Reviewed-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b26f7e86d3cc0e8744cf198118e313911f20f1f6
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Fri Mar 8 22:07:57 2019 -0600

    gpio: exar: add a check for the return value of ida_simple_get fails
    
    commit 7ecced0934e574b528a1ba6c237731e682216a74 upstream.
    
    ida_simple_get may fail and return a negative error number.
    The fix checks its return value; if it fails, go to err_destroy.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df74e70ffec6757f9ea75e7d1ea35de29c7d8b1a
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Wed Feb 20 16:25:04 2019 +0800

    drm/i915/gvt: Fix MI_FLUSH_DW parsing with correct index check
    
    commit 13bcb80b7ee79431fce361e060611134cb19e209 upstream.
    
    When MI_FLUSH_DW post write hw status page in index mode, the index
    value is in dword step and turned into address offset in cmd dword1.
    As status page size is 4K, so can't exceed that.
    
    This fixed upper bound check in cmd parser code which incorrectly
    stopped VM for reason of invalid MI_FLUSH_DW write index.
    
    v2:
    - Fix upper bound as 4K page size because index value is address offset.
    
    Fixes: be1da7070aea ("drm/i915/gvt: vGPU command scanner")
    Cc: stable@vger.kernel.org # v4.10+
    Cc: "Zhao, Yan Y" <yan.y.zhao@intel.com>
    Reviewed-by: Yan Zhao <yan.y.zhao@intel.com>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75f9e994b9fda979f542e8987bb9db9e2db82862
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Feb 26 14:08:58 2019 -0800

    drm/vkms: fix use-after-free when drm_gem_handle_create() fails
    
    commit 36b6c9ed45afe89045973e8dee1b004dd5372d40 upstream.
    
    If drm_gem_handle_create() fails in vkms_gem_create(), then the
    vkms_gem_object is freed twice: once when the reference is dropped by
    drm_gem_object_put_unlocked(), and again by the extra calls to
    drm_gem_object_release() and kfree().
    
    Fix it by skipping the second release and free.
    
    This bug was originally found in the vgem driver by syzkaller using
    fault injection, but I noticed it's also present in the vkms driver.
    
    Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations")
    Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
    Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
    Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190226220858.214438-1-ebiggers@kernel.org
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb1e552524b40df2534f4046161658fd5c73cc63
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Feb 26 13:44:51 2019 -0800

    drm/vgem: fix use-after-free when drm_gem_handle_create() fails
    
    commit 21d2b122732318b48c10b7262e15595ce54511d3 upstream.
    
    If drm_gem_handle_create() fails in vgem_gem_create(), then the
    drm_vgem_gem_object is freed twice: once when the reference is dropped
    by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().
    
    This was hit by syzkaller using fault injection.
    
    Fix it by skipping the second free.
    
    Reported-by: syzbot+e73f2fb5ed5a5df36d33@syzkaller.appspotmail.com
    Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Laura Abbott <labbott@redhat.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Laura Abbott <labbott@redhat.com>
    Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190226214451.195123-1-ebiggers@kernel.org
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07d0d2bd957ad922cf571e7cabb6c34067142b93
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Thu Mar 28 20:44:40 2019 -0700

    fs/proc/proc_sysctl.c: fix NULL pointer dereference in put_links
    
    commit 23da9588037ecdd4901db76a5b79a42b529c4ec3 upstream.
    
    Syzkaller reports:
    
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] SMP KASAN PTI
    CPU: 1 PID: 5373 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
    RIP: 0010:put_links+0x101/0x440 fs/proc/proc_sysctl.c:1599
    Code: 00 0f 85 3a 03 00 00 48 8b 43 38 48 89 44 24 20 48 83 c0 38 48 89 c2 48 89 44 24 28 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 fe 02 00 00 48 8b 74 24 20 48 c7 c7 60 2a 9d 91
    RSP: 0018:ffff8881d828f238 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: ffff8881e01b1140 RCX: ffffffff8ee98267
    RDX: 0000000000000007 RSI: ffffc90001479000 RDI: ffff8881e01b1178
    RBP: dffffc0000000000 R08: ffffed103ee27259 R09: ffffed103ee27259
    R10: 0000000000000001 R11: ffffed103ee27258 R12: fffffffffffffff4
    R13: 0000000000000006 R14: ffff8881f59838c0 R15: dffffc0000000000
    FS:  00007f072254f700(0000) GS:ffff8881f7100000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fff8b286668 CR3: 00000001f0542002 CR4: 00000000007606e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     drop_sysctl_table+0x152/0x9f0 fs/proc/proc_sysctl.c:1629
     get_subdir fs/proc/proc_sysctl.c:1022 [inline]
     __register_sysctl_table+0xd65/0x1090 fs/proc/proc_sysctl.c:1335
     br_netfilter_init+0xbc/0x1000 [br_netfilter]
     do_one_initcall+0xfa/0x5ca init/main.c:887
     do_init_module+0x204/0x5f6 kernel/module.c:3460
     load_module+0x66b2/0x8570 kernel/module.c:3808
     __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
     do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x462e99
    Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f072254ec58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
    RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
    RDX: 0000000000000000 RSI: 0000000020000280 RDI: 0000000000000003
    RBP: 00007f072254ec70 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f072254f6bc
    R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
    Modules linked in: br_netfilter(+) dvb_usb_dibusb_mc_common dib3000mc dibx000_common dvb_usb_dibusb_common dvb_usb_dw2102 dvb_usb classmate_laptop palmas_regulator cn videobuf2_v4l2 v4l2_common snd_soc_bd28623 mptbase snd_usb_usx2y snd_usbmidi_lib snd_rawmidi wmi libnvdimm lockd sunrpc grace rc_kworld_pc150u rc_core rtc_da9063 sha1_ssse3 i2c_cros_ec_tunnel adxl34x_spi adxl34x nfnetlink lib80211 i5500_temp dvb_as102 dvb_core videobuf2_common videodev media videobuf2_vmalloc videobuf2_memops udc_core lnbp22 leds_lp3952 hid_roccat_ryos s1d13xxxfb mtd vport_geneve openvswitch nf_conncount nf_nat_ipv6 nsh geneve udp_tunnel ip6_udp_tunnel snd_soc_mt6351 sis_agp phylink snd_soc_adau1761_spi snd_soc_adau1761 snd_soc_adau17x1 snd_soc_core snd_pcm_dmaengine ac97_bus snd_compress snd_soc_adau_utils snd_soc_sigmadsp_regmap snd_soc_sigmadsp raid_class hid_roccat_konepure hid_roccat_common hid_roccat c2port_duramar2150 core mdio_bcm_unimac iptable_security iptable_raw iptable_mangle
     iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim devlink vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel joydev mousedev ide_pci_generic piix aesni_intel aes_x86_64 ide_core crypto_simd atkbd cryptd glue_helper serio_raw ata_generic pata_acpi i2c_piix4 floppy sch_fq_codel ip_tables x_tables ipv6 [last unloaded: lm73]
    Dumping ftrace buffer:
       (ftrace buffer empty)
    ---[ end trace 770020de38961fd0 ]---
    
    A new dir entry can be created in get_subdir and its 'header->parent' is
    set to NULL.  Only after insert_header success, it will be set to 'dir',
    otherwise 'header->parent' is set to NULL and drop_sysctl_table is called.
    However in err handling path of get_subdir, drop_sysctl_table also be
    called on 'new->header' regardless its value of parent pointer.  Then
    put_links is called, which triggers NULL-ptr deref when access member of
    header->parent.
    
    In fact we have multiple error paths which call drop_sysctl_table() there,
    upon failure on insert_links() we also call drop_sysctl_table().And even
    in the successful case on __register_sysctl_table() we still always call
    drop_sysctl_table().This patch fix it.
    
    Link: http://lkml.kernel.org/r/20190314085527.13244-1-yuehaibing@huawei.com
    Fixes: 0e47c99d7fe25 ("sysctl: Replace root_list with links between sysctl_table_sets")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Acked-by: Luis Chamberlain <mcgrof@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: <stable@vger.kernel.org>    [3.4+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c956914f1efa6d4771881d49d3d08850048b3fec
Author: Wentao Wang <witallwang@gmail.com>
Date:   Wed Mar 20 15:30:39 2019 +0000

    Disable kgdboc failed by echo space to /sys/module/kgdboc/parameters/kgdboc
    
    commit 3ec8002951ea173e24b466df1ea98c56b7920e63 upstream.
    
    Echo "" to /sys/module/kgdboc/parameters/kgdboc will fail with "No such
    device” error.
    
    This is caused by function "configure_kgdboc" who init err to ENODEV
    when the config is empty (legal input) the code go out with ENODEV
    returned.
    
    Fixes: 2dd453168643 ("kgdboc: Fix restrict error")
    Signed-off-by: Wentao Wang <witallwang@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c992ea006ce2b7c79862943d275145986b28ea0
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed Mar 27 15:25:32 2019 +0100

    USB: serial: option: add Olicard 600
    
    commit 84f3b43f7378b98b7e3096d5499de75183d4347c upstream.
    
    This is a Qualcomm based device with a QMI function on interface 4.
    It is mode switched from 2020:2030 using a standard eject message.
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2020 ProdID=2031 Rev= 2.32
    S:  Manufacturer=Mobile Connect
    S:  Product=Mobile Connect
    S:  SerialNumber=0123456789ABCDEF
    C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
    E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    [ johan: use tabs to align comments in adjacent lines ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19151c645d0c3941d4edc2d6c6e8ca037d508d72
Author: Kristian Evensen <kristian.evensen@gmail.com>
Date:   Sat Mar 2 13:35:53 2019 +0100

    USB: serial: option: add support for Quectel EM12
    
    commit d1252f0237238b912c3e7a51bf237acf34c97983 upstream.
    
    The Quectel EM12 is a Cat. 12 LTE modem. It behaves in the exactly the
    same way as the EP06 (including the dynamic configuration behavior), so
    the same checks on reserved interfaces, etc. are needed.
    
    Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 002795b0d9b31dbc549c27ddf328652bc7415dca
Author: Mans Rullgard <mans@mansr.com>
Date:   Tue Feb 26 17:07:10 2019 +0000

    USB: serial: option: set driver_info for SIM5218 and compatibles
    
    commit f8df5c2c3e2df5ffaf9fb5503da93d477a8c7db4 upstream.
    
    The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4
    of which are serial ports.  The fifth is a network interface supported
    by the qmi-wwan driver.  Furthermore, the serial ports do not support
    modem control signals.  Add driver_info flags to reflect this.
    
    Signed-off-by: Mans Rullgard <mans@mansr.com>
    Fixes: ec0cd94d881c ("usb: option: add SIMCom SIM5218")
    Cc: stable <stable@vger.kernel.org>     # 3.2
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7dfccfd3c4b1b8b121b15011566cfc767d3fd6b
Author: Lin Yi <teroincn@163.com>
Date:   Wed Mar 20 19:04:56 2019 +0800

    USB: serial: mos7720: fix mos_parport refcount imbalance on error path
    
    commit 2908b076f5198d231de62713cb2b633a3a4b95ac upstream.
    
    The write_parport_reg_nonblock() helper takes a reference to the struct
    mos_parport, but failed to release it in a couple of error paths after
    allocation failures, leading to a memory leak.
    
    Johan said that move the kref_get() and mos_parport assignment to the
    end of urbtrack initialisation is a better way, so move it. and
    mos_parport do not used until urbtrack initialisation.
    
    Signed-off-by: Lin Yi <teroincn@163.com>
    Fixes: b69578df7e98 ("USB: usbserial: mos7720: add support for parallel port on moschip 7715")
    Cc: stable <stable@vger.kernel.org>     # 2.6.35
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f46db3cc133ef4d1b998940c700ff98904970b4
Author: George McCollister <george.mccollister@gmail.com>
Date:   Tue Mar 5 16:05:03 2019 -0600

    USB: serial: ftdi_sio: add additional NovaTech products
    
    commit 422c2537ba9d42320f8ab6573940269f87095320 upstream.
    
    Add PIDs for the NovaTech OrionLX+ and Orion I/O so they can be
    automatically detected.
    
    Signed-off-by: George McCollister <george.mccollister@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a63003545d0cf97d4ef961ebca588ed4d69b069
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Mar 27 10:11:14 2019 +0900

    USB: serial: cp210x: add new device id
    
    commit a595ecdd5f60b2d93863cebb07eec7f935839b54 upstream.
    
    Lorenz Messtechnik has a device that is controlled by the cp210x driver,
    so add the device id to the driver.  The device id was provided by
    Silicon-Labs for the devices from this vendor.
    
    Reported-by: Uli <t9cpu@web.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59203f078cc60a1c2d00d73a64536c8c6b0fb8d8
Author: Hoan Nguyen An <na-hoan@jinso.co.jp>
Date:   Mon Mar 18 18:26:32 2019 +0900

    serial: sh-sci: Fix setting SCSCR_TIE while transferring data
    
    commit 93bcefd4c6bad4c69dbc4edcd3fbf774b24d930d upstream.
    
    We disable transmission interrupt (clear SCSCR_TIE) after all data has been transmitted
    (if uart_circ_empty(xmit)). While transmitting, if the data is still in the tty buffer,
    re-enable the SCSCR_TIE bit, which was done at sci_start_tx().
    This is unnecessary processing, wasting CPU operation if the data transmission length is large.
    And further, transmit end, FIFO empty bits disabling have also been performed in the step above.
    
    Signed-off-by: Hoan Nguyen An <na-hoan@jinso.co.jp>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1e660c6f8026d52a54ea64288be4a3726fc3394
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Mon Mar 18 18:50:56 2019 -0500

    serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference
    
    commit 32f47179833b63de72427131169809065db6745e upstream.
    
    of_match_device on failure to find a matching device can return a NULL
    pointer. The patch checks for such a scenrio and passes the error upstream.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f34ec64b3f6cc2ae83da6901430be0204297f2d4
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Mon Mar 18 18:44:14 2019 -0500

    serial: max310x: Fix to avoid potential NULL pointer dereference
    
    commit 3a10e3dd52e80b9a97a3346020024d17b2c272d6 upstream.
    
    of_match_device can return a NULL pointer when matching device is not
    found. This patch avoids a scenario causing NULL pointer derefernce.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a090ed15420abf719ba077e9f60defbb1f636831
Author: Chao Yu <yuchao0@huawei.com>
Date:   Mon Mar 11 23:10:10 2019 +0800

    staging: erofs: fix to handle error path of erofs_vmap()
    
    commit 8bce6dcede65139a087ff240127e3f3c01363eed upstream.
    
    erofs_vmap() wrapped vmap() and vm_map_ram() to return virtual
    continuous memory, but both of them can failed due to a lot of
    reason, previously, erofs_vmap()'s callers didn't handle them,
    which can potentially cause NULL pointer access, fix it.
    
    Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
    Fixes: 0d40d6e399c1 ("staging: erofs: add a generic z_erofs VLE decompressor")
    Cc: <stable@vger.kernel.org> # 4.19+
    Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b6b76644ba59d268b24649c679f223bb4a813e8
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Sun Mar 24 18:53:49 2019 +0000

    staging: vt6655: Fix interrupt race condition on device start up.
    
    commit 3b9c2f2e0e99bb67c96abcb659b3465efe3bee1f upstream.
    
    It appears on some slower systems that the driver can find its way
    out of the workqueue while the interrupt is disabled by continuous polling
    by it.
    
    Move MACvIntEnable to vnt_interrupt_work so that it is always enabled
    on all routes out of vnt_interrupt_process.
    
    Move MACvIntDisable so that the device doesn't keep polling the system
    while the workqueue is being processed.
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    CC: stable@vger.kernel.org # v4.2+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9ddff2a41cd6247464dd86d3b9c4e02f916006d
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Wed Mar 27 18:45:26 2019 +0000

    staging: vt6655: Remove vif check from vnt_interrupt
    
    commit cc26358f89c3e493b54766b1ca56cfc6b14db78a upstream.
    
    A check for vif is made in vnt_interrupt_work.
    
    There is a small chance of leaving interrupt disabled while vif
    is NULL and the work hasn't been scheduled.
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    CC: stable@vger.kernel.org # v4.2+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86092f2d5ccba5ea3ec98b17225b98dbfce225d6
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Thu Mar 7 23:06:57 2019 +0100

    staging: speakup_soft: Fix alternate speech with other synths
    
    commit 45ac7b31bc6c4af885cc5b5d6c534c15bcbe7643 upstream.
    
    When switching from speakup_soft to another synth, speakup_soft would
    keep calling synth_buffer_getc() from softsynthx_read.
    
    Let's thus make synth.c export the knowledge of the current synth, so
    that speakup_soft can determine whether it should be running.
    
    speakup_soft also needs to set itself alive, otherwise the switch would
    let it remain silent.
    
    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0360bf48143539178e0196f8ee1f378e3586136
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Mon Mar 4 14:33:54 2019 +0000

    staging: comedi: ni_mio_common: Fix divide-by-zero for DIO cmdtest
    
    commit bafd9c64056cd034a1174dcadb65cd3b294ff8f6 upstream.
    
    `ni_cdio_cmdtest()` validates Comedi asynchronous commands for the DIO
    subdevice (subdevice 2) of supported National Instruments M-series
    cards.  It is called when handling the `COMEDI_CMD` and `COMEDI_CMDTEST`
    ioctls for this subdevice.  There are two causes for a possible
    divide-by-zero error when validating that the `stop_arg` member of the
    passed-in command is not too large.
    
    The first cause for the divide-by-zero is that calls to
    `comedi_bytes_per_scan()` are only valid once the command has been
    copied to `s->async->cmd`, but that copy is only done for the
    `COMEDI_CMD` ioctl.  For the `COMEDI_CMDTEST` ioctl, it will use
    whatever was left there by the previous `COMEDI_CMD` ioctl, if any.
    (This is very likely, as it is usual for the application to use
    `COMEDI_CMDTEST` before `COMEDI_CMD`.) If there has been no previous,
    valid `COMEDI_CMD` for this subdevice, then `comedi_bytes_per_scan()`
    will return 0, so the subsequent division in `ni_cdio_cmdtest()` of
    `s->async->prealloc_bufsz / comedi_bytes_per_scan(s)` will be a
    divide-by-zero error.  To fix this error, call a new function
    `comedi_bytes_per_scan_cmd(s, cmd)`, based on the existing
    `comedi_bytes_per_scan(s)` but using a specified `struct comedi_cmd` for
    its calculations.  (Also refactor `comedi_bytes_per_scan()` to call the
    new function.)
    
    Once the first cause for the divide-by-zero has been fixed, the second
    cause is that `comedi_bytes_per_scan_cmd()` can legitimately return 0 if
    the `scan_end_arg` member of the `struct comedi_cmd` being tested is 0.
    Fix it by only performing the division (and validating that `stop_arg`
    is no more than the maximum value) if `comedi_bytes_per_scan_cmd()`
    returns a non-zero value.
    
    The problem was reported on the COMEDI mailing list here:
    https://groups.google.com/forum/#!topic/comedi_list/4t9WlHzMhKM
    
    Reported-by: Ivan Vasilyev <grabesstimme@gmail.com>
    Tested-by: Ivan Vasilyev <grabesstimme@gmail.com>
    Fixes: f164cbf98fa8 ("staging: comedi: ni_mio_common: add finite regeneration to dio output")
    Cc: <stable@vger.kernel.org> # 4.6+
    Cc: Spencer E. Olson <olsonse@umich.edu>
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 668ba38d895088f81a29aa3b3552f1534aadefe7
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Fri Mar 8 11:37:44 2019 -0700

    tty: serial: qcom_geni_serial: Initialize baud in qcom_geni_console_setup
    
    commit c5cbc78acf693f5605d4a85b1327fa7933daf092 upstream.
    
    When building with -Wsometimes-uninitialized, Clang warns:
    
    drivers/tty/serial/qcom_geni_serial.c:1079:6: warning: variable 'baud'
    is used uninitialized whenever 'if' condition is false
    [-Wsometimes-uninitialized]
    
    It's not wrong; when options is NULL, baud has no default value. Use
    9600 as that is a sane default.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/395
    Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9bbd1edddf74701d51a50ca476fa7101655b693
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Fri Mar 15 12:16:06 2019 -0500

    tty: atmel_serial: fix a potential NULL pointer dereference
    
    commit c85be041065c0be8bc48eda4c45e0319caf1d0e5 upstream.
    
    In case dmaengine_prep_dma_cyclic fails, the fix returns a proper
    error code to avoid NULL pointer dereference.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Fixes: 34df42f59a60 ("serial: at91: add rx dma support")
    Acked-by: Richard Genoud <richard.genoud@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 124e42064c0dcbc0a260d0e18ed2410976422c54
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Thu Mar 14 02:21:51 2019 -0500

    tty: mxs-auart: fix a potential NULL pointer dereference
    
    commit 6734330654dac550f12e932996b868c6d0dcb421 upstream.
    
    In case ioremap fails, the fix returns -ENOMEM to avoid NULL
    pointer dereferences.
    Multiple places use port.membase.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fb7414da97e6ebbe1a220b38415700400d0b875
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Wed Feb 20 22:40:06 2019 +0000

    drm/rockchip: vop: reset scale mode when win is disabled
    
    commit e9abc611a941d4051cde1d94b2ab7473fdb50102 upstream.
    
    NV12 framebuffers produced by the VPU shows distorted on RK3288
    after win has been disabled when scaling is active.
    
    This issue can be reproduced using a 1080p modeset by:
    - Scale a 1280x720 NV12 framebuffer to 1920x1080 on win0
    - Disable win0
    - Display a 1920x1080 NV12 framebuffer without scaling on win0
    - Output will now show the framebuffer distorted
    
    And by:
    - Scale a 1280x720 NV12 framebuffer to 1920x1080
    - Change to a 720p modeset (win gets disabled and scaling reset to none)
    - Output will now show the framebuffer distorted
    
    Fix this by setting scale mode to none when win is disabled.
    
    Fixes: 4c156c21c794 ("drm/rockchip: vop: support plane scale")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/AM3PR03MB0966DE3E19BACE07328CD637AC7D0@AM3PR03MB0966.eurprd03.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a93cd9137feab1a1bc04f5110184280f8db50647
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Tue Mar 26 14:36:59 2019 +0100

    scsi: zfcp: fix scsi_eh host reset with port_forced ERP for non-NPIV FCP devices
    
    commit 242ec1455151267fe35a0834aa9038e4c4670884 upstream.
    
    Suppose more than one non-NPIV FCP device is active on the same channel.
    Send I/O to storage and have some of the pending I/O run into a SCSI
    command timeout, e.g. due to bit errors on the fibre. Now the error
    situation stops. However, we saw FCP requests continue to timeout in the
    channel. The abort will be successful, but the subsequent TUR fails.
    Scsi_eh starts. The LUN reset fails. The target reset fails.  The host
    reset only did an FCP device recovery. However, for non-NPIV FCP devices,
    this does not close and reopen ports on the SAN-side if other non-NPIV FCP
    device(s) share the same open ports.
    
    In order to resolve the continuing FCP request timeouts, we need to
    explicitly close and reopen ports on the SAN-side.
    
    This was missing since the beginning of zfcp in v2.6.0 history commit
    ea127f975424 ("[PATCH] s390 (7/7): zfcp host adapter.").
    
    Note: The FSF requests for forced port reopen could run into FSF request
    timeouts due to other reasons. This would trigger an internal FCP device
    recovery. Pending forced port reopen recoveries would get dismissed. So
    some ports might not get fully reopened during this host reset handler.
    However, subsequent I/O would trigger the above described escalation and
    eventually all ports would be forced reopen to resolve any continuing FCP
    request timeouts due to earlier bit errors.
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: <stable@vger.kernel.org> #3.0+
    Reviewed-by: Jens Remus <jremus@linux.ibm.com>
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 983a543de13a4bafe88958fcab5f41399fbb7eac
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Tue Mar 26 14:36:58 2019 +0100

    scsi: zfcp: fix rport unblock if deleted SCSI devices on Scsi_Host
    
    commit fe67888fc007a76b81e37da23ce5bd8fb95890b0 upstream.
    
    An already deleted SCSI device can exist on the Scsi_Host and remain there
    because something still holds a reference.  A new SCSI device with the same
    H:C:T:L and FCP device, target port WWPN, and FCP LUN can be created.  When
    we try to unblock an rport, we still find the deleted SCSI device and
    return early because the zfcp_scsi_dev of that SCSI device is not
    ZFCP_STATUS_COMMON_UNBLOCKED. Hence we miss to unblock the rport, even if
    the new proper SCSI device would be in good state.
    
    Therefore, skip deleted SCSI devices when iterating the sdevs of the shost.
    [cf. __scsi_device_lookup{_by_target}() or scsi_device_get()]
    
    The following abbreviated trace sequence can indicate such problem:
    
    Area           : REC
    Tag            : ersfs_3
    LUN            : 0x4045400300000000
    WWPN           : 0x50050763031bd327
    LUN status     : 0x40000000     not ZFCP_STATUS_COMMON_UNBLOCKED
    Ready count    : n              not incremented yet
    Running count  : 0x00000000
    ERP want       : 0x01
    ERP need       : 0xc1           ZFCP_ERP_ACTION_NONE
    
    Area           : REC
    Tag            : ersfs_3
    LUN            : 0x4045400300000000
    WWPN           : 0x50050763031bd327
    LUN status     : 0x41000000
    Ready count    : n+1
    Running count  : 0x00000000
    ERP want       : 0x01
    ERP need       : 0x01
    
    ...
    
    Area           : REC
    Level          : 4              only with increased trace level
    Tag            : ertru_l
    LUN            : 0x4045400300000000
    WWPN           : 0x50050763031bd327
    LUN status     : 0x40000000
    Request ID     : 0x0000000000000000
    ERP status     : 0x01800000
    ERP step       : 0x1000
    ERP action     : 0x01
    ERP count      : 0x00
    
    NOT followed by a trace record with tag "scpaddy"
    for WWPN 0x50050763031bd327.
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Fixes: 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery")
    Cc: <stable@vger.kernel.org> #2.6.32+
    Reviewed-by: Jens Remus <jremus@linux.ibm.com>
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a52eb223a6ee3a919283a05bb00023bd1225403e
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Wed Mar 27 12:11:52 2019 -0400

    scsi: sd: Quiesce warning if device does not report optimal I/O size
    
    commit 1d5de5bd311be7cd54f02f7cd164f0349a75c876 upstream.
    
    Commit a83da8a4509d ("scsi: sd: Optimal I/O size should be a multiple
    of physical block size") split one conditional into several separate
    statements in an effort to provide more accurate warning messages when
    a device reports a nonsensical value. However, this reorganization
    accidentally dropped the precondition of the reported value being
    larger than zero. This lead to a warning getting emitted on devices
    that do not report an optimal I/O size at all.
    
    Remain silent if a device does not report an optimal I/O size.
    
    Fixes: a83da8a4509d ("scsi: sd: Optimal I/O size should be a multiple of physical block size")
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: <stable@vger.kernel.org>
    Reported-by: Hussam Al-Tayeb <ht990332@gmx.com>
    Tested-by: Hussam Al-Tayeb <ht990332@gmx.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d72658775c4b2b33a71f0501448d2cd5d77145e1
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Mon Mar 25 10:01:46 2019 -0700

    scsi: sd: Fix a race between closing an sd device and sd I/O
    
    commit c14a57264399efd39514a2329c591a4b954246d8 upstream.
    
    The scsi_end_request() function calls scsi_cmd_to_driver() indirectly and
    hence needs the disk->private_data pointer. Avoid that that pointer is
    cleared before all affected I/O requests have finished. This patch avoids
    that the following crash occurs:
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    Call trace:
     scsi_mq_uninit_cmd+0x1c/0x30
     scsi_end_request+0x7c/0x1b8
     scsi_io_completion+0x464/0x668
     scsi_finish_command+0xbc/0x160
     scsi_eh_flush_done_q+0x10c/0x170
     sas_scsi_recover_host+0x84c/0xa98 [libsas]
     scsi_error_handler+0x140/0x5b0
     kthread+0x100/0x12c
     ret_from_fork+0x10/0x18
    
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Ming Lei <ming.lei@redhat.com>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Johannes Thumshirn <jthumshirn@suse.de>
    Cc: Jason Yan <yanaijie@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Reported-by: Jason Yan <yanaijie@huawei.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b3fcc3d4ffd9046b6ede3f62f473f40b8bd7493
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Thu Mar 28 20:43:38 2019 -0700

    ocfs2: fix inode bh swapping mixup in ocfs2_reflink_inodes_lock
    
    commit e6a9467ea14bae8691b0f72c500510c42ea8edb8 upstream.
    
    ocfs2_reflink_inodes_lock() can swap the inode1/inode2 variables so that
    we always grab cluster locks in order of increasing inode number.
    
    Unfortunately, we forget to swap the inode record buffer head pointers
    when we've done this, which leads to incorrect bookkeepping when we're
    trying to make the two inodes have the same refcount tree.
    
    This has the effect of causing filesystem shutdowns if you're trying to
    reflink data from inode 100 into inode 97, where inode 100 already has a
    refcount tree attached and inode 97 doesn't.  The reflink code decides
    to copy the refcount tree pointer from 100 to 97, but uses inode 97's
    inode record to open the tree root (which it doesn't have) and blows up.
    This issue causes filesystem shutdowns and metadata corruption!
    
    Link: http://lkml.kernel.org/r/20190312214910.GK20533@magnolia
    Fixes: 29ac8e856cb369 ("ocfs2: implement the VFS clone_range, copy_range, and dedupe_range features")
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Joseph Qi <jiangqi903@gmail.com>
    Cc: Mark Fasheh <mfasheh@versity.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Joseph Qi <joseph.qi@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72b790c417b9f6ffec9d04b77b29103f451725f6
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Thu Mar 28 20:43:30 2019 -0700

    fs/open.c: allow opening only regular files during execve()
    
    commit 73601ea5b7b18eb234219ae2adf77530f389da79 upstream.
    
    syzbot is hitting lockdep warning [1] due to trying to open a fifo
    during an execve() operation.  But we don't need to open non regular
    files during an execve() operation, for all files which we will need are
    the executable file itself and the interpreter programs like /bin/sh and
    ld-linux.so.2 .
    
    Since the manpage for execve(2) says that execve() returns EACCES when
    the file or a script interpreter is not a regular file, and the manpage
    for uselib(2) says that uselib() can return EACCES, and we use
    FMODE_EXEC when opening for execve()/uselib(), we can bail out if a non
    regular file is requested with FMODE_EXEC set.
    
    Since this deadlock followed by khungtaskd warnings is trivially
    reproducible by a local unprivileged user, and syzbot's frequent crash
    due to this deadlock defers finding other bugs, let's workaround this
    deadlock until we get a chance to find a better solution.
    
    [1] https://syzkaller.appspot.com/bug?id=b5095bfec44ec84213bac54742a82483aad578ce
    
    Link: http://lkml.kernel.org/r/1552044017-7890-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
    Reported-by: syzbot <syzbot+e93a80c1bb7c5c56e522461c149f8bf55eab1b2b@syzkaller.appspotmail.com>
    Fixes: 8924feff66f35fe2 ("splice: lift pipe_lock out of splice_to_pipe()")
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Eric Biggers <ebiggers3@gmail.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: <stable@vger.kernel.org>    [4.9+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa7f29f870278fca449a26e990717a46ec93834a
Author: Fredrik Noring <noring@nocrew.org>
Date:   Wed Mar 27 19:12:50 2019 +0100

    kbuild: modversions: Fix relative CRC byte order interpretation
    
    commit 54a7151b1496cddbb7a83546b7998103e98edc88 upstream.
    
    Fix commit 56067812d5b0 ("kbuild: modversions: add infrastructure for
    emitting relative CRCs") where CRCs are interpreted in host byte order
    rather than proper kernel byte order. The bug is conditional on
    CONFIG_MODULE_REL_CRCS.
    
    For example, when loading a BE module into a BE kernel compiled with a LE
    system, the error "disagrees about version of symbol module_layout" is
    produced. A message such as "Found checksum D7FA6856 vs module 5668FAD7"
    will be given with debug enabled, which indicates an obvious endian
    problem within __kcrctab within the kernel image.
    
    The general solution is to use the macro TO_NATIVE, as is done in
    similar cases throughout modpost.c. With this correction it has been
    verified that a BE kernel compiled with a LE system accepts BE modules.
    
    This change has also been verified with a LE kernel compiled with a LE
    system, in which case TO_NATIVE returns its value unmodified since the
    byte orders match. This is by far the common case.
    
    Fixes: 56067812d5b0 ("kbuild: modversions: add infrastructure for emitting relative CRCs")
    Signed-off-by: Fredrik Noring <noring@nocrew.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4dfae837ceafddc177d2dc2aaad7f8c463055685
Author: Bernhard Rosenkraenzer <bero@lindev.ch>
Date:   Tue Mar 5 00:38:19 2019 +0100

    ALSA: hda/realtek - Fix speakers on Acer Predator Helios 500 Ryzen laptops
    
    commit e2a829b3da01b9b32c4d0291d042b8a6e2a98ca3 upstream.
    
    On an Acer Predator Helios 500 (Ryzen version), the laptop's speakers
    don't work out of the box.
    
    The problem can be worked around with hdajackretask, remapping the
    "Black Headphone, Right side" pin (0x21) to the Internal speaker.
    
    This patch adds a quirk to change this mapping by default.
    
    [ corrected ALC299_FIXUP_PREDATOR_SPK definition and adapted for the
      latest tree by tiwai ]
    
    Signed-off-by: Bernhard Rosenkraenzer <bero@lindev.ch>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f3dbb71085c0c5b3517a0310c757486b96a0902
Author: Jian-Hong Pan <jian-hong@endlessm.com>
Date:   Fri Mar 22 11:37:22 2019 +0800

    ALSA: hda/realtek: Enable headset MIC of ASUS X430UN and X512DK with ALC256
    
    commit 6ac371aa1a74240fb910c98aa3484d5ece8473d3 upstream.
    
    The ASUS X430UN and X512DK with ALC256 cannot detect the headset MIC
    until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.
    
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Signed-off-by: Daniel Drake <drake@endlessm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 633d5db402800b19b444e6134dc992265f5fc3b9
Author: Chris Chiu <chiu@endlessm.com>
Date:   Fri Mar 22 11:37:20 2019 +0800

    ALSA: hda/realtek: Enable headset mic of ASUS P5440FF with ALC256
    
    commit a806ef1cf3bbc0baadc6cdeb11f12b5dd27e91c2 upstream.
    
    The ASUS laptop P5440FF with ALC256 can't detect the headset microphone
    until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.
    
    Signed-off-by: Chris Chiu <chiu@endlessm.com>
    Signed-off-by: Daniel Drake <drake@endlessm.com>
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd4000c77a5acf82a7b5d34d60bf511e61b2cbb0
Author: Jian-Hong Pan <jian-hong@endlessm.com>
Date:   Fri Mar 22 11:37:18 2019 +0800

    ALSA: hda/realtek: Enable ASUS X441MB and X705FD headset MIC with ALC256
    
    commit e1037354a0a75acdea2b27043c0a371ed85cf262 upstream.
    
    The ASUS laptop X441MB and X705FD with ALC256 cannot detect the headset
    MIC until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.
    
    Signed-off-by: Chris Chiu <chiu@endlessm.com>
    Signed-off-by: Daniel Drake <drake@endlessm.com>
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48e8e6a736b66d33cc08ea346f537fcd9416bd99
Author: Chris Chiu <chiu@endlessm.com>
Date:   Thu Mar 21 17:17:31 2019 +0800

    ALSA: hda/realtek - Add support for Acer Aspire E5-523G/ES1-432 headset mic
    
    commit c7531e31c8a440b5fe6bd62664def5bcb6262f96 upstream.
    
    The Acer laptop Aspire E5-523G and ES1-432 with ALC255 can't detect
    the headset microphone until ALC255_FIXUP_ACER_MIC_NO_PRESENCE quirk
    applied.
    
    Signed-off-by: Chris Chiu <chiu@endlessm.com>
    Signed-off-by: Daniel Drake <drake@endlessm.com>
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fa5a8679b92381e6d2506c32c1f0b3f4b231b87
Author: Jian-Hong Pan <jian-hong@endlessm.com>
Date:   Thu Mar 21 16:39:04 2019 +0800

    ALSA: hda/realtek: Enable headset MIC of Acer Aspire Z24-890 with ALC286
    
    commit 2733ccebf4a937a0858e7d05a4a003b89715033f upstream.
    
    The Acer Aspire Z24-890 cannot detect the headset MIC until
    ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk applied.
    
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Signed-off-by: Daniel Drake <drake@endlessm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ec67684be9e686a70d33a694baa53ec9b3ab4de
Author: Jian-Hong Pan <jian-hong@endlessm.com>
Date:   Fri Mar 15 17:51:09 2019 +0800

    ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286
    
    commit 667a8f73753908c4d0171e52b71774f9be5d6713 upstream.
    
    Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot
    record sound from headset MIC.  This patch adds the
    ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue.
    
    Fixes: 9f8aefed9623 ("ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G")
    Fixes: b72f936f6b32 ("ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G")
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Reviewed-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89ec6d400b5d701ba8b6c55ebf9aff609238af96
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Mar 14 15:50:59 2019 +0800

    ALSA: hda/realtek - Add support headset mode for New DELL WYSE NB
    
    commit da484d00f020af3dd7cfcc6c4b69a7f856832883 upstream.
    
    Enable headset mode support for new WYSE NB platform.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 522f06c9c00d47f21b986f24e835f58410c81f09
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Mar 14 16:22:45 2019 +0800

    ALSA: hda/realtek - Add support headset mode for DELL WYSE AIO
    
    commit 136824efaab2c095fc911048f7c7ddeda258c965 upstream.
    
    This patch will enable WYSE AIO for Headset mode.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b93302bbc4e64d8f32e3b4b6d9e82470a47a72e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Mar 25 10:38:58 2019 +0100

    ALSA: pcm: Don't suspend stream in unrecoverable PCM state
    
    commit 113ce08109f8e3b091399e7cc32486df1cff48e7 upstream.
    
    Currently PCM core sets each opened stream forcibly to SUSPENDED state
    via snd_pcm_suspend_all() call, and the user-space is responsible for
    re-triggering the resume manually either via snd_pcm_resume() or
    prepare call.  The scheme works fine usually, but there are corner
    cases where the stream can't be resumed by that call: the streams
    still in OPEN state before finishing hw_params.  When they are
    suspended, user-space cannot perform resume or prepare because they
    haven't been set up yet.  The only possible recovery is to re-open the
    device, which isn't nice at all.  Similarly, when a stream is in
    DISCONNECTED state, it makes no sense to change it to SUSPENDED
    state.  Ditto for in SETUP state; which you can re-prepare directly.
    
    So, this patch addresses these issues by filtering the PCM streams to
    be suspended by checking the PCM state.  When a stream is in either
    OPEN, SETUP or DISCONNECTED as well as already SUSPENDED, the suspend
    action is skipped.
    
    To be noted, this problem was originally reported for the PCM runtime
    PM on HD-audio.  And, the runtime PM problem itself was already
    addressed (although not intended) by the code refactoring commits
    3d21ef0b49f8 ("ALSA: pcm: Suspend streams globally via device type PM
    ops") and 17bc4815de58 ("ALSA: pci: Remove superfluous
    snd_pcm_suspend*() calls").  These commits eliminated the
    snd_pcm_suspend*() calls from the runtime PM suspend callback code
    path, hence the racy OPEN state won't appear while runtime PM.
    (FWIW, the race window is between snd_pcm_open_substream() and the
    first power up in azx_pcm_open().)
    
    Although the runtime PM issue was already "fixed", the same problem is
    still present for the system PM, hence this patch is still needed.
    And for stable trees, this patch alone should suffice for fixing the
    runtime PM problem, too.
    
    Reported-and-tested-by: Jon Hunter <jonathanh@nvidia.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fc6064dc3b21f70c18f45c5e98b0e9e17770954
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Mar 22 16:00:54 2019 +0100

    ALSA: pcm: Fix possible OOB access in PCM oss plugins
    
    commit ca0214ee2802dd47239a4e39fb21c5b00ef61b22 upstream.
    
    The PCM OSS emulation converts and transfers the data on the fly via
    "plugins".  The data is converted over the dynamically allocated
    buffer for each plugin, and recently syzkaller caught OOB in this
    flow.
    
    Although the bisection by syzbot pointed out to the commit
    65766ee0bf7f ("ALSA: oss: Use kvzalloc() for local buffer
    allocations"), this is merely a commit to replace vmalloc() with
    kvmalloc(), hence it can't be the cause.  The further debug action
    revealed that this happens in the case where a slave PCM doesn't
    support only the stereo channels while the OSS stream is set up for a
    mono channel.  Below is a brief explanation:
    
    At each OSS parameter change, the driver sets up the PCM hw_params
    again in snd_pcm_oss_change_params_lock().  This is also the place
    where plugins are created and local buffers are allocated.  The
    problem is that the plugins are created before the final hw_params is
    determined.  Namely, two snd_pcm_hw_param_near() calls for setting the
    period size and periods may influence on the final result of channels,
    rates, etc, too, while the current code has already created plugins
    beforehand with the premature values.  So, the plugin believes that
    channels=1, while the actual I/O is with channels=2, which makes the
    driver reading/writing over the allocated buffer size.
    
    The fix is simply to move the plugin allocation code after the final
    hw_params call.
    
    Reported-by: syzbot+d4503ae45b65c5bc1194@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b425f45295dd9692c146a6ca46cb533195aa3d9f
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Wed Mar 20 18:42:01 2019 -0500

    ALSA: seq: oss: Fix Spectre v1 vulnerability
    
    commit c709f14f0616482b67f9fbcb965e1493a03ff30b upstream.
    
    dev is indirectly controlled by user-space, hence leading to
    a potential exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn: potential spectre issue 'dp->synths' [w] (local cap)
    
    Fix this by sanitizing dev before using it to index dp->synths.
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd55e6727a33b89d5575e2759eef82ad9551a45c
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Wed Mar 20 16:15:24 2019 -0500

    ALSA: rawmidi: Fix potential Spectre v1 vulnerability
    
    commit 2b1d9c8f87235f593826b9cf46ec10247741fff9 upstream.
    
    info->stream is indirectly controlled by user-space, hence leading to
    a potential exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    sound/core/rawmidi.c:604 __snd_rawmidi_info_select() warn: potential spectre issue 'rmidi->streams' [r] (local cap)
    
    Fix this by sanitizing info->stream before using it to index
    rmidi->streams.
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a485919fe4cc18d72bd0bae8e11fdcaf75b378f0
Author: Christian Lamparter <chunkeey@gmail.com>
Date:   Fri Mar 22 01:05:02 2019 +0100

    net: dsa: qca8k: remove leftover phy accessors
    
    commit 1eec7151ae0e134bd42e3f128066b2ff8da21393 upstream.
    
    This belated patch implements Andrew Lunn's request of
    "remove the phy_read() and phy_write() functions."
    <https://lore.kernel.org/patchwork/comment/902734/>
    
    While seemingly harmless, this causes the switch's user
    port PHYs to get registered twice. This is because the
    DSA subsystem will create a slave mdio-bus not knowing
    that the qca8k_phy_(read|write) accessors operate on
    the external mdio-bus. So the same "bus" gets effectively
    duplicated.
    
    Cc: stable@vger.kernel.org
    Fixes: 6b93fb46480a ("net-next: dsa: add new driver for qca8xxx family")
    Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64751542d3f3a6e9ccf88dab1fd05cc47bcba301
Author: Olga Kornievskaia <kolga@netapp.com>
Date:   Tue Mar 19 12:12:13 2019 -0400

    NFSv4.1 don't free interrupted slot on open
    
    commit 0cb98abb5bd13b9a636bde603d952d722688b428 upstream.
    
    Allow the async rpc task for finish and update the open state if needed,
    then free the slot. Otherwise, the async rpc unable to decode the reply.
    
    Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
    Fixes: ae55e59da0e4 ("pnfs: Don't release the sequence slot...")
    Cc: stable@vger.kernel.org # v4.18+
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da57cba4f3f1c63303cffcee97cf4d7bf1ff386a
Author: NeilBrown <neilb@suse.com>
Date:   Tue Mar 19 11:33:24 2019 +1100

    NFS: fix mount/umount race in nlmclnt.
    
    commit 4a9be28c45bf02fa0436808bb6c0baeba30e120e upstream.
    
    If the last NFSv3 unmount from a given host races with a mount from the
    same host, we can destroy an nlm_host that is still in use.
    
    Specifically nlmclnt_lookup_host() can increment h_count on
    an nlm_host that nlmclnt_release_host() has just successfully called
    refcount_dec_and_test() on.
    Once nlmclnt_lookup_host() drops the mutex, nlm_destroy_host_lock()
    will be called to destroy the nlmclnt which is now in use again.
    
    The cause of the problem is that the dec_and_test happens outside the
    locked region.  This is easily fixed by using
    refcount_dec_and_mutex_lock().
    
    Fixes: 8ea6ecc8b075 ("lockd: Create client-side nlm_host cache")
    Cc: stable@vger.kernel.org (v2.6.38+)
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f273f0c3064dab95c82d6046b0f5ea2ababd304
Author: Cornelia Huck <cohuck@redhat.com>
Date:   Mon Mar 11 10:59:53 2019 +0100

    vfio: ccw: only free cp on final interrupt
    
    commit 50b7f1b7236bab08ebbbecf90521e84b068d7a17 upstream.
    
    When we get an interrupt for a channel program, it is not
    necessarily the final interrupt; for example, the issuing
    guest may request an intermediate interrupt by specifying
    the program-controlled-interrupt flag on a ccw.
    
    We must not switch the state to idle if the interrupt is not
    yet final; even more importantly, we must not free the translated
    channel program if the interrupt is not yet final, or the host
    can crash during cp rewind.
    
    Fixes: e5f84dbaea59 ("vfio: ccw: return I/O results asynchronously")
    Cc: stable@vger.kernel.org # v4.12+
    Reviewed-by: Eric Farman <farman@linux.ibm.com>
    Signed-off-by: Cornelia Huck <cohuck@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92d4ee2e82767998f1300e6ac4fc9f95bf860b7c
Author: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Date:   Fri Mar 15 20:21:19 2019 +0530

    powerpc: bpf: Fix generation of load/store DW instructions
    
    commit 86be36f6502c52ddb4b85938145324fd07332da1 upstream.
    
    Yauheni Kaliuta pointed out that PTR_TO_STACK store/load verifier test
    was failing on powerpc64 BE, and rightfully indicated that the PPC_LD()
    macro is not masking away the last two bits of the offset per the ISA,
    resulting in the generation of 'lwa' instruction instead of the intended
    'ld' instruction.
    
    Segher also pointed out that we can't simply mask away the last two bits
    as that will result in loading/storing from/to a memory location that
    was not intended.
    
    This patch addresses this by using ldx/stdx if the offset is not
    word-aligned. We load the offset into a temporary register (TMP_REG_2)
    and use that as the index register in a subsequent ldx/stdx. We fix
    PPC_LD() macro to mask off the last two bits, but enhance PPC_BPF_LL()
    and PPC_BPF_STL() to factor in the offset value and generate the proper
    instruction sequence. We also convert all existing users of PPC_LD() and
    PPC_STD() to use these macros. All existing uses of these macros have
    been audited to ensure that TMP_REG_2 can be clobbered.
    
    Fixes: 156d0e290e96 ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
    Cc: stable@vger.kernel.org # v4.9+
    
    Reported-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
    Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9397f0d9948c466612799899e7205d403b0621ce
Author: Kohji Okuno <okuno.kohji@jp.panasonic.com>
Date:   Tue Feb 26 11:34:13 2019 +0900

    ARM: imx6q: cpuidle: fix bug that CPU might not wake up at expected time
    
    commit 91740fc8242b4f260cfa4d4536d8551804777fae upstream.
    
    In the current cpuidle implementation for i.MX6q, the CPU that sets
    'WAIT_UNCLOCKED' and the CPU that returns to 'WAIT_CLOCKED' are always
    the same. While the CPU that sets 'WAIT_UNCLOCKED' is in IDLE state of
    "WAIT", if the other CPU wakes up and enters IDLE state of "WFI"
    istead of "WAIT", this CPU can not wake up at expired time.
     Because, in the case of "WFI", the CPU must be waked up by the local
    timer interrupt. But, while 'WAIT_UNCLOCKED' is set, the local timer
    is stopped, when all CPUs execute "wfi" instruction. As a result, the
    local timer interrupt is not fired.
     In this situation, this CPU will wake up by IRQ different from local
    timer. (e.g. broacast timer)
    
    So, this fix changes CPU to return to 'WAIT_CLOCKED'.
    
    Signed-off-by: Kohji Okuno <okuno.kohji@jp.panasonic.com>
    Fixes: e5f9dec8ff5f ("ARM: imx6q: support WAIT mode using cpuidle")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd1b25364fef1cb5d7898b751f531bf754a39af5
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Mar 19 17:18:13 2019 +0000

    Btrfs: fix assertion failure on fsync with NO_HOLES enabled
    
    commit 0ccc3876e4b2a1559a4dbe3126dda4459d38a83b upstream.
    
    Back in commit a89ca6f24ffe4 ("Btrfs: fix fsync after truncate when
    no_holes feature is enabled") I added an assertion that is triggered when
    an inline extent is found to assert that the length of the (uncompressed)
    data the extent represents is the same as the i_size of the inode, since
    that is true most of the time I couldn't find or didn't remembered about
    any exception at that time. Later on the assertion was expanded twice to
    deal with a case of a compressed inline extent representing a range that
    matches the sector size followed by an expanding truncate, and another
    case where fallocate can update the i_size of the inode without adding
    or updating existing extents (if the fallocate range falls entirely within
    the first block of the file). These two expansion/fixes of the assertion
    were done by commit 7ed586d0a8241 ("Btrfs: fix assertion on fsync of
    regular file when using no-holes feature") and commit 6399fb5a0b69a
    ("Btrfs: fix assertion failure during fsync in no-holes mode").
    These however missed the case where an falloc expands the i_size of an
    inode to exactly the sector size and inline extent exists, for example:
    
     $ mkfs.btrfs -f -O no-holes /dev/sdc
     $ mount /dev/sdc /mnt
    
     $ xfs_io -f -c "pwrite -S 0xab 0 1096" /mnt/foobar
     wrote 1096/1096 bytes at offset 0
     1 KiB, 1 ops; 0.0002 sec (4.448 MiB/sec and 4255.3191 ops/sec)
    
     $ xfs_io -c "falloc 1096 3000" /mnt/foobar
     $ xfs_io -c "fsync" /mnt/foobar
     Segmentation fault
    
     $ dmesg
     [701253.602385] assertion failed: len == i_size || (len == fs_info->sectorsize && btrfs_file_extent_compression(leaf, extent) != BTRFS_COMPRESS_NONE) || (len < i_size && i_size < fs_info->sectorsize), file: fs/btrfs/tree-log.c, line: 4727
     [701253.602962] ------------[ cut here ]------------
     [701253.603224] kernel BUG at fs/btrfs/ctree.h:3533!
     [701253.603503] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
     [701253.603774] CPU: 2 PID: 7192 Comm: xfs_io Tainted: G        W         5.0.0-rc8-btrfs-next-45 #1
     [701253.604054] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014
     [701253.604650] RIP: 0010:assfail.constprop.23+0x18/0x1a [btrfs]
     (...)
     [701253.605591] RSP: 0018:ffffbb48c186bc48 EFLAGS: 00010286
     [701253.605914] RAX: 00000000000000de RBX: ffff921d0a7afc08 RCX: 0000000000000000
     [701253.606244] RDX: 0000000000000000 RSI: ffff921d36b16868 RDI: ffff921d36b16868
     [701253.606580] RBP: ffffbb48c186bcf0 R08: 0000000000000000 R09: 0000000000000000
     [701253.606913] R10: 0000000000000003 R11: 0000000000000000 R12: ffff921d05d2de18
     [701253.607247] R13: ffff921d03b54000 R14: 0000000000000448 R15: ffff921d059ecf80
     [701253.607769] FS:  00007f14da906700(0000) GS:ffff921d36b00000(0000) knlGS:0000000000000000
     [701253.608163] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     [701253.608516] CR2: 000056087ea9f278 CR3: 00000002268e8001 CR4: 00000000003606e0
     [701253.608880] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     [701253.609250] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
     [701253.609608] Call Trace:
     [701253.609994]  btrfs_log_inode+0xdfb/0xe40 [btrfs]
     [701253.610383]  btrfs_log_inode_parent+0x2be/0xa60 [btrfs]
     [701253.610770]  ? do_raw_spin_unlock+0x49/0xc0
     [701253.611150]  btrfs_log_dentry_safe+0x4a/0x70 [btrfs]
     [701253.611537]  btrfs_sync_file+0x3b2/0x440 [btrfs]
     [701253.612010]  ? do_sysinfo+0xb0/0xf0
     [701253.612552]  do_fsync+0x38/0x60
     [701253.612988]  __x64_sys_fsync+0x10/0x20
     [701253.613360]  do_syscall_64+0x60/0x1b0
     [701253.613733]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
     [701253.614103] RIP: 0033:0x7f14da4e66d0
     (...)
     [701253.615250] RSP: 002b:00007fffa670fdb8 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
     [701253.615647] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f14da4e66d0
     [701253.616047] RDX: 000056087ea9c260 RSI: 000056087ea9c260 RDI: 0000000000000003
     [701253.616450] RBP: 0000000000000001 R08: 0000000000000020 R09: 0000000000000010
     [701253.616854] R10: 000000000000009b R11: 0000000000000246 R12: 000056087ea9c260
     [701253.617257] R13: 000056087ea9c240 R14: 0000000000000000 R15: 000056087ea9dd10
     (...)
     [701253.619941] ---[ end trace e088d74f132b6da5 ]---
    
    Updating the assertion again to allow for this particular case would result
    in a meaningless assertion, plus there is currently no risk of logging
    content that would result in any corruption after a log replay if the size
    of the data encoded in an inline extent is greater than the inode's i_size
    (which is not currently possibe either with or without compression),
    therefore just remove the assertion.
    
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ae3b84b3fa6cd988c8ee65053f6fa34bfda3034
Author: Nikolay Borisov <nborisov@suse.com>
Date:   Mon Mar 18 17:45:20 2019 +0200

    btrfs: Avoid possible qgroup_rsv_size overflow in btrfs_calculate_inode_block_rsv_size
    
    commit 139a56170de67101791d6e6c8e940c6328393fe9 upstream.
    
    qgroup_rsv_size is calculated as the product of
    outstanding_extent * fs_info->nodesize. The product is calculated with
    32 bit precision since both variables are defined as u32. Yet
    qgroup_rsv_size expects a 64 bit result.
    
    Avoid possible multiplication overflow by casting outstanding_extent to
    u64. Such overflow would in the worst case (64K nodesize) require more
    than 65536 extents, which is quite large and i'ts not likely that it
    would happen in practice.
    
    Fixes-coverity-id: 1435101
    Fixes: ff6bc37eb7f6 ("btrfs: qgroup: Use independent and accurate per inode qgroup rsv")
    CC: stable@vger.kernel.org # 4.19+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cf4ab01eb5aa72fab9acf405b4a9037dcc7cefc
Author: Andrea Righi <andrea.righi@canonical.com>
Date:   Thu Mar 14 08:56:28 2019 +0100

    btrfs: raid56: properly unmap parity page in finish_parity_scrub()
    
    commit 3897b6f0a859288c22fb793fad11ec2327e60fcd upstream.
    
    Parity page is incorrectly unmapped in finish_parity_scrub(), triggering
    a reference counter bug on i386, i.e.:
    
     [ 157.662401] kernel BUG at mm/highmem.c:349!
     [ 157.666725] invalid opcode: 0000 [#1] SMP PTI
    
    The reason is that kunmap(p_page) was completely left out, so we never
    did an unmap for the p_page and the loop unmapping the rbio page was
    iterating over the wrong number of stripes: unmapping should be done
    with nr_data instead of rbio->real_stripes.
    
    Test case to reproduce the bug:
    
     - create a raid5 btrfs filesystem:
       # mkfs.btrfs -m raid5 -d raid5 /dev/sdb /dev/sdc /dev/sdd /dev/sde
    
     - mount it:
       # mount /dev/sdb /mnt
    
     - run btrfs scrub in a loop:
       # while :; do btrfs scrub start -BR /mnt; done
    
    BugLink: https://bugs.launchpad.net/bugs/1812845
    Fixes: 5a6ac9eacb49 ("Btrfs, raid56: support parity scrub on raid56")
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d952c337b25d3f3d3e4b2156b2ab83118c7951fd
Author: David Sterba <dsterba@suse.com>
Date:   Thu Mar 7 15:40:50 2019 +0100

    btrfs: don't report readahead errors and don't update statistics
    
    commit 0cc068e6ee59c1fffbfa977d8bf868b7551d80ac upstream.
    
    As readahead is an optimization, all errors are usually filtered out,
    but still properly handled when the real read call is done. The commit
    5e9d398240b2 ("btrfs: readpages() should submit IO as read-ahead") added
    REQ_RAHEAD to readpages() because that's only used for readahead
    (despite what one would expect from the callback name).
    
    This causes a flood of messages and inflated read error stats, so skip
    reporting in case it's readahead.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202403
    Reported-by: LimeTech <tomm@lime-technology.com>
    Fixes: 5e9d398240b2 ("btrfs: readpages() should submit IO as read-ahead")
    CC: stable@vger.kernel.org # 4.19+
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b57220cc982033dc8e1e8d398cb006b72b275213
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Mar 6 17:13:04 2019 -0500

    btrfs: remove WARN_ON in log_dir_items
    
    commit 2cc8334270e281815c3850c3adea363c51f21e0d upstream.
    
    When Filipe added the recursive directory logging stuff in
    2f2ff0ee5e430 ("Btrfs: fix metadata inconsistencies after directory
    fsync") he specifically didn't take the directory i_mutex for the
    children directories that we need to log because of lockdep.  This is
    generally fine, but can lead to this WARN_ON() tripping if we happen to
    run delayed deletion's in between our first search and our second search
    of dir_item/dir_indexes for this directory.  We expect this to happen,
    so the WARN_ON() isn't necessary.  Drop the WARN_ON() and add a comment
    so we know why this case can happen.
    
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22dcb30fb9d8199b9a105f699b828dedb5b59d36
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Mar 4 14:06:12 2019 +0000

    Btrfs: fix incorrect file size after shrinking truncate and fsync
    
    commit bf504110bc8aa05df48b0e5f0aa84bfb81e0574b upstream.
    
    If we do a shrinking truncate against an inode which is already present
    in the respective log tree and then rename it, as part of logging the new
    name we end up logging an inode item that reflects the old size of the
    file (the one which we previously logged) and not the new smaller size.
    The decision to preserve the size previously logged was added by commit
    1a4bcf470c886b ("Btrfs: fix fsync data loss after adding hard link to
    inode") in order to avoid data loss after replaying the log. However that
    decision is only needed for the case the logged inode size is smaller then
    the current size of the inode, as explained in that commit's change log.
    If the current size of the inode is smaller then the previously logged
    size, we know a shrinking truncate happened and therefore need to use
    that smaller size.
    
    Example to trigger the problem:
    
      $ mkfs.btrfs -f /dev/sdb
      $ mount /dev/sdb /mnt
    
      $ xfs_io -f -c "pwrite -S 0xab 0 8000" /mnt/foo
      $ xfs_io -c "fsync" /mnt/foo
      $ xfs_io -c "truncate 3000" /mnt/foo
    
      $ mv /mnt/foo /mnt/bar
      $ xfs_io -c "fsync" /mnt/bar
    
      <power failure>
    
      $ mount /dev/sdb /mnt
      $ od -t x1 -A d /mnt/bar
      0000000 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
      *
      0008000
    
    Once we rename the file, we log its name (and inode item), and because
    the inode was already logged before in the current transaction, we log it
    with a size of 8000 bytes because that is the size we previously logged
    (with the first fsync). As part of the rename, besides logging the inode,
    we do also sync the log, which is done since commit d4682ba03ef618
    ("Btrfs: sync log after logging new name"), so the next fsync against our
    inode is effectively a no-op, since no new changes happened since the
    rename operation. Even if did not sync the log during the rename
    operation, the same problem (fize size of 8000 bytes instead of 3000
    bytes) would be visible after replaying the log if the log ended up
    getting synced to disk through some other means, such as for example by
    fsyncing some other modified file. In the example above the fsync after
    the rename operation is there just because not every filesystem may
    guarantee logging/journalling the inode (and syncing the log/journal)
    during the rename operation, for example it is needed for f2fs, but not
    for ext4 and xfs.
    
    Fix this scenario by, when logging a new name (which is triggered by
    rename and link operations), using the current size of the inode instead
    of the previously logged inode size.
    
    A test case for fstests follows soon.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202695
    CC: stable@vger.kernel.org # 4.4+
    Reported-by: Seulbae Kim <seulbae@gatech.edu>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1df5db3a9f11f1fbabc44972ca9d4a851d7f042
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Fri Mar 29 22:26:20 2019 +1100

    powerpc/security: Fix spectre_v2 reporting
    
    commit 92edf8df0ff2ae86cc632eeca0e651fd8431d40d upstream.
    
    When I updated the spectre_v2 reporting to handle software count cache
    flush I got the logic wrong when there's no software count cache
    enabled at all.
    
    The result is that on systems with the software count cache flush
    disabled we print:
    
      Mitigation: Indirect branch cache disabled, Software count cache flush
    
    Which correctly indicates that the count cache is disabled, but
    incorrectly says the software count cache flush is enabled.
    
    The root of the problem is that we are trying to handle all
    combinations of options. But we know now that we only expect to see
    the software count cache flush enabled if the other options are false.
    
    So split the two cases, which simplifies the logic and fixes the bug.
    We were also missing a space before "(hardware accelerated)".
    
    The result is we see one of:
    
      Mitigation: Indirect branch serialisation (kernel only)
      Mitigation: Indirect branch cache disabled
      Mitigation: Software count cache flush
      Mitigation: Software count cache flush (hardware accelerated)
    
    Fixes: ee13cb249fab ("powerpc/64s: Add support for software count cache flush")
    Cc: stable@vger.kernel.org # v4.19+
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Michael Neuling <mikey@neuling.org>
    Reviewed-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 986f0c65674956d4d6be83835066d6aebcc0440f
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date:   Fri Mar 29 22:26:19 2019 +1100

    powerpc/fsl: Fix the flush of branch predictor.
    
    commit 27da80719ef132cf8c80eb406d5aeb37dddf78cc upstream.
    
    The commit identified below adds MC_BTB_FLUSH macro only when
    CONFIG_PPC_FSL_BOOK3E is defined. This results in the following error
    on some configs (seen several times with kisskb randconfig_defconfig)
    
    arch/powerpc/kernel/exceptions-64e.S:576: Error: Unrecognized opcode: `mc_btb_flush'
    make[3]: *** [scripts/Makefile.build:367: arch/powerpc/kernel/exceptions-64e.o] Error 1
    make[2]: *** [scripts/Makefile.build:492: arch/powerpc/kernel] Error 2
    make[1]: *** [Makefile:1043: arch/powerpc] Error 2
    make: *** [Makefile:152: sub-make] Error 2
    
    This patch adds a blank definition of MC_BTB_FLUSH for other cases.
    
    Fixes: 10c5e83afd4a ("powerpc/fsl: Flush the branch predictor at each kernel entry (64bit)")
    Cc: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Reviewed-by: Daniel Axtens <dja@axtens.net>
    Reviewed-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b848d19c483a23c2f4a3566f6367c9c61bd2ad2d
Author: Diana Craciun <diana.craciun@nxp.com>
Date:   Fri Mar 29 22:26:18 2019 +1100

    powerpc/fsl: Fixed warning: orphan section `__btb_flush_fixup'
    
    commit 039daac5526932ec731e4499613018d263af8b3e upstream.
    
    Fixed the following build warning:
    powerpc-linux-gnu-ld: warning: orphan section `__btb_flush_fixup' from
    `arch/powerpc/kernel/head_44x.o' being placed in section
    `__btb_flush_fixup'.
    
    Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 632d839296bd1ac7bc5aade75cf7db2ec0700585
Author: Diana Craciun <diana.craciun@nxp.com>
Date:   Fri Mar 29 22:26:17 2019 +1100

    powerpc/fsl: Update Spectre v2 reporting
    
    commit dfa88658fb0583abb92e062c7a9cd5a5b94f2a46 upstream.
    
    Report branch predictor state flush as a mitigation for
    Spectre variant 2.
    
    Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43f40620d7a5a4fd6565219c5001296a75ed427e
Author: Diana Craciun <diana.craciun@nxp.com>
Date:   Fri Mar 29 22:26:16 2019 +1100

    powerpc/fsl: Enable runtime patching if nospectre_v2 boot arg is used
    
    commit 3bc8ea8603ae4c1e09aca8de229ad38b8091fcb3 upstream.
    
    If the user choses not to use the mitigations, replace
    the code sequence with nops.
    
    Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a46a5038263989fff96e884c7cec2680c7a5fc6a
Author: Diana Craciun <diana.craciun@nxp.com>
Date:   Fri Mar 29 22:26:15 2019 +1100

    powerpc/fsl: Flush branch predictor when entering KVM
    
    commit e7aa61f47b23afbec41031bc47ca8d6cb6516abc upstream.
    
    Switching from the guest to host is another place
    where the speculative accesses can be exploited.
    Flush the branch predictor when entering KVM.
    
    Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cb931c709d00b1cff3ed094a62465a7bcc05dc2
Author: Diana Craciun <diana.craciun@nxp.com>
Date:   Fri Mar 29 22:26:14 2019 +1100

    powerpc/fsl: Flush the branch predictor at each kernel entry (32 bit)
    
    commit 7fef436295bf6c05effe682c8797dfcb0deb112a upstream.
    
    In order to protect against speculation attacks on
    indirect branches, the branch predictor is flushed at
    kernel entry to protect for the following situations:
    - userspace process attacking another userspace process
    - userspace process attacking the kernel
    Basically when the privillege level change (i.e.the kernel
    is entered), the branch predictor state is flushed.
    
    Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf72dad924cb98773cd21c22cc06f484fd522db9
Author: Diana Craciun <diana.craciun@nxp.com>
Date:   Fri Mar 29 22:26:13 2019 +1100

    powerpc/fsl: Flush the branch predictor at each kernel entry (64bit)
    
    commit 10c5e83afd4a3f01712d97d3bb1ae34d5b74a185 upstream.
    
    In order to protect against speculation attacks on
    indirect branches, the branch predictor is flushed at
    kernel entry to protect for the following situations:
    - userspace process attacking another userspace process
    - userspace process attacking the kernel
    Basically when the privillege level change (i.e. the
    kernel is entered), the branch predictor state is flushed.
    
    Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 020e5f13805b4a35c9394fbe55508311453fdbc8
Author: Diana Craciun <diana.craciun@nxp.com>
Date:   Fri Mar 29 22:26:12 2019 +1100

    powerpc/fsl: Add nospectre_v2 command line argument
    
    commit f633a8ad636efb5d4bba1a047d4a0f1ef719aa06 upstream.
    
    When the command line argument is present, the Spectre variant 2
    mitigations are disabled.
    
    Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a6a2287e0e61dfe9449413d09e63842e016fdcb
Author: Diana Craciun <diana.craciun@nxp.com>
Date:   Fri Mar 29 22:26:11 2019 +1100

    powerpc/fsl: Emulate SPRN_BUCSR register
    
    commit 98518c4d8728656db349f875fcbbc7c126d4c973 upstream.
    
    In order to flush the branch predictor the guest kernel performs
    writes to the BUCSR register which is hypervisor privilleged. However,
    the branch predictor is flushed at each KVM entry, so the branch
    predictor has been already flushed, so just return as soon as possible
    to guest.
    
    Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
    [mpe: Tweak comment formatting]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4944f1d48d7117e9766db8953d0855bfede939e6
Author: Diana Craciun <diana.craciun@nxp.com>
Date:   Fri Mar 29 22:26:09 2019 +1100

    powerpc/fsl: Add macro to flush the branch predictor
    
    commit 1cbf8990d79ff69da8ad09e8a3df014e1494462b upstream.
    
    The BUCSR register can be used to invalidate the entries in the
    branch prediction mechanisms.
    
    Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d67ab3d9a1b7e4dbee0db0f133611de3a22d5517
Author: Diana Craciun <diana.craciun@nxp.com>
Date:   Fri Mar 29 22:26:08 2019 +1100

    powerpc/fsl: Add infrastructure to fixup branch predictor flush
    
    commit 76a5eaa38b15dda92cd6964248c39b5a6f3a4e9d upstream.
    
    In order to protect against speculation attacks (Spectre
    variant 2) on NXP PowerPC platforms, the branch predictor
    should be flushed when the privillege level is changed.
    This patch is adding the infrastructure to fixup at runtime
    the code sections that are performing the branch predictor flush
    depending on a boot arg parameter which is added later in a
    separate patch.
    
    Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e044d21c2999d35c26cc15011e6478e2a9eaee63
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Mar 16 13:09:53 2019 -0700

    tun: add a missing rcu_read_unlock() in error path
    
    commit 9180bb4f046064dfa4541488102703b402bb04e1 upstream.
    
    In my latest patch I missed one rcu_read_unlock(), in case
    device is down.
    
    Fixes: 4477138fa0ae ("tun: properly test for IFF_UP")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bdb5fdc4787fb621676c5d7380b9351b79cd9f8
Author: Dean Nelson <dnelson@redhat.com>
Date:   Tue Mar 26 11:53:26 2019 -0400

    thunderx: eliminate extra calls to put_page() for pages held for recycling
    
    [ Upstream commit cd35ef91490ad8049dd180bb060aff7ee192eda9 ]
    
    For the non-XDP case, commit 773225388dae15e72790 ("net: thunderx: Optimize
    page recycling for XDP") added code to nicvf_free_rbdr() that, when releasing
    the additional receive buffer page reference held for recycling, repeatedly
    calls put_page() until the page's _refcount goes to zero. Which results in
    the page being freed.
    
    This is not okay if the page's _refcount was greater than 1 (in the non-XDP
    case), because nicvf_free_rbdr() should not be subtracting more than what
    nicvf_alloc_page() had previously added to the page's _refcount, which was
    only 1 (in the non-XDP case).
    
    This can arise if a received packet is still being processed and the receive
    buffer (i.e., skb->head) has not yet been freed via skb_free_head() when
    nicvf_free_rbdr() is spinning through the aforementioned put_page() loop.
    
    If this should occur, when the received packet finishes processing and
    skb_free_head() is called, various problems can ensue. Exactly what, depends on
    whether the page has already been reallocated or not, anything from "BUG: Bad
    page state ... ", to "Unable to handle kernel NULL pointer dereference ..." or
    "Unable to handle kernel paging request...".
    
    So this patch changes nicvf_free_rbdr() to only call put_page() once for pages
    held for recycling (in the non-XDP case).
    
    Fixes: 773225388dae ("net: thunderx: Optimize page recycling for XDP")
    Signed-off-by: Dean Nelson <dnelson@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac8411d759622374e6818b77d5a70671c0ed1072
Author: Dean Nelson <dnelson@redhat.com>
Date:   Tue Mar 26 11:53:19 2019 -0400

    thunderx: enable page recycling for non-XDP case
    
    [ Upstream commit b3e208069477588c06f4d5d986164b435bb06e6d ]
    
    Commit 773225388dae15e72790 ("net: thunderx: Optimize page recycling for XDP")
    added code to nicvf_alloc_page() that inadvertently disables receive buffer
    page recycling for the non-XDP case by always NULL'ng the page pointer.
    
    This patch corrects two if-conditionals to allow for the recycling of non-XDP
    mode pages by only setting the page pointer to NULL when the page is not ready
    for recycling.
    
    Fixes: 773225388dae ("net: thunderx: Optimize page recycling for XDP")
    Signed-off-by: Dean Nelson <dnelson@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a491de9041b4630401bf0c287da20fb43a15a22b
Author: John Hurley <john.hurley@netronome.com>
Date:   Fri Mar 22 12:37:35 2019 +0000

    net: sched: fix cleanup NULL pointer exception in act_mirr
    
    [ Upstream commit 064c5d6881e897077639e04973de26440ee205e6 ]
    
    A new mirred action is created by the tcf_mirred_init function. This
    contains a list head struct which is inserted into a global list on
    successful creation of a new action. However, after a creation, it is
    still possible to error out and call the tcf_idr_release function. This,
    in turn, calls the act_mirr cleanup function via __tcf_idr_release and
    __tcf_action_put. This cleanup function tries to delete the list entry
    which is as yet uninitialised, leading to a NULL pointer exception.
    
    Fix this by initialising the list entry on creation of a new action.
    
    Bug report:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
    PGD 8000000840c73067 P4D 8000000840c73067 PUD 858dcc067 PMD 0
    Oops: 0002 [#1] SMP PTI
    CPU: 32 PID: 5636 Comm: handler194 Tainted: G           OE     5.0.0+ #186
    Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.3.6 06/03/2015
    RIP: 0010:tcf_mirred_release+0x42/0xa7 [act_mirred]
    Code: f0 90 39 c0 e8 52 04 57 c8 48 c7 c7 b8 80 39 c0 e8 94 fa d4 c7 48 8b 93 d0 00 00 00 48 8b 83 d8 00 00 00 48 c7 c7 f0 90 39 c0 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 d0 00
    RSP: 0018:ffffac4aa059f688 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff9dcd1b214d00 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffff9dcd1fa165f8 RDI: ffffffffc03990f0
    RBP: ffff9dccf9c7af80 R08: 0000000000000a3b R09: 0000000000000000
    R10: ffff9dccfa11f420 R11: 0000000000000000 R12: 0000000000000001
    R13: ffff9dcd16b433c0 R14: ffff9dcd1b214d80 R15: 0000000000000000
    FS:  00007f441bfff700(0000) GS:ffff9dcd1fa00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000008 CR3: 0000000839e64004 CR4: 00000000001606e0
    Call Trace:
    tcf_action_cleanup+0x59/0xca
    __tcf_action_put+0x54/0x6b
    __tcf_idr_release.cold.33+0x9/0x12
    tcf_mirred_init.cold.20+0x22e/0x3b0 [act_mirred]
    tcf_action_init_1+0x3d0/0x4c0
    tcf_action_init+0x9c/0x130
    tcf_exts_validate+0xab/0xc0
    fl_change+0x1ca/0x982 [cls_flower]
    tc_new_tfilter+0x647/0x8d0
    ? load_balance+0x14b/0x9e0
    rtnetlink_rcv_msg+0xe3/0x370
    ? __switch_to_asm+0x40/0x70
    ? __switch_to_asm+0x34/0x70
    ? _cond_resched+0x15/0x30
    ? __kmalloc_node_track_caller+0x1d4/0x2b0
    ? rtnl_calcit.isra.31+0xf0/0xf0
    netlink_rcv_skb+0x49/0x110
    netlink_unicast+0x16f/0x210
    netlink_sendmsg+0x1df/0x390
    sock_sendmsg+0x36/0x40
    ___sys_sendmsg+0x27b/0x2c0
    ? futex_wake+0x80/0x140
    ? do_futex+0x2b9/0xac0
    ? ep_scan_ready_list.constprop.22+0x1f2/0x210
    ? ep_poll+0x7a/0x430
    __sys_sendmsg+0x47/0x80
    do_syscall_64+0x55/0x100
    entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 4e232818bd32 ("net: sched: act_mirred: remove dependency on rtnl lock")
    Signed-off-by: John Hurley <john.hurley@netronome.com>
    Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7254ad094f4a7d624d988d3095e6cb94f3e9afe6
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Mar 26 13:50:14 2019 +0800

    ila: Fix rhashtable walker list corruption
    
    [ Upstream commit b5f9bd15b88563b55a99ed588416881367a0ce5f ]
    
    ila_xlat_nl_cmd_flush uses rhashtable walkers allocated from the
    stack but it never frees them.  This corrupts the walker list of
    the hash table.
    
    This patch fixes it.
    
    Reported-by: syzbot+dae72a112334aa65a159@syzkaller.appspotmail.com
    Fixes: b6e71bdebb12 ("ila: Flush netlink command to clear xlat...")
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 979f8a675d3b8f28c80ec23c4e9406ce30464c8e
Author: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Date:   Sat Mar 16 17:02:54 2019 +0800

    vxlan: Don't call gro_cells_destroy() before device is unregistered
    
    [ Upstream commit cc4807bb609230d8959fd732b0bf3bd4c2de8eac ]
    
    Commit ad6c9986bcb62 ("vxlan: Fix GRO cells race condition between
    receive and link delete") fixed a race condition for the typical case a vxlan
    device is dismantled from the current netns. But if a netns is dismantled,
    vxlan_destroy_tunnels() is called to schedule a unregister_netdevice_queue()
    of all the vxlan tunnels that are related to this netns.
    
    In vxlan_destroy_tunnels(), gro_cells_destroy() is called and finished before
    unregister_netdevice_queue(). This means that the gro_cells_destroy() call is
    done too soon, for the same reasons explained in above commit.
    
    So we need to fully respect the RCU rules, and thus must remove the
    gro_cells_destroy() call or risk use after-free.
    
    Fixes: 58ce31cca1ff ("vxlan: GRO support at tunnel layer")
    Signed-off-by: Suanming.Mou <mousuanming@huawei.com>
    Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Reviewed-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b1386beeef4a355dcf48d5c8d0653ba39887cf6
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Tue Mar 26 18:22:16 2019 +0100

    vrf: prevent adding upper devices
    
    [ Upstream commit 1017e0987117c32783ba7c10fe2e7ff1456ba1dc ]
    
    VRF devices don't work with upper devices. Currently, it's possible to
    add a VRF device to a bridge or team, and to create macvlan, macsec, or
    ipvlan devices on top of a VRF (bond and vlan are prevented respectively
    by the lack of an ndo_set_mac_address op and the NETIF_F_VLAN_CHALLENGED
    feature flag).
    
    Fix this by setting the IFF_NO_RX_HANDLER flag (introduced in commit
    f5426250a6ec ("net: introduce IFF_NO_RX_HANDLER")).
    
    Cc: David Ahern <dsahern@gmail.com>
    Fixes: 193125dbd8eb ("net: Introduce VRF device driver")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Acked-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ea78da1aa3eb3bd0534fda9848a407b0a700fd1
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Mar 14 20:19:47 2019 -0700

    tun: properly test for IFF_UP
    
    [ Upstream commit 4477138fa0ae4e1b699786ef0600863ea6e6c61c ]
    
    Same reasons than the ones explained in commit 4179cb5a4c92
    ("vxlan: test dev->flags & IFF_UP before calling netif_rx()")
    
    netif_rx_ni() or napi_gro_frags() must be called under a strict contract.
    
    At device dismantle phase, core networking clears IFF_UP
    and flush_all_backlogs() is called after rcu grace period
    to make sure no incoming packet might be in a cpu backlog
    and still referencing the device.
    
    A similar protocol is used for gro layer.
    
    Most drivers call netif_rx() from their interrupt handler,
    and since the interrupts are disabled at device dismantle,
    netif_rx() does not have to check dev->flags & IFF_UP
    
    Virtual drivers do not have this guarantee, and must
    therefore make the check themselves.
    
    Fixes: 1bd4978a88ac ("tun: honor IFF_UP in tun_get_user()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52a7505c91a19d3a2a1047225701a57728a83875
Author: Erik Hugne <erik.hugne@gmail.com>
Date:   Thu Mar 21 09:11:59 2019 +0100

    tipc: fix cancellation of topology subscriptions
    
    [ Upstream commit 33872d79f5d1cbedaaab79669cc38f16097a9450 ]
    
    When cancelling a subscription, we have to clear the cancel bit in the
    request before iterating over any established subscriptions with memcmp.
    Otherwise no subscription will ever be found, and it will not be
    possible to explicitly unsubscribe individual subscriptions.
    
    Fixes: 8985ecc7c1e0 ("tipc: simplify endianness handling in topology subscriber")
    Signed-off-by: Erik Hugne <erik.hugne@gmail.com>
    Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1be6c0c737e402958283a0941b92c2204bb96a04
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sun Mar 24 00:48:22 2019 +0800

    tipc: change to check tipc_own_id to return in tipc_net_stop
    
    [ Upstream commit 9926cb5f8b0f0aea535735185600d74db7608550 ]
    
    When running a syz script, a panic occurred:
    
    [  156.088228] BUG: KASAN: use-after-free in tipc_disc_timeout+0x9c9/0xb20 [tipc]
    [  156.094315] Call Trace:
    [  156.094844]  <IRQ>
    [  156.095306]  dump_stack+0x7c/0xc0
    [  156.097346]  print_address_description+0x65/0x22e
    [  156.100445]  kasan_report.cold.3+0x37/0x7a
    [  156.102402]  tipc_disc_timeout+0x9c9/0xb20 [tipc]
    [  156.106517]  call_timer_fn+0x19a/0x610
    [  156.112749]  run_timer_softirq+0xb51/0x1090
    
    It was caused by the netns freed without deleting the discoverer timer,
    while later on the netns would be accessed in the timer handler.
    
    The timer should have been deleted by tipc_net_stop() when cleaning up a
    netns. However, tipc has been able to enable a bearer and start d->timer
    without the local node_addr set since Commit 52dfae5c85a4 ("tipc: obtain
    node identity from interface by default"), which caused the timer not to
    be deleted in tipc_net_stop() then.
    
    So fix it in tipc_net_stop() by changing to check local node_id instead
    of local node_addr, as Jon suggested.
    
    While at it, remove the calling of tipc_nametbl_withdraw() there, since
    tipc_nametbl_stop() will take of the nametbl's freeing after.
    
    Fixes: 52dfae5c85a4 ("tipc: obtain node identity from interface by default")
    Reported-by: syzbot+a25307ad099309f1c2b9@syzkaller.appspotmail.com
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Ying Xue <ying.xue@windriver.com>
    Acked-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24d1a6259706f03aa2057359685ef8ea77f69e38
Author: Erik Hugne <erik.hugne@gmail.com>
Date:   Sun Mar 17 18:46:42 2019 +0100

    tipc: allow service ranges to be connect()'ed on RDM/DGRAM
    
    [ Upstream commit ea239314fe42ace880bdd834256834679346c80e ]
    
    We move the check that prevents connecting service ranges to after
    the RDM/DGRAM check, and move address sanity control to a separate
    function that also validates the service range.
    
    Fixes: 23998835be98 ("tipc: improve address sanity check in tipc_connect()")
    Signed-off-by: Erik Hugne <erik.hugne@gmail.com>
    Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7115df614b09ea5baa9883b4f629a27a02237de3
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Mar 19 05:45:35 2019 -0700

    tcp: do not use ipv6 header for ipv4 flow
    
    [ Upstream commit 89e4130939a20304f4059ab72179da81f5347528 ]
    
    When a dual stack tcp listener accepts an ipv4 flow,
    it should not attempt to use an ipv6 header or tcp_v6_iif() helper.
    
    Fixes: 1397ed35f22d ("ipv6: add flowinfo for tcp6 pkt_options for all cases")
    Fixes: df3687ffc665 ("ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cab576f1b00fa3b18f1f2b56c6c094c8a6deb2d3
Author: Xin Long <lucien.xin@gmail.com>
Date:   Wed Mar 20 14:49:38 2019 +0800

    sctp: use memdup_user instead of vmemdup_user
    
    [ Upstream commit ef82bcfa671b9a635bab5fa669005663d8b177c5 ]
    
    In sctp_setsockopt_bindx()/__sctp_setsockopt_connectx(), it allocates
    memory with addrs_size which is passed from userspace. We used flag
    GFP_USER to put some more restrictions on it in Commit cacc06215271
    ("sctp: use GFP_USER for user-controlled kmalloc").
    
    However, since Commit c981f254cc82 ("sctp: use vmemdup_user() rather
    than badly open-coding memdup_user()"), vmemdup_user() has been used,
    which doesn't check GFP_USER flag when goes to vmalloc_*(). So when
    addrs_size is a huge value, it could exhaust memory and even trigger
    oom killer.
    
    This patch is to use memdup_user() instead, in which GFP_USER would
    work to limit the memory allocation with a huge addrs_size.
    
    Note we can't fix it by limiting 'addrs_size', as there's no demand
    for it from RFC.
    
    Reported-by: syzbot+ec1b7575afef85a0e5ca@syzkaller.appspotmail.com
    Fixes: c981f254cc82 ("sctp: use vmemdup_user() rather than badly open-coding memdup_user()")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97265479d7cadf5fa6597ee74371d3d21d2e8f94
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Mar 18 19:47:00 2019 +0800

    sctp: get sctphdr by offset in sctp_compute_cksum
    
    [ Upstream commit 273160ffc6b993c7c91627f5a84799c66dfe4dee ]
    
    sctp_hdr(skb) only works when skb->transport_header is set properly.
    
    But in Netfilter, skb->transport_header for ipv6 is not guaranteed
    to be right value for sctphdr. It would cause to fail to check the
    checksum for sctp packets.
    
    So fix it by using offset, which is always right in all places.
    
    v1->v2:
      - Fix the changelog.
    
    Fixes: e6d8b64b34aa ("net: sctp: fix and consolidate SCTP checksumming code")
    Reported-by: Li Shuang <shuali@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf86f7a97561fbdf18edd25da833419196504db2
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Mar 21 09:39:52 2019 +0800

    rhashtable: Still do rehash when we get EEXIST
    
    [ Upstream commit 408f13ef358aa5ad56dc6230c2c7deb92cf462b1 ]
    
    As it stands if a shrink is delayed because of an outstanding
    rehash, we will go into a rescheduling loop without ever doing
    the rehash.
    
    This patch fixes this by still carrying out the rehash and then
    rescheduling so that we can shrink after the completion of the
    rehash should it still be necessary.
    
    The return value of EEXIST captures this case and other cases
    (e.g., another thread expanded/rehashed the table at the same
    time) where we should still proceed with the rehash.
    
    Fixes: da20420f83ea ("rhashtable: Add nested tables")
    Reported-by: Josh Elsasser <jelsasser@appneta.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Tested-by: Josh Elsasser <jelsasser@appneta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69cea7cf3170a3288cf82402b6f2fed3940cc33c
Author: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date:   Sat Mar 16 14:41:30 2019 +0100

    packets: Always register packet sk in the same order
    
    [ Upstream commit a4dc6a49156b1f8d6e17251ffda17c9e6a5db78a ]
    
    When using fanouts with AF_PACKET, the demux functions such as
    fanout_demux_cpu will return an index in the fanout socket array, which
    corresponds to the selected socket.
    
    The ordering of this array depends on the order the sockets were added
    to a given fanout group, so for FANOUT_CPU this means sockets are bound
    to cpus in the order they are configured, which is OK.
    
    However, when stopping then restarting the interface these sockets are
    bound to, the sockets are reassigned to the fanout group in the reverse
    order, due to the fact that they were inserted at the head of the
    interface's AF_PACKET socket list.
    
    This means that traffic that was directed to the first socket in the
    fanout group is now directed to the last one after an interface restart.
    
    In the case of FANOUT_CPU, traffic from CPU0 will be directed to the
    socket that used to receive traffic from the last CPU after an interface
    restart.
    
    This commit introduces a helper to add a socket at the tail of a list,
    then uses it to register AF_PACKET sockets.
    
    Note that this changes the order in which sockets are listed in /proc and
    with sock_diag.
    
    Fixes: dc99f600698d ("packet: Add fanout support")
    Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9d215be3a3aa8b3638f2705826f52a7fb84cf24
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Tue Mar 19 10:16:53 2019 +0800

    net-sysfs: call dev_hold if kobject_init_and_add success
    
    [ Upstream commit a3e23f719f5c4a38ffb3d30c8d7632a4ed8ccd9e ]
    
    In netdev_queue_add_kobject and rx_queue_add_kobject,
    if sysfs_create_group failed, kobject_put will call
    netdev_queue_release to decrease dev refcont, however
    dev_hold has not be called. So we will see this while
    unregistering dev:
    
    unregister_netdevice: waiting for bcsh0 to become free. Usage count = -1
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: d0d668371679 ("net: don't decrement kobj reference count on init failure")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8dcf078d92ae81a241019df80db311d5884f8812
Author: Aaro Koskinen <aaro.koskinen@nokia.com>
Date:   Mon Mar 18 23:36:08 2019 +0200

    net: stmmac: fix memory corruption with large MTUs
    
    [ Upstream commit 223a960c01227e4dbcb6f9fa06b47d73bda21274 ]
    
    When using 16K DMA buffers and ring mode, the DES3 refill is not working
    correctly as the function is using a bogus pointer for checking the
    private data. As a result stale pointers will remain in the RX descriptor
    ring, so DMA will now likely overwrite/corrupt some already freed memory.
    
    As simple reproducer, just receive some UDP traffic:
    
            # ifconfig eth0 down; ifconfig eth0 mtu 9000; ifconfig eth0 up
            # iperf3 -c 192.168.253.40 -u -b 0 -R
    
    If you didn't crash by now check the RX descriptors to find non-contiguous
    RX buffers:
    
            cat /sys/kernel/debug/stmmaceth/eth0/descriptors_status
            [...]
            1 [0x2be5020]: 0xa3220321 0x9ffc1ffc 0x72d70082 0x130e207e
                                                 ^^^^^^^^^^^^^^^^^^^^^
            2 [0x2be5040]: 0xa3220321 0x9ffc1ffc 0x72998082 0x1311a07e
                                                 ^^^^^^^^^^^^^^^^^^^^^
    
    A simple ping test will now report bad data:
    
            # ping -s 8200 192.168.253.40
            PING 192.168.253.40 (192.168.253.40) 8200(8228) bytes of data.
            8208 bytes from 192.168.253.40: icmp_seq=1 ttl=64 time=1.00 ms
            wrong data byte #8144 should be 0xd0 but was 0x88
    
    Fix the wrong pointer. Also we must refill DES3 only if the DMA buffer
    size is 16K.
    
    Fixes: 54139cf3bb33 ("net: stmmac: adding multiple buffers for rx")
    Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
    Acked-by: Jose Abreu <joabreu@synopsys.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7eeb12edf63754c49b6e720c02d829fb0af7caf4
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Mar 15 10:41:14 2019 -0700

    net: rose: fix a possible stack overflow
    
    [ Upstream commit e5dcc0c3223c45c94100f05f28d8ef814db3d82c ]
    
    rose_write_internal() uses a temp buffer of 100 bytes, but a manual
    inspection showed that given arbitrary input, rose_create_facilities()
    can fill up to 110 bytes.
    
    Lets use a tailroom of 256 bytes for peace of mind, and remove
    the bounce buffer : we can simply allocate a big enough skb
    and adjust its length as needed.
    
    syzbot report :
    
    BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:352 [inline]
    BUG: KASAN: stack-out-of-bounds in rose_create_facilities net/rose/rose_subr.c:521 [inline]
    BUG: KASAN: stack-out-of-bounds in rose_write_internal+0x597/0x15d0 net/rose/rose_subr.c:116
    Write of size 7 at addr ffff88808b1ffbef by task syz-executor.0/24854
    
    CPU: 0 PID: 24854 Comm: syz-executor.0 Not tainted 5.0.0+ #97
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x172/0x1f0 lib/dump_stack.c:113
     print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
     kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
     check_memory_region_inline mm/kasan/generic.c:185 [inline]
     check_memory_region+0x123/0x190 mm/kasan/generic.c:191
     memcpy+0x38/0x50 mm/kasan/common.c:131
     memcpy include/linux/string.h:352 [inline]
     rose_create_facilities net/rose/rose_subr.c:521 [inline]
     rose_write_internal+0x597/0x15d0 net/rose/rose_subr.c:116
     rose_connect+0x7cb/0x1510 net/rose/af_rose.c:826
     __sys_connect+0x266/0x330 net/socket.c:1685
     __do_sys_connect net/socket.c:1696 [inline]
     __se_sys_connect net/socket.c:1693 [inline]
     __x64_sys_connect+0x73/0xb0 net/socket.c:1693
     do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x458079
    Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007f47b8d9dc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458079
    RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000004
    RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f47b8d9e6d4
    R13: 00000000004be4a4 R14: 00000000004ceca8 R15: 00000000ffffffff
    
    The buggy address belongs to the page:
    page:ffffea00022c7fc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
    flags: 0x1fffc0000000000()
    raw: 01fffc0000000000 0000000000000000 ffffffff022c0101 0000000000000000
    raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff88808b1ffa80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff88808b1ffb00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 03
    >ffff88808b1ffb80: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 04 f3
                                                                 ^
     ffff88808b1ffc00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
     ffff88808b1ffc80: 00 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 01 f2 01
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6f0168e668169768cb076ed6ecc4891855aaebd
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Thu Mar 14 14:49:45 2019 +0100

    net: phy: meson-gxl: fix interrupt support
    
    [ Upstream commit daa5c4d0167a308306525fd5ab9a5e18e21f4f74 ]
    
    If an interrupt is already pending when the interrupt is enabled on the
    GXL phy, no IRQ will ever be triggered.
    
    The fix is simply to make sure pending IRQs are cleared before setting
    up the irq mask.
    
    Fixes: cf127ff20af1 ("net: phy: meson-gxl: add interrupt support")
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85ef72d829eb85c58c92c902c9821f26639b254f
Author: Christoph Paasch <cpaasch@apple.com>
Date:   Mon Mar 18 23:14:52 2019 -0700

    net/packet: Set __GFP_NOWARN upon allocation in alloc_pg_vec
    
    [ Upstream commit 398f0132c14754fcd03c1c4f8e7176d001ce8ea1 ]
    
    Since commit fc62814d690c ("net/packet: fix 4gb buffer limit due to overflow check")
    one can now allocate packet ring buffers >= UINT_MAX. However, syzkaller
    found that that triggers a warning:
    
    [   21.100000] WARNING: CPU: 2 PID: 2075 at mm/page_alloc.c:4584 __alloc_pages_nod0
    [   21.101490] Modules linked in:
    [   21.101921] CPU: 2 PID: 2075 Comm: syz-executor.0 Not tainted 5.0.0 #146
    [   21.102784] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
    [   21.103887] RIP: 0010:__alloc_pages_nodemask+0x2a0/0x630
    [   21.104640] Code: fe ff ff 65 48 8b 04 25 c0 de 01 00 48 05 90 0f 00 00 41 bd 01 00 00 00 48 89 44 24 48 e9 9c fe 3
    [   21.107121] RSP: 0018:ffff88805e1cf920 EFLAGS: 00010246
    [   21.107819] RAX: 0000000000000000 RBX: ffffffff85a488a0 RCX: 0000000000000000
    [   21.108753] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000000000
    [   21.109699] RBP: 1ffff1100bc39f28 R08: ffffed100bcefb67 R09: ffffed100bcefb67
    [   21.110646] R10: 0000000000000001 R11: ffffed100bcefb66 R12: 000000000000000d
    [   21.111623] R13: 0000000000000000 R14: ffff88805e77d888 R15: 000000000000000d
    [   21.112552] FS:  00007f7c7de05700(0000) GS:ffff88806d100000(0000) knlGS:0000000000000000
    [   21.113612] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   21.114405] CR2: 000000000065c000 CR3: 000000005e58e006 CR4: 00000000001606e0
    [   21.115367] Call Trace:
    [   21.115705]  ? __alloc_pages_slowpath+0x21c0/0x21c0
    [   21.116362]  alloc_pages_current+0xac/0x1e0
    [   21.116923]  kmalloc_order+0x18/0x70
    [   21.117393]  kmalloc_order_trace+0x18/0x110
    [   21.117949]  packet_set_ring+0x9d5/0x1770
    [   21.118524]  ? packet_rcv_spkt+0x440/0x440
    [   21.119094]  ? lock_downgrade+0x620/0x620
    [   21.119646]  ? __might_fault+0x177/0x1b0
    [   21.120177]  packet_setsockopt+0x981/0x2940
    [   21.120753]  ? __fget+0x2fb/0x4b0
    [   21.121209]  ? packet_release+0xab0/0xab0
    [   21.121740]  ? sock_has_perm+0x1cd/0x260
    [   21.122297]  ? selinux_secmark_relabel_packet+0xd0/0xd0
    [   21.123013]  ? __fget+0x324/0x4b0
    [   21.123451]  ? selinux_netlbl_socket_setsockopt+0x101/0x320
    [   21.124186]  ? selinux_netlbl_sock_rcv_skb+0x3a0/0x3a0
    [   21.124908]  ? __lock_acquire+0x529/0x3200
    [   21.125453]  ? selinux_socket_setsockopt+0x5d/0x70
    [   21.126075]  ? __sys_setsockopt+0x131/0x210
    [   21.126533]  ? packet_release+0xab0/0xab0
    [   21.127004]  __sys_setsockopt+0x131/0x210
    [   21.127449]  ? kernel_accept+0x2f0/0x2f0
    [   21.127911]  ? ret_from_fork+0x8/0x50
    [   21.128313]  ? do_raw_spin_lock+0x11b/0x280
    [   21.128800]  __x64_sys_setsockopt+0xba/0x150
    [   21.129271]  ? lockdep_hardirqs_on+0x37f/0x560
    [   21.129769]  do_syscall_64+0x9f/0x450
    [   21.130182]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    We should allocate with __GFP_NOWARN to handle this.
    
    Cc: Kal Conley <kal.conley@dectris.com>
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Fixes: fc62814d690c ("net/packet: fix 4gb buffer limit due to overflow check")
    Signed-off-by: Christoph Paasch <cpaasch@apple.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88c64f9c7d3ffaca070c01c1564afeeaffd472f1
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Mon Mar 25 14:18:06 2019 +0100

    net: datagram: fix unbounded loop in __skb_try_recv_datagram()
    
    [ Upstream commit 0b91bce1ebfc797ff3de60c8f4a1e6219a8a3187 ]
    
    Christoph reported a stall while peeking datagram with an offset when
    busy polling is enabled. __skb_try_recv_datagram() uses as the loop
    termination condition 'queue empty'. When peeking, the socket
    queue can be not empty, even when no additional packets are received.
    
    Address the issue explicitly checking for receive queue changes,
    as currently done by __skb_wait_for_more_packets().
    
    Fixes: 2b5cd0dfa384 ("net: Change return type of sk_busy_loop from bool to void")
    Reported-and-tested-by: Christoph Paasch <cpaasch@apple.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4ff39e1ba80a2b2284e217525e9aea07aae76e2
Author: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Date:   Sat Mar 16 08:28:18 2019 +0000

    net: aquantia: fix rx checksum offload for UDP/TCP over IPv6
    
    [ Upstream commit a7faaa0c5dc7d091cc9f72b870d7edcdd6f43f12 ]
    
    TCP/UDP checksum validity was propagated to skb
    only if IP checksum is valid.
    But for IPv6 there is no validity as there is no checksum in IPv6.
    This patch propagates TCP/UDP checksum validity regardless of IP checksum.
    
    Fixes: 018423e90bee ("net: ethernet: aquantia: Add ring support code")
    Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
    Signed-off-by: Nikita Danilov <nikita.danilov@aquantia.com>
    Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c408426292eed4ce5747c994b356a42edf71a8f1
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Mon Mar 18 08:51:06 2019 -0500

    mISDN: hfcpci: Test both vendor & device ID for Digium HFC4S
    
    [ Upstream commit fae846e2b7124d4b076ef17791c73addf3b26350 ]
    
    The device ID alone does not uniquely identify a device.  Test both the
    vendor and device ID to make sure we don't mistakenly think some other
    vendor's 0xB410 device is a Digium HFC4S.  Also, instead of the bare hex
    ID, use the same constant (PCI_DEVICE_ID_DIGIUM_HFC4S) used in the device
    ID table.
    
    No functional change intended.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0f8c06f45c3e251a11e84793ab00c528e10cac6
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Sat Mar 16 14:21:19 2019 +1100

    mac8390: Fix mmio access size probe
    
    [ Upstream commit bb9e5c5bcd76f4474eac3baf643d7a39f7bac7bb ]
    
    The bug that Stan reported is as follows. After a restart, a 16-bit NIC
    may be incorrectly identified as a 32-bit NIC and stop working.
    
    mac8390 slot.E: Memory length resource not found, probing
    mac8390 slot.E: Farallon EtherMac II-C (type farallon)
    mac8390 slot.E: MAC 00:00:c5:30:c2:99, IRQ 61, 32 KB shared memory at 0xfeed0000, 32-bit access.
    
    The bug never arises after a cold start and only intermittently after a
    warm start. (I didn't investigate why the bug is intermittent.)
    
    It turns out that memcpy_toio() is deprecated and memcmp_withio() also
    has issues. Replacing these calls with mmio accessors fixes the problem.
    
    Reported-and-tested-by: Stan Johnson <userm57@yahoo.com>
    Fixes: 2964db0f5904 ("m68k: Mac DP8390 update")
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be09211384c2f4b545b4dcd2c93ab2ef3388b3f2
Author: Xin Long <lucien.xin@gmail.com>
Date:   Wed Mar 20 14:45:48 2019 +0800

    ipv6: make ip6_create_rt_rcu return ip6_null_entry instead of NULL
    
    [ Upstream commit 1c87e79a002f6a159396138cd3f3ab554a2a8887 ]
    
    Jianlin reported a crash:
    
      [  381.484332] BUG: unable to handle kernel NULL pointer dereference at 0000000000000068
      [  381.619802] RIP: 0010:fib6_rule_lookup+0xa3/0x160
      [  382.009615] Call Trace:
      [  382.020762]  <IRQ>
      [  382.030174]  ip6_route_redirect.isra.52+0xc9/0xf0
      [  382.050984]  ip6_redirect+0xb6/0xf0
      [  382.066731]  icmpv6_notify+0xca/0x190
      [  382.083185]  ndisc_redirect_rcv+0x10f/0x160
      [  382.102569]  ndisc_rcv+0xfb/0x100
      [  382.117725]  icmpv6_rcv+0x3f2/0x520
      [  382.133637]  ip6_input_finish+0xbf/0x460
      [  382.151634]  ip6_input+0x3b/0xb0
      [  382.166097]  ipv6_rcv+0x378/0x4e0
    
    It was caused by the lookup function __ip6_route_redirect() returns NULL in
    fib6_rule_lookup() when ip6_create_rt_rcu() returns NULL.
    
    So we fix it by simply making ip6_create_rt_rcu() return ip6_null_entry
    instead of NULL.
    
    v1->v2:
      - move down 'fallback:' to make it more readable.
    
    Fixes: e873e4b9cc7e ("ipv6: use fib6_info_hold_safe() when necessary")
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Suggested-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Reviewed-by: David Ahern <dsahern@gmail.com>
    Acked-by: Wei Wang <weiwan@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53adaacbbadb6dda96196b91a21e871968694734
Author: Matteo Croce <mcroce@redhat.com>
Date:   Sat Mar 16 01:00:50 2019 +0100

    gtp: change NET_UDP_TUNNEL dependency to select
    
    [ Upstream commit c22da36688d6298f2e546dcc43fdc1ad35036467 ]
    
    Similarly to commit a7603ac1fc8c ("geneve: change NET_UDP_TUNNEL
    dependency to select"), GTP has a dependency on NET_UDP_TUNNEL which
    makes impossible to compile it if no other protocol depending on
    NET_UDP_TUNNEL is selected.
    
    Fix this by changing the depends to a select, and drop NET_IP_TUNNEL from
    the select list, as it already depends on NET_UDP_TUNNEL.
    
    Signed-off-by: Matteo Croce <mcroce@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b8ef421b481d6e648438131d867986c649c297c
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Thu Mar 21 15:02:50 2019 +0800

    genetlink: Fix a memory leak on error path
    
    [ Upstream commit ceabee6c59943bdd5e1da1a6a20dc7ee5f8113a2 ]
    
    In genl_register_family(), when idr_alloc() fails,
    we forget to free the memory we possibly allocate for
    family->attrbuf.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 2ae0f17df1cd ("genetlink: use idr to track families")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Kirill Tkhai <ktkhai@virtuozzo.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 321461f2497fbb07b77edd2c184cfa624573b96a
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Mar 19 05:46:18 2019 -0700

    dccp: do not use ipv6 header for ipv4 flow
    
    [ Upstream commit e0aa67709f89d08c8d8e5bdd9e0b649df61d0090 ]
    
    When a dual stack dccp listener accepts an ipv4 flow,
    it should not attempt to use an ipv6 header or
    inet6_iif() helper.
    
    Fixes: 3df80d9320bc ("[DCCP]: Introduce DCCPv6")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bba17f6bce39e46fdf8c0fe190bdc3f57ef8f8f
Author: Corey Minyard <cminyard@mvista.com>
Date:   Tue Mar 26 11:10:04 2019 -0500

    ipmi_si: Fix crash when using hard-coded device
    
    Backport from 41b766d661bf94a364960862cfc248a78313dbd3
    
    When excuting a command like:
      modprobe ipmi_si ports=0xffc0e3 type=bt
    The system would get an oops.
    
    The trouble here is that ipmi_si_hardcode_find_bmc() is called before
    ipmi_si_platform_init(), but initialization of the hard-coded device
    creates an IPMI platform device, which won't be initialized yet.
    
    The real trouble is that hard-coded devices aren't created with
    any device, and the fixup is done later.  So do it right, create the
    hard-coded devices as normal platform devices.
    
    This required adding some new resource types to the IPMI platform
    code for passing information required by the hard-coded device
    and adding some code to remove the hard-coded platform devices
    on module removal.
    
    To enforce the "hard-coded devices passed by the user take priority
    over firmware devices" rule, some special code was added to check
    and see if a hard-coded device already exists.
    
    The backport required some minor fixups and adding the device
    id table that had been added in another change and was used
    in this one.
    
    Reported-by: Yang Yingliang <yangyingliang@huawei.com>
    Cc: stable@vger.kernel.org # v4.15+
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Tested-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15d6538a0d6e0f6de5116081a948cba7cc3e1d3d
Author: Marcel Holtmann <marcel@holtmann.org>
Date:   Fri Jan 18 13:43:19 2019 +0100

    Bluetooth: Verify that l2cap_get_conf_opt provides large enough buffer
    
    commit 7c9cbd0b5e38a1672fcd137894ace3b042dfbf69 upstream.
    
    The function l2cap_get_conf_opt will return L2CAP_CONF_OPT_SIZE + opt->len
    as length value. The opt->len however is in control over the remote user
    and can be used by an attacker to gain access beyond the bounds of the
    actual packet.
    
    To prevent any potential leak of heap memory, it is enough to check that
    the resulting len calculation after calling l2cap_get_conf_opt is not
    below zero. A well formed packet will always return >= 0 here and will
    end with the length value being zero after the last option has been
    parsed. In case of malformed packets messing with the opt->len field the
    length value will become negative. If that is the case, then just abort
    and ignore the option.
    
    In case an attacker uses a too short opt->len value, then garbage will
    be parsed, but that is protected by the unknown option handling and also
    the option parameter size checks.
    
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2318c0e4b87e590c9d8e88db185477cfac18abe2
Author: Marcel Holtmann <marcel@holtmann.org>
Date:   Fri Jan 18 12:56:20 2019 +0100

    Bluetooth: Check L2CAP option sizes returned from l2cap_get_conf_opt
    
    commit af3d5d1c87664a4f150fcf3534c6567cb19909b0 upstream.
    
    When doing option parsing for standard type values of 1, 2 or 4 octets,
    the value is converted directly into a variable instead of a pointer. To
    avoid being tricked into being a pointer, check that for these option
    types that sizes actually match. In L2CAP every option is fixed size and
    thus it is prudent anyway to ensure that the remote side sends us the
    right option size along with option paramters.
    
    If the option size is not matching the option type, then that option is
    silently ignored. It is a protocol violation and instead of trying to
    give the remote attacker any further hints just pretend that option is
    not present and proceed with the default values. Implementation
    following the specification and its qualification procedures will always
    use the correct size and thus not being impacted here.
    
    To keep the code readable and consistent accross all options, a few
    cosmetic changes were also required.
    
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>