commit bb263a2a2d4380a56edab6dce5a2c064769676fb
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jun 19 08:21:00 2019 +0200

    Linux 4.14.128

commit 3177ab541ba8b875d0cdb85e9813f5402e59714d
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Wed Dec 5 17:00:09 2018 +0200

    rtc: pcf8523: don't return invalid date when battery is low
    
    commit ecb4a353d3afd45b9bb30c85d03ee113a0589079 upstream.
    
    The RTC_VL_READ ioctl reports the low battery condition. Still,
    pcf8523_rtc_read_time() happily returns invalid dates in this case.
    Check the battery health on pcf8523_rtc_read_time() to avoid that.
    
    Reported-by: Erik ÄŒuk <erik.cuk@domel.com>
    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 488beeebddaf563aed96c27aa78c520a00f1a30f
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date:   Fri Jun 14 17:31:49 2019 +0300

    x86/kasan: Fix boot with 5-level paging and KASAN
    
    commit f3176ec9420de0c385023afa3e4970129444ac2f upstream.
    
    Since commit d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on
    5-level paging") kernel doesn't boot with KASAN on 5-level paging machines.
    The bug is actually in early_p4d_offset() and introduced by commit
    12a8cc7fcf54 ("x86/kasan: Use the same shadow offset for 4- and 5-level paging")
    
    early_p4d_offset() tries to convert pgd_val(*pgd) value to a physical
    address. This doesn't make sense because pgd_val() already contains the
    physical address.
    
    It did work prior to commit d52888aa2753 because the result of
    "__pa_nodebug(pgd_val(*pgd)) & PTE_PFN_MASK" was the same as "pgd_val(*pgd)
    & PTE_PFN_MASK". __pa_nodebug() just set some high bits which were masked
    out by applying PTE_PFN_MASK.
    
    After the change of the PAGE_OFFSET offset in commit d52888aa2753
    __pa_nodebug(pgd_val(*pgd)) started to return a value with more high bits
    set and PTE_PFN_MASK wasn't enough to mask out all of them. So it returns a
    wrong not even canonical address and crashes on the attempt to dereference
    it.
    
    Switch back to pgd_val() & PTE_PFN_MASK to cure the issue.
    
    Fixes: 12a8cc7fcf54 ("x86/kasan: Use the same shadow offset for 4- and 5-level paging")
    Reported-by: Kirill A. Shutemov <kirill@shutemov.name>
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: kasan-dev@googlegroups.com
    Cc: stable@vger.kernel.org
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20190614143149.2227-1-aryabinin@virtuozzo.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e7018426849aebaddbd48fe5d16727ead98f711
Author: Borislav Petkov <bp@suse.de>
Date:   Thu Jun 13 15:49:02 2019 +0200

    x86/microcode, cpuhotplug: Add a microcode loader CPU hotplug callback
    
    commit 78f4e932f7760d965fb1569025d1576ab77557c5 upstream.
    
    Adric Blake reported the following warning during suspend-resume:
    
      Enabling non-boot CPUs ...
      x86: Booting SMP configuration:
      smpboot: Booting Node 0 Processor 1 APIC 0x2
      unchecked MSR access error: WRMSR to 0x10f (tried to write 0x0000000000000000) \
       at rIP: 0xffffffff8d267924 (native_write_msr+0x4/0x20)
      Call Trace:
       intel_set_tfa
       intel_pmu_cpu_starting
       ? x86_pmu_dead_cpu
       x86_pmu_starting_cpu
       cpuhp_invoke_callback
       ? _raw_spin_lock_irqsave
       notify_cpu_starting
       start_secondary
       secondary_startup_64
      microcode: sig=0x806ea, pf=0x80, revision=0x96
      microcode: updated to revision 0xb4, date = 2019-04-01
      CPU1 is up
    
    The MSR in question is MSR_TFA_RTM_FORCE_ABORT and that MSR is emulated
    by microcode. The log above shows that the microcode loader callback
    happens after the PMU restoration, leading to the conjecture that
    because the microcode hasn't been updated yet, that MSR is not present
    yet, leading to the #GP.
    
    Add a microcode loader-specific hotplug vector which comes before
    the PERF vectors and thus executes earlier and makes sure the MSR is
    present.
    
    Fixes: 400816f60c54 ("perf/x86/intel: Implement support for TSX Force Abort")
    Reported-by: Adric Blake <promarbler14@gmail.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: <stable@vger.kernel.org>
    Cc: x86@kernel.org
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=203637
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2da7d3ba367aecc0beeafd0a609393607a7f791e
Author: Borislav Petkov <bp@suse.de>
Date:   Sat Apr 20 13:27:51 2019 +0200

    RAS/CEC: Fix binary search function
    
    commit f3c74b38a55aefe1004200d15a83f109b510068c upstream.
    
    Switch to using Donald Knuth's binary search algorithm (The Art of
    Computer Programming, vol. 3, section 6.2.1). This should've been done
    from the very beginning but the author must've been smoking something
    very potent at the time.
    
    The problem with the current one was that it would return the wrong
    element index in certain situations:
    
      https://lkml.kernel.org/r/CAM_iQpVd02zkVJ846cj-Fg1yUNuz6tY5q1Vpj4LrXmE06dPYYg@mail.gmail.com
    
    and the noodling code after the loop was fishy at best.
    
    So switch to using Knuth's binary search. The final result is much
    cleaner and straightforward.
    
    Fixes: 011d82611172 ("RAS: Add a Corrected Errors Collector")
    Reported-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: linux-edac <linux-edac@vger.kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2d2622b4832f69ed08ca2fe103ea0fa205510f2
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Wed May 15 17:27:49 2019 +0200

    USB: serial: option: add Telit 0x1260 and 0x1261 compositions
    
    commit f3dfd4072c3ee6e287f501a18b5718b185d6a940 upstream.
    
    Added support for Telit LE910Cx 0x1260 and 0x1261 compositions.
    
    Signed-off-by: Daniele Palmas <dnlplm@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 299d2cceded4061cac61c6383fc0e68a32a440d4
Author: Jörgen Storvist <jorgen.storvist@gmail.com>
Date:   Mon May 13 18:37:52 2019 +0200

    USB: serial: option: add support for Simcom SIM7500/SIM7600 RNDIS mode
    
    commit 5417a7e482962952e622eabd60cd3600dd65dedf upstream.
    
    Added IDs for Simcom SIM7500/SIM7600 series cellular module in RNDIS
    mode. Reserved the interface for ADB.
    
    T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1e0e ProdID=9011 Rev=03.18
    S:  Manufacturer=SimTech, Incorporated
    S:  Product=SimTech, Incorporated
    S:  SerialNumber=0123456789ABCDEF
    C:  #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=ff Driver=rndis_host
    I:  If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    I:  If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#=0x7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    
    Signed-off-by: Jörgen Storvist <jorgen.storvist@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 0089afc2f14a630eff65cab7c4a3d523c0d6fac7
Author: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date:   Tue May 14 17:35:42 2019 +1200

    USB: serial: pl2303: add Allied Telesis VT-Kit3
    
    commit c5f81656a18b271976a86724dadd8344e54de74e upstream.
    
    This is adds the vendor and device id for the AT-VT-Kit3 which is a
    pl2303-based device.
    
    Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95eee1e1f309626b7915fb79e57364ff6e320123
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Tue Jun 4 00:20:49 2019 +0800

    USB: usb-storage: Add new ID to ums-realtek
    
    commit 1a6dd3fea131276a4fc44ae77b0f471b0b473577 upstream.
    
    There is one more Realtek card reader requires ums-realtek to work
    correctly.
    
    Add the device ID to support it.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2247085710a21e328f8e94698526b0aafb5ae3fe
Author: Marco Zatta <marco@zatta.me>
Date:   Sat Jun 1 09:52:57 2019 +0200

    USB: Fix chipmunk-like voice when using Logitech C270 for recording audio.
    
    commit bd21f0222adab64974b7d1b4b8c7ce6b23e9ea4d upstream.
    
    This patch fixes the chipmunk-like voice that manifets randomly when
    using the integrated mic of the Logitech Webcam HD C270.
    
    The issue was solved initially for this device by commit 2394d67e446b
    ("USB: add RESET_RESUME for webcams shown to be quirky") but it was then
    reintroduced by e387ef5c47dd ("usb: Add USB_QUIRK_RESET_RESUME for all
    Logitech UVC webcams"). This patch is to have the fix back.
    
    Signed-off-by: Marco Zatta <marco@zatta.me>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cff44f3c4245c8b3f874dad2b6ad21315809624b
Author: Douglas Anderson <dianders@chromium.org>
Date:   Fri May 31 13:04:12 2019 -0700

    usb: dwc2: host: Fix wMaxPacketSize handling (fix webcam regression)
    
    commit babd183915e91a64e976b9e8ab682bb56624df76 upstream.
    
    In commit abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return
    only packet size") the API to usb_endpoint_maxp() changed.  It used to
    just return wMaxPacketSize but after that commit it returned
    wMaxPacketSize with the high bits (the multiplier) masked off.  If you
    wanted to get the multiplier it was now up to your code to call the
    new usb_endpoint_maxp_mult() which was introduced in
    commit 541b6fe63023 ("usb: add helper to extract bits 12:11 of
    wMaxPacketSize").
    
    Prior to the API change most host drivers were updated, but no update
    was made to dwc2.  Presumably it was assumed that dwc2 was too
    simplistic to use the multiplier and thus just didn't support a
    certain class of USB devices.  However, it turns out that dwc2 did use
    the multiplier and many devices using it were working quite nicely.
    That means that many USB devices have been broken since the API
    change.  One such device is a Logitech HD Pro Webcam C920.
    
    Specifically, though dwc2 didn't directly call usb_endpoint_maxp(), it
    did call usb_maxpacket() which in turn called usb_endpoint_maxp().
    
    Let's update dwc2 to work properly with the new API.
    
    Fixes: abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return only packet size")
    Cc: stable@vger.kernel.org
    Acked-by: Minas Harutyunyan <hminas@synopsys.com>
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc0368db8c746aa95eefc0f7f54d5eabe6c7835c
Author: Martin Schiller <ms@dev.tdt.de>
Date:   Mon Feb 18 07:37:30 2019 +0100

    usb: dwc2: Fix DMA cache alignment issues
    
    commit 4a4863bf2e7932e584a3a462d3c6daf891142ddc upstream.
    
    Insert a padding between data and the stored_xfer_buffer pointer to
    ensure they are not on the same cache line.
    
    Otherwise, the stored_xfer_buffer gets corrupted for IN URBs on
    non-cache-coherent systems. (In my case: Lantiq xRX200 MIPS)
    
    Fixes: 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more supported way")
    Fixes: 56406e017a88 ("usb: dwc2: Fix DMA alignment to start at allocated boundary")
    Cc: <stable@vger.kernel.org>
    Tested-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Acked-by: Minas Harutyunyan <hminas@synopsys.com>
    Signed-off-by: Martin Schiller <ms@dev.tdt.de>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 095b1decb5d929876c236ef5fe0c2eb40748731f
Author: Murray McAllister <murray.mcallister@gmail.com>
Date:   Sat May 11 18:01:37 2019 +1200

    drm/vmwgfx: NULL pointer dereference from vmw_cmd_dx_view_define()
    
    commit bcd6aa7b6cbfd6f985f606c6f76046d782905820 upstream.
    
    If SVGA_3D_CMD_DX_DEFINE_RENDERTARGET_VIEW is called with a surface
    ID of SVGA3D_INVALID_ID, the srf struct will remain NULL after
    vmw_cmd_res_check(), leading to a null pointer dereference in
    vmw_view_add().
    
    Cc: <stable@vger.kernel.org>
    Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
    Signed-off-by: Murray McAllister <murray.mcallister@gmail.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 956916b54207ba46d4b921facbdf5728f064a653
Author: Murray McAllister <murray.mcallister@gmail.com>
Date:   Mon May 20 21:57:34 2019 +1200

    drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading to an invalid read
    
    commit 5ed7f4b5eca11c3c69e7c8b53e4321812bc1ee1e upstream.
    
    If SVGA_3D_CMD_DX_SET_SHADER is called with a shader ID
    of SVGA3D_INVALID_ID, and a shader type of
    SVGA3D_SHADERTYPE_INVALID, the calculated binding.shader_slot
    will be 4294967295, leading to an out-of-bounds read in vmw_binding_loc()
    when the offset is calculated.
    
    Cc: <stable@vger.kernel.org>
    Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
    Signed-off-by: Murray McAllister <murray.mcallister@gmail.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4739012890395a463e6a7439d552367704baefbf
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Fri May 24 16:06:23 2019 +0200

    KVM: s390: fix memory slot handling for KVM_SET_USER_MEMORY_REGION
    
    [ Upstream commit 19ec166c3f39fe1d3789888a74cc95544ac266d4 ]
    
    kselftests exposed a problem in the s390 handling for memory slots.
    Right now we only do proper memory slot handling for creation of new
    memory slots. Neither MOVE, nor DELETION are handled properly. Let us
    implement those.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 891bd1a93eeecc0faa34b5928676b6db4daecf61
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Mon May 20 17:34:30 2019 +0200

    KVM: x86/pmu: do not mask the value that is written to fixed PMUs
    
    [ Upstream commit 2924b52117b2812e9633d5ea337333299166d373 ]
    
    According to the SDM, for MSR_IA32_PERFCTR0/1 "the lower-order 32 bits of
    each MSR may be written with any value, and the high-order 8 bits are
    sign-extended according to the value of bit 31", but the fixed counters
    in real hardware are limited to the width of the fixed counters ("bits
    beyond the width of the fixed-function counter are reserved and must be
    written as zeros").  Fix KVM to do the same.
    
    Reported-by: Nadav Amit <nadav.amit@gmail.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba1cf86bdf0a1ca25438817353c8b80f3de056a6
Author: Bernd Eckstein <3erndeckstein@gmail.com>
Date:   Mon May 20 17:31:09 2019 +0200

    usbnet: ipheth: fix racing condition
    
    [ Upstream commit 94d250fae48e6f873d8362308f5c4d02cd1b1fd2 ]
    
    Fix a racing condition in ipheth.c that can lead to slow performance.
    
    Bug: In ipheth_tx(), netif_wake_queue() may be called on the callback
    ipheth_sndbulk_callback(), _before_ netif_stop_queue() is called.
    When this happens, the queue is stopped longer than it needs to be,
    thus reducing network performance.
    
    Fix: Move netif_stop_queue() in front of usb_submit_urb(). Now the order
    is always correct. In case, usb_submit_urb() fails, the queue is woken up
    again as callback will not fire.
    
    Testing: This racing condition is usually not noticeable, as it has to
    occur very frequently to slowdown the network. The callback from the USB
    is usually triggered slow enough, so the situation does not appear.
    However, on a Ubuntu Linux on VMWare Workstation, running on Windows 10,
    the we loose the race quite often and the following speedup can be noticed:
    
    Without this patch: Download:  4.10 Mbit/s, Upload:  4.01 Mbit/s
    With this patch:    Download: 36.23 Mbit/s, Upload: 17.61 Mbit/s
    
    Signed-off-by: Oliver Zweigle <Oliver.Zweigle@faro.com>
    Signed-off-by: Bernd Eckstein <3ernd.Eckstein@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 881758675907d24777742a39c74f1b221b5f0e62
Author: Kees Cook <keescook@chromium.org>
Date:   Mon May 20 15:37:49 2019 -0700

    selftests/timers: Add missing fflush(stdout) calls
    
    [ Upstream commit fe48319243a626c860fd666ca032daacc2ba84a5 ]
    
    When running under a pipe, some timer tests would not report output in
    real-time because stdout flushes were missing after printf()s that lacked
    a newline. This adds them to restore real-time status output that humans
    can enjoy.
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69bb52fdeb7fe962822b89eabdc6a42beaeceb53
Author: Qian Cai <cai@lca.pw>
Date:   Thu May 16 12:04:53 2019 -0400

    libnvdimm: Fix compilation warnings with W=1
    
    [ Upstream commit c01dafad77fea8d64c4fdca0a6031c980842ad65 ]
    
    Several places (dimm_devs.c, core.c etc) include label.h but only
    label.c uses NSINDEX_SIGNATURE, so move its definition to label.c
    instead.
    
    In file included from drivers/nvdimm/dimm_devs.c:23:
    drivers/nvdimm/label.h:41:19: warning: 'NSINDEX_SIGNATURE' defined but
    not used [-Wunused-const-variable=]
    
    Also, some places abuse "/**" which is only reserved for the kernel-doc.
    
    drivers/nvdimm/bus.c:648: warning: cannot understand function prototype:
    'struct attribute_group nd_device_attribute_group = '
    drivers/nvdimm/bus.c:677: warning: cannot understand function prototype:
    'struct attribute_group nd_numa_attribute_group = '
    
    Those are just some member assignments for the "struct attribute_group"
    instances and it can't be expressed in the kernel-doc.
    
    Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
    Signed-off-by: Qian Cai <cai@lca.pw>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4291e45df5cc06ff47a3124cd2857a6513174dd6
Author: Colin Ian King <colin.king@canonical.com>
Date:   Sat May 4 17:48:29 2019 +0100

    scsi: bnx2fc: fix incorrect cast to u64 on shift operation
    
    [ Upstream commit d0c0d902339249c75da85fd9257a86cbb98dfaa5 ]
    
    Currently an int is being shifted and the result is being cast to a u64
    which leads to undefined behaviour if the shift is more than 31 bits. Fix
    this by casting the integer value 1 to u64 before the shift operation.
    
    Addresses-Coverity: ("Bad shift operation")
    Fixes: 7b594769120b ("[SCSI] bnx2fc: Handle REC_TOV error code from firmware")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Acked-by: Saurav Kashyap <skashyap@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a415e2db35b90200b1990cd2c4024c13859ccd14
Author: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com>
Date:   Thu May 2 15:03:51 2019 +0200

    platform/x86: pmc_atom: Add several Beckhoff Automation boards to critclk_systems DMI table
    
    [ Upstream commit d6423bd03031c020121da26c41a26bd5cc6d0da3 ]
    
    There are several Beckhoff Automation industrial PC boards which use
    pmc_plt_clk* clocks for ethernet controllers. This adds affected boards
    to critclk_systems DMI table so the clocks are marked as CLK_CRITICAL and
    not turned off.
    
    Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
    Signed-off-by: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e2ec4a3701475bbb35c08ea5e262330ce04d019
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Apr 29 17:01:35 2019 +0200

    platform/x86: pmc_atom: Add Lex 3I380D industrial PC to critclk_systems DMI table
    
    [ Upstream commit 3d0818f5eba80fbe4c0addbfe6ddb2d19dc82cd4 ]
    
    The Lex 3I380D industrial PC has 4 ethernet controllers on board
    which need pmc_plt_clk0 - 3 to function, add it to the critclk_systems
    DMI table, so that drivers/clk/x86/clk-pmc-atom.c will mark the clocks
    as CLK_CRITICAL and they will not get turned off.
    
    Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
    Reported-and-tested-by: Semyon Verchenko <semverchenko@factor-ts.ru>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c8371539ba03335716c40589c281672fac78b4b
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri May 17 02:47:34 2019 -0700

    nvme: remove the ifdef around nvme_nvm_ioctl
    
    [ Upstream commit 3f98bcc58cd5f1e4668db289dcab771874cc0920 ]
    
    We already have a proper stub if lightnvm is not enabled, so don't bother
    with the ifdef.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Keith Busch <keith.busch@intel.com>
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c96833fa18a8e82eca84b2f2d1b29fa31d80dc44
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue May 14 14:30:06 2019 +0530

    arm64/mm: Inhibit huge-vmap with ptdump
    
    [ Upstream commit 7ba36eccb3f83983a651efd570b4f933ecad1b5c ]
    
    The arm64 ptdump code can race with concurrent modification of the
    kernel page tables. At the time this was added, this was sound as:
    
    * Modifications to leaf entries could result in stale information being
      logged, but would not result in a functional problem.
    
    * Boot time modifications to non-leaf entries (e.g. freeing of initmem)
      were performed when the ptdump code cannot be invoked.
    
    * At runtime, modifications to non-leaf entries only occurred in the
      vmalloc region, and these were strictly additive, as intermediate
      entries were never freed.
    
    However, since commit:
    
      commit 324420bf91f6 ("arm64: add support for ioremap() block mappings")
    
    ... it has been possible to create huge mappings in the vmalloc area at
    runtime, and as part of this existing intermediate levels of table my be
    removed and freed.
    
    It's possible for the ptdump code to race with this, and continue to
    walk tables which have been freed (and potentially poisoned or
    reallocated). As a result of this, the ptdump code may dereference bogus
    addresses, which could be fatal.
    
    Since huge-vmap is a TLB and memory optimization, we can disable it when
    the runtime ptdump code is in use to avoid this problem.
    
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Fixes: 324420bf91f60582 ("arm64: add support for ioremap() block mappings")
    Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9bc0178fd99bc798a32753649568d89ff022f8db
Author: James Smart <jsmart2021@gmail.com>
Date:   Mon May 6 17:26:49 2019 -0700

    scsi: lpfc: add check for loss of ndlp when sending RRQ
    
    [ Upstream commit c8cb261a072c88ca1aff0e804a30db4c7606521b ]
    
    There was a missing qualification of a valid ndlp structure when calling to
    send an RRQ for an abort.  Add the check.
    
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Tested-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aaca4fd7e8efad7ab453625e349845f853368fd3
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed Apr 24 16:02:56 2019 +0800

    scsi: qedi: remove set but not used variables 'cdev' and 'udev'
    
    [ Upstream commit d0adee5d12752256ff0c87ad7f002f21fe49d618 ]
    
    Fixes gcc '-Wunused-but-set-variable' warning:
    
    drivers/scsi/qedi/qedi_iscsi.c: In function 'qedi_ep_connect':
    drivers/scsi/qedi/qedi_iscsi.c:813:23: warning: variable 'udev' set but not used [-Wunused-but-set-variable]
    drivers/scsi/qedi/qedi_iscsi.c:812:18: warning: variable 'cdev' set but not used [-Wunused-but-set-variable]
    
    These have never been used since introduction.
    
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Acked-by: Manish Rangankar <mrangankar@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af1630c6dc4fd96c09fef088f9c400c35e259e72
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Sat Apr 20 12:05:54 2019 +0800

    scsi: qedi: remove memset/memcpy to nfunc and use func instead
    
    [ Upstream commit c09581a52765a85f19fc35340127396d5e3379cc ]
    
    KASAN reports this:
    
    BUG: KASAN: global-out-of-bounds in qedi_dbg_err+0xda/0x330 [qedi]
    Read of size 31 at addr ffffffffc12b0ae0 by task syz-executor.0/2429
    
    CPU: 0 PID: 2429 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0xfa/0x1ce lib/dump_stack.c:113
     print_address_description+0x1c4/0x270 mm/kasan/report.c:187
     kasan_report+0x149/0x18d mm/kasan/report.c:317
     memcpy+0x1f/0x50 mm/kasan/common.c:130
     qedi_dbg_err+0xda/0x330 [qedi]
     ? 0xffffffffc12d0000
     qedi_init+0x118/0x1000 [qedi]
     ? 0xffffffffc12d0000
     ? 0xffffffffc12d0000
     ? 0xffffffffc12d0000
     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:00007f2d57e55c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
    RAX: ffffffffffffffda RBX: 000000000073bfa0 RCX: 0000000000462e99
    RDX: 0000000000000000 RSI: 00000000200003c0 RDI: 0000000000000003
    RBP: 00007f2d57e55c70 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2d57e566bc
    R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004
    
    The buggy address belongs to the variable:
     __func__.67584+0x0/0xffffffffffffd520 [qedi]
    
    Memory state around the buggy address:
     ffffffffc12b0980: fa fa fa fa 00 04 fa fa fa fa fa fa 00 00 05 fa
     ffffffffc12b0a00: fa fa fa fa 00 00 04 fa fa fa fa fa 00 05 fa fa
    > ffffffffc12b0a80: fa fa fa fa 00 06 fa fa fa fa fa fa 00 02 fa fa
                                                              ^
     ffffffffc12b0b00: fa fa fa fa 00 00 04 fa fa fa fa fa 00 00 03 fa
     ffffffffc12b0b80: fa fa fa fa 00 00 02 fa fa fa fa fa 00 00 04 fa
    
    Currently the qedi_dbg_* family of functions can overrun the end of the
    source string if it is less than the destination buffer length because of
    the use of a fixed sized memcpy. Remove the memset/memcpy calls to nfunc
    and just use func instead as it is always a null terminated string.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6c7e6460d7f5e0147a7253b8edd62217d3b48e3
Author: Young Xiao <YangX92@hotmail.com>
Date:   Fri Apr 12 15:45:06 2019 +0800

    Drivers: misc: fix out-of-bounds access in function param_set_kgdbts_var
    
    [ Upstream commit b281218ad4311a0342a40cb02fb17a363df08b48 ]
    
    There is an out-of-bounds access to "config[len - 1]" array when the
    variable "len" is zero.
    
    See commit dada6a43b040 ("kgdboc: fix KASAN global-out-of-bounds bug
    in param_set_kgdboc_var()") for details.
    
    Signed-off-by: Young Xiao <YangX92@hotmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80afb5209b59a032fac66c9d1cd3d8d87794e3cd
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Tue Apr 23 15:36:36 2019 +0200

    s390/kasan: fix strncpy_from_user kasan checks
    
    [ Upstream commit 01eb42afb45719cb41bb32c278e068073738899d ]
    
    arch/s390/lib/uaccess.c is built without kasan instrumentation. Kasan
    checks are performed explicitly in copy_from_user/copy_to_user
    functions. But since those functions could be inlined, calls from
    files like uaccess.c with instrumentation disabled won't generate
    kasan reports. This is currently the case with strncpy_from_user
    function which was revealed by newly added kasan test. Avoid inlining of
    copy_from_user/copy_to_user when the kernel is built with kasan support
    to make sure kasan checks are fully functional.
    
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41cb8f4b5b9b14d199e6cab2a2a7ad8dde7499d1
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Apr 11 19:58:32 2019 +0200

    Revert "ALSA: seq: Protect in-kernel ioctl calls with mutex"
    
    [ Upstream commit f0654ba94e33699b295ce4f3dc73094db6209035 ]
    
    This reverts commit feb689025fbb6f0aa6297d3ddf97de945ea4ad32.
    
    The fix attempt was incorrect, leading to the mutex deadlock through
    the close of OSS sequencer client.  The proper fix needs more
    consideration, so let's revert it now.
    
    Fixes: feb689025fbb ("ALSA: seq: Protect in-kernel ioctl calls with mutex")
    Reported-by: syzbot+47ded6c0f23016cde310@syzkaller.appspotmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c862c7805972fb4dd7b9aef06366f866f94ac0b5
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Apr 9 18:04:17 2019 +0200

    ALSA: seq: Fix race of get-subscription call vs port-delete ioctls
    
    [ Upstream commit 2eabc5ec8ab4d4748a82050dfcb994119b983750 ]
    
    The snd_seq_ioctl_get_subscription() retrieves the port subscriber
    information as a pointer, while the object isn't protected, hence it
    may be deleted before the actual reference.  This race was spotted by
    syzkaller and may lead to a UAF.
    
    The fix is simply copying the data in the lookup function that
    performs in the rwsem to protect against the deletion.
    
    Reported-by: syzbot+9437020c82413d00222d@syzkaller.appspotmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37626d9fbf0b5ecf4a8fb5a96a1e47afe82ba8e7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Apr 9 17:35:22 2019 +0200

    ALSA: seq: Protect in-kernel ioctl calls with mutex
    
    [ Upstream commit feb689025fbb6f0aa6297d3ddf97de945ea4ad32 ]
    
    ALSA OSS sequencer calls the ioctl function indirectly via
    snd_seq_kernel_client_ctl().  While we already applied the protection
    against races between the normal ioctls and writes via the client's
    ioctl_mutex, this code path was left untouched.  And this seems to be
    the cause of still remaining some rare UAF as spontaneously triggered
    by syzkaller.
    
    For the sake of robustness, wrap the ioctl_mutex also for the call via
    snd_seq_kernel_client_ctl(), too.
    
    Reported-by: syzbot+e4c8abb920efa77bace9@syzkaller.appspotmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f6f2ee1d75c48c7e30f7771cfb2e4bdc2f30f44
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Mar 7 19:54:25 2019 +0100

    x86/uaccess, kcov: Disable stack protector
    
    [ Upstream commit 40ea97290b08be2e038b31cbb33097d1145e8169 ]
    
    New tooling noticed this mishap:
    
      kernel/kcov.o: warning: objtool: write_comp_data()+0x138: call to __stack_chk_fail() with UACCESS enabled
      kernel/kcov.o: warning: objtool: __sanitizer_cov_trace_pc()+0xd9: call to __stack_chk_fail() with UACCESS enabled
    
    All the other instrumentation (KASAN,UBSAN) also have stack protector
    disabled.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3b6d988a2f7bda1bcd18d84f1a57e4a16f16656
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Apr 9 17:40:49 2019 +0300

    drm/i915/sdvo: Implement proper HDMI audio support for SDVO
    
    commit d74408f528261f900dddb9778f61b5c5a7a6249c upstream.
    
    Our SDVO audio support is pretty bogus. We can't push audio over the
    SDVO bus, so trying to enable audio in the SDVO control register doesn't
    do anything. In fact it looks like the SDVO encoder will always mix in
    the audio coming over HDA, and there's no (at least documented) way to
    disable that from our side. So HDMI audio does work currently on gen4
    but only by luck really. On gen3 it got broken by the referenced commit.
    And what has always been missing on every platform is the ELD.
    
    To pass the ELD to the audio driver we need to write it to magic buffer
    in the SDVO encoder hardware which then gets pulled out via HDA in the
    other end. Ie. pretty much the same thing we had for native HDMI before
    we started to just pass the ELD between the drivers. This sort of
    explains why we even have that silly hardware buffer with native HDMI.
    
    $ cat /proc/asound/card0/eld#1.0
    -monitor_present                0
    -eld_valid              0
    +monitor_present                1
    +eld_valid              1
    +monitor_name           LG TV
    +connection_type                HDMI
    +...
    
    This also fixes our state readout since we can now query the SDVO
    encoder about the state of the "ELD valid" and "presence detect"
    bits. As mentioned those don't actually control whether audio
    gets sent over the HDMI cable, but it's the best we can do. And with
    the state checker appeased we can re-enable HDMI audio for gen3.
    
    Cc: stable@vger.kernel.org
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: zardam@gmail.com
    Tested-by: zardam@gmail.com
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108976
    Fixes: de44e256b92c ("drm/i915/sdvo: Shut up state checker with hdmi cards on gen3")
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190409144054.24561-3-ville.syrjala@linux.intel.com
    Reviewed-by: Imre Deak <imre.deak@intel.com>
    (cherry picked from commit dc49a56bd43bb04982e64b44436831da801d0237)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03da939298b47b8daa3c5d1026f2927556edc1cd
Author: S.j. Wang <shengjiu.wang@nxp.com>
Date:   Wed May 15 06:42:18 2019 +0000

    ASoC: fsl_asrc: Fix the issue about unsupported rate
    
    commit b06c58c2a1eed571ea2a6640fdb85b7b00196b1e upstream.
    
    When the output sample rate is [8kHz, 30kHz], the limitation
    of the supported ratio range is [1/24, 8]. In the driver
    we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
    So this patch is to fix this issue and the potential rounding
    issue with divider.
    
    Fixes: fff6e03c7b65 ("ASoC: fsl_asrc: add support for 8-30kHz
    output sample rate")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c77b6aba381af6b06728769f18d6871d19d0e044
Author: S.j. Wang <shengjiu.wang@nxp.com>
Date:   Thu May 16 06:04:29 2019 +0000

    ASoC: cs42xx8: Add regcache mask dirty
    
    commit ad6eecbfc01c987e0253371f274c3872042e4350 upstream.
    
    Add regcache_mark_dirty before regcache_sync for power
    of codec may be lost at suspend, then all the register
    need to be reconfigured.
    
    Fixes: 0c516b4ff85c ("ASoC: cs42xx8: Add codec driver
    support for CS42448/CS42888")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b1c102e9d072d5f0868b52028d673ffee962a26
Author: Tejun Heo <tj@kernel.org>
Date:   Wed May 29 13:46:25 2019 -0700

    cgroup: Use css_tryget() instead of css_tryget_online() in task_get_css()
    
    commit 18fa84a2db0e15b02baa5d94bdb5bd509175d2f6 upstream.
    
    A PF_EXITING task can stay associated with an offline css.  If such
    task calls task_get_css(), it can get stuck indefinitely.  This can be
    triggered by BSD process accounting which writes to a file with
    PF_EXITING set when racing against memcg disable as in the backtrace
    at the end.
    
    After this change, task_get_css() may return a css which was already
    offline when the function was called.  None of the existing users are
    affected by this change.
    
      INFO: rcu_sched self-detected stall on CPU
      INFO: rcu_sched detected stalls on CPUs/tasks:
      ...
      NMI backtrace for cpu 0
      ...
      Call Trace:
       <IRQ>
       dump_stack+0x46/0x68
       nmi_cpu_backtrace.cold.2+0x13/0x57
       nmi_trigger_cpumask_backtrace+0xba/0xca
       rcu_dump_cpu_stacks+0x9e/0xce
       rcu_check_callbacks.cold.74+0x2af/0x433
       update_process_times+0x28/0x60
       tick_sched_timer+0x34/0x70
       __hrtimer_run_queues+0xee/0x250
       hrtimer_interrupt+0xf4/0x210
       smp_apic_timer_interrupt+0x56/0x110
       apic_timer_interrupt+0xf/0x20
       </IRQ>
      RIP: 0010:balance_dirty_pages_ratelimited+0x28f/0x3d0
      ...
       btrfs_file_write_iter+0x31b/0x563
       __vfs_write+0xfa/0x140
       __kernel_write+0x4f/0x100
       do_acct_process+0x495/0x580
       acct_process+0xb9/0xdb
       do_exit+0x748/0xa00
       do_group_exit+0x3a/0xa0
       get_signal+0x254/0x560
       do_signal+0x23/0x5c0
       exit_to_usermode_loop+0x5d/0xa0
       prepare_exit_to_usermode+0x53/0x80
       retint_user+0x8/0x8
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org # v4.2+
    Fixes: ec438699a9ae ("cgroup, block: implement task_get_css() and use it in bio_associate_current()")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a75d830333e520774733ec9205c1738ef020e724
Author: Coly Li <colyli@suse.de>
Date:   Mon Jun 10 06:13:34 2019 +0800

    bcache: fix stack corruption by PRECEDING_KEY()
    
    commit 31b90956b124240aa8c63250243ae1a53585c5e2 upstream.
    
    Recently people report bcache code compiled with gcc9 is broken, one of
    the buggy behavior I observe is that two adjacent 4KB I/Os should merge
    into one but they don't. Finally it turns out to be a stack corruption
    caused by macro PRECEDING_KEY().
    
    See how PRECEDING_KEY() is defined in bset.h,
    437 #define PRECEDING_KEY(_k)                                       \
    438 ({                                                              \
    439         struct bkey *_ret = NULL;                               \
    440                                                                 \
    441         if (KEY_INODE(_k) || KEY_OFFSET(_k)) {                  \
    442                 _ret = &KEY(KEY_INODE(_k), KEY_OFFSET(_k), 0);  \
    443                                                                 \
    444                 if (!_ret->low)                                 \
    445                         _ret->high--;                           \
    446                 _ret->low--;                                    \
    447         }                                                       \
    448                                                                 \
    449         _ret;                                                   \
    450 })
    
    At line 442, _ret points to address of a on-stack variable combined by
    KEY(), the life range of this on-stack variable is in line 442-446,
    once _ret is returned to bch_btree_insert_key(), the returned address
    points to an invalid stack address and this address is overwritten in
    the following called bch_btree_iter_init(). Then argument 'search' of
    bch_btree_iter_init() points to some address inside stackframe of
    bch_btree_iter_init(), exact address depends on how the compiler
    allocates stack space. Now the stack is corrupted.
    
    Fixes: 0eacac22034c ("bcache: PRECEDING_KEY()")
    Signed-off-by: Coly Li <colyli@suse.de>
    Reviewed-by: Rolf Fokkens <rolf@rolffokkens.nl>
    Reviewed-by: Pierre JUHEN <pierre.juhen@orange.fr>
    Tested-by: Shenghui Wang <shhuiw@foxmail.com>
    Tested-by: Pierre JUHEN <pierre.juhen@orange.fr>
    Cc: Kent Overstreet <kent.overstreet@gmail.com>
    Cc: Nix <nix@esperi.org.uk>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70ea54f744bf5ef4704f3acafc73eee75e1374c7
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Tue Jun 11 17:48:18 2019 +0100

    i2c: acorn: fix i2c warning
    
    commit ca21f851cc9643af049226d57fabc3c883ea648e upstream.
    
    The Acorn i2c driver (for RiscPC) triggers the "i2c adapter has no name"
    warning in the I2C core driver, resulting in the RTC being inaccessible.
    Fix this.
    
    Fixes: 2236baa75f70 ("i2c: Sanity checks on adapter registration")
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0365cb72070c84d3ec1a2b41bfa02e83a3ea4e2
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Mon Jun 3 14:15:37 2019 +0200

    iommu/arm-smmu: Avoid constant zero in TLBI writes
    
    commit 4e4abae311e4b44aaf61f18a826fd7136037f199 upstream.
    
    Apparently, some Qualcomm arm64 platforms which appear to expose their
    SMMU global register space are still, in fact, using a hypervisor to
    mediate it by trapping and emulating register accesses. Sadly, some
    deployed versions of said trapping code have bugs wherein they go
    horribly wrong for stores using r31 (i.e. XZR/WZR) as the source
    register.
    
    While this can be mitigated for GCC today by tweaking the constraints
    for the implementation of writel_relaxed(), to avoid any potential
    arms race with future compilers more aggressively optimising register
    allocation, the simple way is to just remove all the problematic
    constant zeros. For the write-only TLB operations, the actual value is
    irrelevant anyway and any old nearby variable will provide a suitable
    GPR to encode. The one point at which we really do need a zero to clear
    a context bank happens before any of the TLB maintenance where crashes
    have been reported, so is apparently not a problem... :/
    
    Reported-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
    Tested-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9af0e8e717122d796b374bdc3b74e147c63a62f8
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Sat May 12 10:44:02 2018 -0400

    media: v4l2-ioctl: clear fields in s_parm
    
    commit 8a7c5594c02022ca5fa7fb603e11b3e1feb76ed5 upstream.
    
    Zero the reserved capture/output array.
    
    Zero the extendedmode (it is never used in drivers).
    
    Clear all flags in capture/outputmode except for V4L2_MODE_HIGHQUALITY,
    as that is the only valid flag.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7013ea8df35d3078b286aa8b99bf868c24c92ca5
Author: Jann Horn <jannh@google.com>
Date:   Wed May 29 13:31:57 2019 +0200

    ptrace: restore smp_rmb() in __ptrace_may_access()
    
    commit f6581f5b55141a95657ef5742cf6a6bfa20a109f upstream.
    
    Restore the read memory barrier in __ptrace_may_access() that was deleted
    a couple years ago. Also add comments on this barrier and the one it pairs
    with to explain why they're there (as far as I understand).
    
    Fixes: bfedb589252c ("mm: Add a user_ns owner to mm_struct and fix ptrace permission checks")
    Cc: stable@vger.kernel.org
    Acked-by: Kees Cook <keescook@chromium.org>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50f806a53964577d43c4fbb7b35416fe3d317105
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Tue May 28 18:46:37 2019 -0500

    signal/ptrace: Don't leak unitialized kernel memory with PTRACE_PEEK_SIGINFO
    
    [ Upstream commit f6e2aa91a46d2bc79fce9b93a988dbe7655c90c0 ]
    
    Recently syzbot in conjunction with KMSAN reported that
    ptrace_peek_siginfo can copy an uninitialized siginfo to userspace.
    Inspecting ptrace_peek_siginfo confirms this.
    
    The problem is that off when initialized from args.off can be
    initialized to a negaive value.  At which point the "if (off >= 0)"
    test to see if off became negative fails because off started off
    negative.
    
    Prevent the core problem by adding a variable found that is only true
    if a siginfo is found and copied to a temporary in preparation for
    being copied to userspace.
    
    Prevent args.off from being truncated when being assigned to off by
    testing that off is <= the maximum possible value of off.  Convert off
    to an unsigned long so that we should not have to truncate args.off,
    we have well defined overflow behavior so if we add another check we
    won't risk fighting undefined compiler behavior, and so that we have a
    type whose maximum value is easy to test for.
    
    Cc: Andrei Vagin <avagin@gmail.com>
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+0d602a1b0d8c95bdf299@syzkaller.appspotmail.com
    Fixes: 84c751bd4aeb ("ptrace: add ability to retrieve signals without removing from a queue (v4)")
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89062f033fab66e1dd8a5e5d1e40965db8aad637
Author: Minchan Kim <minchan@kernel.org>
Date:   Thu Jun 13 15:56:15 2019 -0700

    mm/vmscan.c: fix trying to reclaim unevictable LRU page
    
    commit a58f2cef26e1ca44182c8b22f4f4395e702a5795 upstream.
    
    There was the below bug report from Wu Fangsuo.
    
    On the CMA allocation path, isolate_migratepages_range() could isolate
    unevictable LRU pages and reclaim_clean_page_from_list() can try to
    reclaim them if they are clean file-backed pages.
    
      page:ffffffbf02f33b40 count:86 mapcount:84 mapping:ffffffc08fa7a810 index:0x24
      flags: 0x19040c(referenced|uptodate|arch_1|mappedtodisk|unevictable|mlocked)
      raw: 000000000019040c ffffffc08fa7a810 0000000000000024 0000005600000053
      raw: ffffffc009b05b20 ffffffc009b05b20 0000000000000000 ffffffc09bf3ee80
      page dumped because: VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page))
      page->mem_cgroup:ffffffc09bf3ee80
      ------------[ cut here ]------------
      kernel BUG at /home/build/farmland/adroid9.0/kernel/linux/mm/vmscan.c:1350!
      Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 0 PID: 7125 Comm: syz-executor Tainted: G S              4.14.81 #3
      Hardware name: ASR AQUILAC EVB (DT)
      task: ffffffc00a54cd00 task.stack: ffffffc009b00000
      PC is at shrink_page_list+0x1998/0x3240
      LR is at shrink_page_list+0x1998/0x3240
      pc : [<ffffff90083a2158>] lr : [<ffffff90083a2158>] pstate: 60400045
      sp : ffffffc009b05940
      ..
         shrink_page_list+0x1998/0x3240
         reclaim_clean_pages_from_list+0x3c0/0x4f0
         alloc_contig_range+0x3bc/0x650
         cma_alloc+0x214/0x668
         ion_cma_allocate+0x98/0x1d8
         ion_alloc+0x200/0x7e0
         ion_ioctl+0x18c/0x378
         do_vfs_ioctl+0x17c/0x1780
         SyS_ioctl+0xac/0xc0
    
    Wu found it's due to commit ad6b67041a45 ("mm: remove SWAP_MLOCK in
    ttu").  Before that, unevictable pages go to cull_mlocked so that we
    can't reach the VM_BUG_ON_PAGE line.
    
    To fix the issue, this patch filters out unevictable LRU pages from the
    reclaim_clean_pages_from_list in CMA.
    
    Link: http://lkml.kernel.org/r/20190524071114.74202-1-minchan@kernel.org
    Fixes: ad6b67041a45 ("mm: remove SWAP_MLOCK in ttu")
    Signed-off-by: Minchan Kim <minchan@kernel.org>
    Reported-by: Wu Fangsuo <fangsuowu@asrmicro.com>
    Debugged-by: Wu Fangsuo <fangsuowu@asrmicro.com>
    Tested-by: Wu Fangsuo <fangsuowu@asrmicro.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Pankaj Suryawanshi <pankaj.suryawanshi@einfochips.com>
    Cc: <stable@vger.kernel.org>    [4.12+]
    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 f1c08645df0e50f7ab0bd7a9c314815be80b9a77
Author: Wengang Wang <wen.gang.wang@oracle.com>
Date:   Thu Jun 13 15:56:01 2019 -0700

    fs/ocfs2: fix race in ocfs2_dentry_attach_lock()
    
    commit be99ca2716972a712cde46092c54dee5e6192bf8 upstream.
    
    ocfs2_dentry_attach_lock() can be executed in parallel threads against the
    same dentry.  Make that race safe.  The race is like this:
    
                thread A                               thread B
    
    (A1) enter ocfs2_dentry_attach_lock,
    seeing dentry->d_fsdata is NULL,
    and no alias found by
    ocfs2_find_local_alias, so kmalloc
    a new ocfs2_dentry_lock structure
    to local variable "dl", dl1
    
                   .....
    
                                        (B1) enter ocfs2_dentry_attach_lock,
                                        seeing dentry->d_fsdata is NULL,
                                        and no alias found by
                                        ocfs2_find_local_alias so kmalloc
                                        a new ocfs2_dentry_lock structure
                                        to local variable "dl", dl2.
    
                                                       ......
    
    (A2) set dentry->d_fsdata with dl1,
    call ocfs2_dentry_lock() and increase
    dl1->dl_lockres.l_ro_holders to 1 on
    success.
                  ......
    
                                        (B2) set dentry->d_fsdata with dl2
                                        call ocfs2_dentry_lock() and increase
                                        dl2->dl_lockres.l_ro_holders to 1 on
                                        success.
    
                                                      ......
    
    (A3) call ocfs2_dentry_unlock()
    and decrease
    dl2->dl_lockres.l_ro_holders to 0
    on success.
                 ....
    
                                        (B3) call ocfs2_dentry_unlock(),
                                        decreasing
                                        dl2->dl_lockres.l_ro_holders, but
                                        see it's zero now, panic
    
    Link: http://lkml.kernel.org/r/20190529174636.22364-1-wen.gang.wang@oracle.com
    Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
    Reported-by: Daniel Sobe <daniel.sobe@nxp.com>
    Tested-by: Daniel Sobe <daniel.sobe@nxp.com>
    Reviewed-by: Changwei Ge <gechangwei@live.cn>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@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 373ecad9b9f4647c13ed59029613002ce0b2e647
Author: Shakeel Butt <shakeelb@google.com>
Date:   Thu Jun 13 15:55:49 2019 -0700

    mm/list_lru.c: fix memory leak in __memcg_init_list_lru_node
    
    commit 3510955b327176fd4cbab5baa75b449f077722a2 upstream.
    
    Syzbot reported following memory leak:
    
    ffffffffda RBX: 0000000000000003 RCX: 0000000000441f79
    BUG: memory leak
    unreferenced object 0xffff888114f26040 (size 32):
      comm "syz-executor626", pid 7056, jiffies 4294948701 (age 39.410s)
      hex dump (first 32 bytes):
        40 60 f2 14 81 88 ff ff 40 60 f2 14 81 88 ff ff  @`......@`......
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
         slab_post_alloc_hook mm/slab.h:439 [inline]
         slab_alloc mm/slab.c:3326 [inline]
         kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
         kmalloc include/linux/slab.h:547 [inline]
         __memcg_init_list_lru_node+0x58/0xf0 mm/list_lru.c:352
         memcg_init_list_lru_node mm/list_lru.c:375 [inline]
         memcg_init_list_lru mm/list_lru.c:459 [inline]
         __list_lru_init+0x193/0x2a0 mm/list_lru.c:626
         alloc_super+0x2e0/0x310 fs/super.c:269
         sget_userns+0x94/0x2a0 fs/super.c:609
         sget+0x8d/0xb0 fs/super.c:660
         mount_nodev+0x31/0xb0 fs/super.c:1387
         fuse_mount+0x2d/0x40 fs/fuse/inode.c:1236
         legacy_get_tree+0x27/0x80 fs/fs_context.c:661
         vfs_get_tree+0x2e/0x120 fs/super.c:1476
         do_new_mount fs/namespace.c:2790 [inline]
         do_mount+0x932/0xc50 fs/namespace.c:3110
         ksys_mount+0xab/0x120 fs/namespace.c:3319
         __do_sys_mount fs/namespace.c:3333 [inline]
         __se_sys_mount fs/namespace.c:3330 [inline]
         __x64_sys_mount+0x26/0x30 fs/namespace.c:3330
         do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    This is a simple off by one bug on the error path.
    
    Link: http://lkml.kernel.org/r/20190528043202.99980-1-shakeelb@google.com
    Fixes: 60d3fd32a7a9 ("list_lru: introduce per-memcg lists")
    Reported-by: syzbot+f90a420dfe2b1b03cb2c@syzkaller.appspotmail.com
    Signed-off-by: Shakeel Butt <shakeelb@google.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Kirill Tkhai <ktkhai@virtuozzo.com>
    Cc: <stable@vger.kernel.org>    [4.0+]
    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 4156b5bbf0fe311dc423d6b20741da1ea2c2e47f
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Jun 11 16:32:59 2019 +0200

    libata: Extend quirks for the ST1000LM024 drives with NOLPM quirk
    
    commit 31f6264e225fb92cf6f4b63031424f20797c297d upstream.
    
    We've received a bugreport that using LPM with ST1000LM024 drives leads
    to system lockups. So it seems that these models are buggy in more then
    1 way. Add NOLPM quirk to the existing quirks entry for BROKEN_FPDMA_AA.
    
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1571330
    Cc: stable@vger.kernel.org
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2127976c10256e051a8f1e5af6c1f9ae064768d
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sat Jun 1 12:08:01 2019 +0900

    ALSA: firewire-motu: fix destruction of data for isochronous resources
    
    commit 0e3fb6995bfabb23c172e8b883bf5ac57102678e upstream.
    
    The data for isochronous resources is not destroyed in expected place.
    This commit fixes the bug.
    
    Cc: <stable@vger.kernel.org> # v4.12+
    Fixes: 9b2bb4f2f4a2 ("ALSA: firewire-motu: add stream management functionality")
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0666b6d11678f56483acbcc334baced68d35941
Author: Kailang Yang <kailang@realtek.com>
Date:   Fri May 31 17:16:53 2019 +0800

    ALSA: hda/realtek - Update headset mode for ALC256
    
    commit 717f43d81afc1250300479075952a0e36d74ded3 upstream.
    
    ALC255 and ALC256 were some difference for hidden register.
    This update was suitable for ALC256.
    
    Fixes: e69e7e03ed22 ("ALSA: hda/realtek - ALC256 speaker noise issue")
    Signed-off-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 ff4a486f335f221c5b617f0ad5581dc8db3b2961
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sun Jun 9 19:29:12 2019 +0900

    ALSA: oxfw: allow PCM capture for Stanton SCS.1m
    
    commit d8fa87c368f5b4096c4746894fdcc195da285df1 upstream.
    
    Stanton SCS.1m can transfer isochronous packet with Multi Bit Linear
    Audio data channels, therefore it allows software to capture PCM
    substream. However, ALSA oxfw driver doesn't.
    
    This commit changes the driver to add one PCM substream for capture
    direction.
    
    Fixes: de5126cc3c0b ("ALSA: oxfw: add stream format quirk for SCS.1 models")
    Cc: <stable@vger.kernel.org> # v4.5+
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e5a7e1f1378d9845c8b2a66d729dcd97966e21d
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Tue May 7 11:53:22 2019 -0700

    HID: wacom: Sync INTUOSP2_BT touch state after each frame if necessary
    
    commit 69dbdfffef20c715df9f381b2cee4e9e0a4efd93 upstream.
    
    The Bluetooth interface of the 2nd-gen Intuos Pro batches together four
    independent "frames" of finger data into a single report. Each frame
    is essentially equivalent to a single USB report, with the up-to-10
    fingers worth of information being spread across two frames. At the
    moment the driver only calls `input_sync` after processing all four
    frames have been processed, which can result in the driver sending
    multiple updates for a single slot within the same SYN_REPORT. This
    can confuse userspace, so modify the driver to sync more often if
    necessary (i.e., after reporting the state of all fingers).
    
    Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
    Cc: <stable@vger.kernel.org> # 4.11+
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0c83ba15ff90b8d42d9f48c6c26ceef7bde037a
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Tue May 7 11:53:21 2019 -0700

    HID: wacom: Correct button numbering 2nd-gen Intuos Pro over Bluetooth
    
    commit 6441fc781c344df61402be1fde582c4491fa35fa upstream.
    
    The button numbering of the 2nd-gen Intuos Pro is not consistent between
    the USB and Bluetooth interfaces. Over USB, the HID_GENERIC codepath
    enumerates the eight ExpressKeys first (BTN_0 - BTN_7) followed by the
    center modeswitch button (BTN_8). The Bluetooth codepath, however, has
    the center modeswitch button as BTN_0 and the the eight ExpressKeys as
    BTN_1 - BTN_8. To ensure userspace button mappings do not change
    depending on how the tablet is connected, modify the Bluetooth codepath
    to report buttons in the same order as USB.
    
    To ensure the mode switch LED continues to toggle in response to the
    mode switch button, the `wacom_is_led_toggled` function also requires
    a small update.
    
    Link: https://github.com/linuxwacom/input-wacom/pull/79
    Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
    Cc: <stable@vger.kernel.org> # 4.11+
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Reviewed-by: Aaron Skomra <aaron.skomra@wacom.com>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 149d05f80dc9259ad62f2630935502e4c02b26a7
Author: Thomas Backlund <tmb@mageia.org>
Date:   Sat Jun 15 12:22:44 2019 +0300

    nouveau: Fix build with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT disabled
    
    Not-entirely-upstream-sha1-but-equivalent: bed2dd8421
    ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")
    
    Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit: b30a43ac7132)
    causes the build to fail with:
    
    ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
    
    This does not happend upstream as the offending code got removed in:
    bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")
    
    Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around
    the drm_legacy_mmap() call.
    
    Also, as Sven Joachim pointed out, we need to make the check in
    CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n case return -EINVAL as its done
    for basically all other gpu drivers, especially in upstream kernels
    drivers/gpu/drm/ttm/ttm_bo_vm.c as of the upstream commit bed2dd8421.
    
    NOTE. This is a minimal stable-only fix for trees where b30a43ac7132 is
    backported as the build error affects nouveau only.
    
    Fixes: b30a43ac7132 ("drm/nouveau: add kconfig option to turn off nouveau
           legacy contexts. (v3)")
    Signed-off-by: Thomas Backlund <tmb@mageia.org>
    Cc: stable@vger.kernel.org
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Sven Joachim <svenjoac@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40ea9f3352ab426035671f46cf6d9f3cf45c691d
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Apr 18 16:45:15 2019 +1000

    drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)
    
    commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream.
    
    There was a nouveau DDX that relied on legacy context ioctls to work,
    but we fixed it years ago, give distros that have a modern DDX the
    option to break the uAPI and close the mess of holes that legacy
    context support is.
    
    Full context of the story:
    
    commit 0e975980d435d58df2d430d688b8c18778b42218
    Author: Peter Antoine <peter.antoine@intel.com>
    Date:   Tue Jun 23 08:18:49 2015 +0100
    
        drm: Turn off Legacy Context Functions
    
        The context functions are not used by the i915 driver and should not
        be used by modeset drivers. These driver functions contain several bugs
        and security holes. This change makes these functions optional can be
        turned on by a setting, they are turned off by default for modeset
        driver with the exception of the nouvea driver that may require them with
        an old version of libdrm.
    
        The previous attempt was
    
        commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1
        Author: Daniel Vetter <daniel.vetter@ffwll.ch>
        Date:   Thu Aug 8 15:41:21 2013 +0200
    
            drm: mark context support as a legacy subsystem
    
        but this had to be reverted
    
        commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
        Author: Dave Airlie <airlied@redhat.com>
        Date:   Fri Sep 20 08:32:59 2013 +1000
    
            Revert "drm: mark context support as a legacy subsystem"
    
        v2: remove returns from void function, and formatting (Daniel Vetter)
    
        v3:
        - s/Nova/nouveau/ in the commit message, and add references to the
          previous attempts
        - drop the part touching the drm hw lock, that should be a separate
          patch.
    
        Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2)
        Cc: Peter Antoine <peter.antoine@intel.com> (v2)
        Reviewed-by: Peter Antoine <peter.antoine@intel.com>
        Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    
    v2: move DRM_VM dependency into legacy config.
    v3: fix missing dep (kbuild robot)
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>