--- /dev/null
+From ee13919c2e8d1f904e035ad4b4239029a8994131 Mon Sep 17 00:00:00 2001
+From: Pavel Shilovsky <pshilov@microsoft.com>
+Date: Thu, 10 Jan 2019 11:27:28 -0800
+Subject: CIFS: Do not hide EINTR after sending network packets
+
+From: Pavel Shilovsky <pshilov@microsoft.com>
+
+commit ee13919c2e8d1f904e035ad4b4239029a8994131 upstream.
+
+Currently we hide EINTR code returned from sock_sendmsg()
+and return 0 instead. This makes a caller think that we
+successfully completed the network operation which is not
+true. Fix this by properly returning EINTR to callers.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/transport.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/cifs/transport.c
++++ b/fs/cifs/transport.c
+@@ -301,7 +301,7 @@ uncork:
+ if (rc < 0 && rc != -EINTR)
+ cifs_dbg(VFS, "Error %d sending data on socket to server\n",
+ rc);
+- else
++ else if (rc > 0)
+ rc = 0;
+
+ return rc;
--- /dev/null
+From b9a74cde94957d82003fb9f7ab4777938ca851cd Mon Sep 17 00:00:00 2001
+From: Ross Lagerwall <ross.lagerwall@citrix.com>
+Date: Tue, 8 Jan 2019 18:30:57 +0000
+Subject: cifs: Fix potential OOB access of lock element array
+
+From: Ross Lagerwall <ross.lagerwall@citrix.com>
+
+commit b9a74cde94957d82003fb9f7ab4777938ca851cd upstream.
+
+If maxBuf is small but non-zero, it could result in a zero sized lock
+element array which we would then try and access OOB.
+
+Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/file.c | 8 ++++----
+ fs/cifs/smb2file.c | 4 ++--
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+--- a/fs/cifs/file.c
++++ b/fs/cifs/file.c
+@@ -1118,10 +1118,10 @@ cifs_push_mandatory_locks(struct cifsFil
+
+ /*
+ * Accessing maxBuf is racy with cifs_reconnect - need to store value
+- * and check it for zero before using.
++ * and check it before using.
+ */
+ max_buf = tcon->ses->server->maxBuf;
+- if (!max_buf) {
++ if (max_buf < (sizeof(struct smb_hdr) + sizeof(LOCKING_ANDX_RANGE))) {
+ free_xid(xid);
+ return -EINVAL;
+ }
+@@ -1456,10 +1456,10 @@ cifs_unlock_range(struct cifsFileInfo *c
+
+ /*
+ * Accessing maxBuf is racy with cifs_reconnect - need to store value
+- * and check it for zero before using.
++ * and check it before using.
+ */
+ max_buf = tcon->ses->server->maxBuf;
+- if (!max_buf)
++ if (max_buf < (sizeof(struct smb_hdr) + sizeof(LOCKING_ANDX_RANGE)))
+ return -EINVAL;
+
+ max_num = (max_buf - sizeof(struct smb_hdr)) /
+--- a/fs/cifs/smb2file.c
++++ b/fs/cifs/smb2file.c
+@@ -123,10 +123,10 @@ smb2_unlock_range(struct cifsFileInfo *c
+
+ /*
+ * Accessing maxBuf is racy with cifs_reconnect - need to store value
+- * and check it for zero before using.
++ * and check it before using.
+ */
+ max_buf = tcon->ses->server->maxBuf;
+- if (!max_buf)
++ if (max_buf < sizeof(struct smb2_lock_element))
+ return -EINVAL;
+
+ max_num = max_buf / sizeof(struct smb2_lock_element);
--- /dev/null
+From 63f3655f950186752236bb88a22f8252c11ce394 Mon Sep 17 00:00:00 2001
+From: Michal Hocko <mhocko@suse.com>
+Date: Tue, 8 Jan 2019 15:23:07 -0800
+Subject: mm, memcg: fix reclaim deadlock with writeback
+
+From: Michal Hocko <mhocko@suse.com>
+
+commit 63f3655f950186752236bb88a22f8252c11ce394 upstream.
+
+Liu Bo has experienced a deadlock between memcg (legacy) reclaim and the
+ext4 writeback
+
+ task1:
+ wait_on_page_bit+0x82/0xa0
+ shrink_page_list+0x907/0x960
+ shrink_inactive_list+0x2c7/0x680
+ shrink_node_memcg+0x404/0x830
+ shrink_node+0xd8/0x300
+ do_try_to_free_pages+0x10d/0x330
+ try_to_free_mem_cgroup_pages+0xd5/0x1b0
+ try_charge+0x14d/0x720
+ memcg_kmem_charge_memcg+0x3c/0xa0
+ memcg_kmem_charge+0x7e/0xd0
+ __alloc_pages_nodemask+0x178/0x260
+ alloc_pages_current+0x95/0x140
+ pte_alloc_one+0x17/0x40
+ __pte_alloc+0x1e/0x110
+ alloc_set_pte+0x5fe/0xc20
+ do_fault+0x103/0x970
+ handle_mm_fault+0x61e/0xd10
+ __do_page_fault+0x252/0x4d0
+ do_page_fault+0x30/0x80
+ page_fault+0x28/0x30
+
+ task2:
+ __lock_page+0x86/0xa0
+ mpage_prepare_extent_to_map+0x2e7/0x310 [ext4]
+ ext4_writepages+0x479/0xd60
+ do_writepages+0x1e/0x30
+ __writeback_single_inode+0x45/0x320
+ writeback_sb_inodes+0x272/0x600
+ __writeback_inodes_wb+0x92/0xc0
+ wb_writeback+0x268/0x300
+ wb_workfn+0xb4/0x390
+ process_one_work+0x189/0x420
+ worker_thread+0x4e/0x4b0
+ kthread+0xe6/0x100
+ ret_from_fork+0x41/0x50
+
+He adds
+ "task1 is waiting for the PageWriteback bit of the page that task2 has
+ collected in mpd->io_submit->io_bio, and tasks2 is waiting for the
+ LOCKED bit the page which tasks1 has locked"
+
+More precisely task1 is handling a page fault and it has a page locked
+while it charges a new page table to a memcg. That in turn hits a
+memory limit reclaim and the memcg reclaim for legacy controller is
+waiting on the writeback but that is never going to finish because the
+writeback itself is waiting for the page locked in the #PF path. So
+this is essentially ABBA deadlock:
+
+ lock_page(A)
+ SetPageWriteback(A)
+ unlock_page(A)
+ lock_page(B)
+ lock_page(B)
+ pte_alloc_pne
+ shrink_page_list
+ wait_on_page_writeback(A)
+ SetPageWriteback(B)
+ unlock_page(B)
+
+ # flush A, B to clear the writeback
+
+This accumulating of more pages to flush is used by several filesystems
+to generate a more optimal IO patterns.
+
+Waiting for the writeback in legacy memcg controller is a workaround for
+pre-mature OOM killer invocations because there is no dirty IO
+throttling available for the controller. There is no easy way around
+that unfortunately. Therefore fix this specific issue by pre-allocating
+the page table outside of the page lock. We have that handy
+infrastructure for that already so simply reuse the fault-around pattern
+which already does this.
+
+There are probably other hidden __GFP_ACCOUNT | GFP_KERNEL allocations
+from under a fs page locked but they should be really rare. I am not
+aware of a better solution unfortunately.
+
+[akpm@linux-foundation.org: fix mm/memory.c:__do_fault()]
+[akpm@linux-foundation.org: coding-style fixes]
+[mhocko@kernel.org: enhance comment, per Johannes]
+ Link: http://lkml.kernel.org/r/20181214084948.GA5624@dhcp22.suse.cz
+Link: http://lkml.kernel.org/r/20181213092221.27270-1-mhocko@kernel.org
+Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
+Signed-off-by: Michal Hocko <mhocko@suse.com>
+Reported-by: Liu Bo <bo.liu@linux.alibaba.com>
+Debugged-by: Liu Bo <bo.liu@linux.alibaba.com>
+Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Acked-by: Johannes Weiner <hannes@cmpxchg.org>
+Reviewed-by: Liu Bo <bo.liu@linux.alibaba.com>
+Cc: Jan Kara <jack@suse.cz>
+Cc: Dave Chinner <david@fromorbit.com>
+Cc: Theodore Ts'o <tytso@mit.edu>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Shakeel Butt <shakeelb@google.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>
+
+---
+ mm/memory.c | 22 ++++++++++++++++++++++
+ 1 file changed, 22 insertions(+)
+
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -2823,6 +2823,28 @@ static int __do_fault(struct fault_env *
+ struct vm_fault vmf;
+ int ret;
+
++ /*
++ * Preallocate pte before we take page_lock because this might lead to
++ * deadlocks for memcg reclaim which waits for pages under writeback:
++ * lock_page(A)
++ * SetPageWriteback(A)
++ * unlock_page(A)
++ * lock_page(B)
++ * lock_page(B)
++ * pte_alloc_pne
++ * shrink_page_list
++ * wait_on_page_writeback(A)
++ * SetPageWriteback(B)
++ * unlock_page(B)
++ * # flush A, B to clear the writeback
++ */
++ if (pmd_none(*vmf->pmd) && !vmf->prealloc_pte) {
++ vmf->prealloc_pte = pte_alloc_one(vmf->vma->vm_mm);
++ if (!vmf->prealloc_pte)
++ return VM_FAULT_OOM;
++ smp_wmb(); /* See comment in __pte_alloc() */
++ }
++
+ vmf.virtual_address = (void __user *)(fe->address & PAGE_MASK);
+ vmf.pgoff = pgoff;
+ vmf.flags = fe->flags;
--- /dev/null
+From 8ab88c7169b7fba98812ead6524b9d05bc76cf00 Mon Sep 17 00:00:00 2001
+From: Jan Stancek <jstancek@redhat.com>
+Date: Tue, 8 Jan 2019 15:23:28 -0800
+Subject: mm: page_mapped: don't assume compound page is huge or THP
+
+From: Jan Stancek <jstancek@redhat.com>
+
+commit 8ab88c7169b7fba98812ead6524b9d05bc76cf00 upstream.
+
+LTP proc01 testcase has been observed to rarely trigger crashes
+on arm64:
+ page_mapped+0x78/0xb4
+ stable_page_flags+0x27c/0x338
+ kpageflags_read+0xfc/0x164
+ proc_reg_read+0x7c/0xb8
+ __vfs_read+0x58/0x178
+ vfs_read+0x90/0x14c
+ SyS_read+0x60/0xc0
+
+The issue is that page_mapped() assumes that if compound page is not
+huge, then it must be THP. But if this is 'normal' compound page
+(COMPOUND_PAGE_DTOR), then following loop can keep running (for
+HPAGE_PMD_NR iterations) until it tries to read from memory that isn't
+mapped and triggers a panic:
+
+ for (i = 0; i < hpage_nr_pages(page); i++) {
+ if (atomic_read(&page[i]._mapcount) >= 0)
+ return true;
+ }
+
+I could replicate this on x86 (v4.20-rc4-98-g60b548237fed) only
+with a custom kernel module [1] which:
+ - allocates compound page (PAGEC) of order 1
+ - allocates 2 normal pages (COPY), which are initialized to 0xff (to
+ satisfy _mapcount >= 0)
+ - 2 PAGEC page structs are copied to address of first COPY page
+ - second page of COPY is marked as not present
+ - call to page_mapped(COPY) now triggers fault on access to 2nd COPY
+ page at offset 0x30 (_mapcount)
+
+[1] https://github.com/jstancek/reproducers/blob/master/kernel/page_mapped_crash/repro.c
+
+Fix the loop to iterate for "1 << compound_order" pages.
+
+Kirrill said "IIRC, sound subsystem can producuce custom mapped compound
+pages".
+
+Link: http://lkml.kernel.org/r/c440d69879e34209feba21e12d236d06bc0a25db.1543577156.git.jstancek@redhat.com
+Fixes: e1534ae95004 ("mm: differentiate page_mapped() from page_mapcount() for compound pages")
+Signed-off-by: Jan Stancek <jstancek@redhat.com>
+Debugged-by: Laszlo Ersek <lersek@redhat.com>
+Suggested-by: "Kirill A. Shutemov" <kirill@shutemov.name>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Andrea Arcangeli <aarcange@redhat.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>
+
+---
+ mm/util.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/util.c
++++ b/mm/util.c
+@@ -389,7 +389,7 @@ bool page_mapped(struct page *page)
+ return true;
+ if (PageHuge(page))
+ return false;
+- for (i = 0; i < hpage_nr_pages(page); i++) {
++ for (i = 0; i < (1 << compound_order(page)); i++) {
+ if (atomic_read(&page[i]._mapcount) >= 0)
+ return true;
+ }
alsa-hda-realtek-disable-headset-mic-vref-for-headset-mode-of-alc225.patch
+cifs-do-not-hide-eintr-after-sending-network-packets.patch
+cifs-fix-potential-oob-access-of-lock-element-array.patch
+usb-cdc-acm-send-zlp-for-telit-3g-intel-based-modems.patch
+usb-storage-don-t-insert-sane-sense-for-spc3-when-bad-sense-specified.patch
+usb-storage-add-quirk-for-smi-sm3350.patch
+usb-add-usb_quirk_delay_ctrl_msg-quirk-for-corsair-k70-rgb.patch
+slab-alien-caches-must-not-be-initialized-if-the-allocation-of-the-alien-cache-failed.patch
+mm-memcg-fix-reclaim-deadlock-with-writeback.patch
+mm-page_mapped-don-t-assume-compound-page-is-huge-or-thp.patch
--- /dev/null
+From 09c2e76ed734a1d36470d257a778aaba28e86531 Mon Sep 17 00:00:00 2001
+From: Christoph Lameter <cl@linux.com>
+Date: Tue, 8 Jan 2019 15:23:00 -0800
+Subject: slab: alien caches must not be initialized if the allocation of the alien cache failed
+
+From: Christoph Lameter <cl@linux.com>
+
+commit 09c2e76ed734a1d36470d257a778aaba28e86531 upstream.
+
+Callers of __alloc_alien() check for NULL. We must do the same check in
+__alloc_alien_cache to avoid NULL pointer dereferences on allocation
+failures.
+
+Link: http://lkml.kernel.org/r/010001680f42f192-82b4e12e-1565-4ee0-ae1f-1e98974906aa-000000@email.amazonses.com
+Fixes: 49dfc304ba241 ("slab: use the lock on alien_cache, instead of the lock on array_cache")
+Fixes: c8522a3a5832b ("Slab: introduce alloc_alien")
+Signed-off-by: Christoph Lameter <cl@linux.com>
+Reported-by: syzbot+d6ed4ec679652b4fd4e4@syzkaller.appspotmail.com
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Pekka Enberg <penberg@kernel.org>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.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>
+
+---
+ mm/slab.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/mm/slab.c
++++ b/mm/slab.c
+@@ -682,8 +682,10 @@ static struct alien_cache *__alloc_alien
+ struct alien_cache *alc = NULL;
+
+ alc = kmalloc_node(memsize, gfp, node);
+- init_arraycache(&alc->ac, entries, batch);
+- spin_lock_init(&alc->lock);
++ if (alc) {
++ init_arraycache(&alc->ac, entries, batch);
++ spin_lock_init(&alc->lock);
++ }
+ return alc;
+ }
+
--- /dev/null
+From 3483254b89438e60f719937376c5e0ce2bc46761 Mon Sep 17 00:00:00 2001
+From: Jack Stocker <jackstocker.93@gmail.com>
+Date: Thu, 3 Jan 2019 21:56:53 +0000
+Subject: USB: Add USB_QUIRK_DELAY_CTRL_MSG quirk for Corsair K70 RGB
+
+From: Jack Stocker <jackstocker.93@gmail.com>
+
+commit 3483254b89438e60f719937376c5e0ce2bc46761 upstream.
+
+To match the Corsair Strafe RGB, the Corsair K70 RGB also requires
+USB_QUIRK_DELAY_CTRL_MSG to completely resolve boot connection issues
+discussed here: https://github.com/ckb-next/ckb-next/issues/42.
+Otherwise roughly 1 in 10 boots the keyboard will fail to be detected.
+
+Patch that applied delay control quirk for Corsair Strafe RGB:
+cb88a0588717 ("usb: quirks: add control message delay for 1b1c:1b20")
+
+Previous K70 RGB patch to add delay-init quirk:
+7a1646d92257 ("Add delay-init quirk for Corsair K70 RGB keyboards")
+
+Signed-off-by: Jack Stocker <jackstocker.93@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/quirks.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/core/quirks.c
++++ b/drivers/usb/core/quirks.c
+@@ -240,7 +240,8 @@ static const struct usb_device_id usb_qu
+ USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+
+ /* Corsair K70 RGB */
+- { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
++ { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT |
++ USB_QUIRK_DELAY_CTRL_MSG },
+
+ /* Corsair Strafe */
+ { USB_DEVICE(0x1b1c, 0x1b15), .driver_info = USB_QUIRK_DELAY_INIT |
--- /dev/null
+From 34aabf918717dd14e05051896aaecd3b16b53d95 Mon Sep 17 00:00:00 2001
+From: Daniele Palmas <dnlplm@gmail.com>
+Date: Fri, 28 Dec 2018 16:15:41 +0100
+Subject: usb: cdc-acm: send ZLP for Telit 3G Intel based modems
+
+From: Daniele Palmas <dnlplm@gmail.com>
+
+commit 34aabf918717dd14e05051896aaecd3b16b53d95 upstream.
+
+Telit 3G Intel based modems require zero packet to be sent if
+out data size is equal to the endpoint max packet size.
+
+Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/class/cdc-acm.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/usb/class/cdc-acm.c
++++ b/drivers/usb/class/cdc-acm.c
+@@ -1828,6 +1828,13 @@ static const struct usb_device_id acm_id
+ .driver_info = IGNORE_DEVICE,
+ },
+
++ { USB_DEVICE(0x1bc7, 0x0021), /* Telit 3G ACM only composition */
++ .driver_info = SEND_ZERO_PACKET,
++ },
++ { USB_DEVICE(0x1bc7, 0x0023), /* Telit 3G ACM + ECM composition */
++ .driver_info = SEND_ZERO_PACKET,
++ },
++
+ /* control interfaces without any protocol set */
+ { USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM,
+ USB_CDC_PROTO_NONE) },
--- /dev/null
+From 0a99cc4b8ee83885ab9f097a3737d1ab28455ac0 Mon Sep 17 00:00:00 2001
+From: Icenowy Zheng <icenowy@aosc.io>
+Date: Thu, 3 Jan 2019 11:26:18 +0800
+Subject: USB: storage: add quirk for SMI SM3350
+
+From: Icenowy Zheng <icenowy@aosc.io>
+
+commit 0a99cc4b8ee83885ab9f097a3737d1ab28455ac0 upstream.
+
+The SMI SM3350 USB-UFS bridge controller cannot handle long sense request
+correctly and will make the chip refuse to do read/write when requested
+long sense.
+
+Add a bad sense quirk for it.
+
+Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/storage/unusual_devs.h | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -1285,6 +1285,18 @@ UNUSUAL_DEV( 0x090c, 0x1132, 0x0000, 0xf
+ US_FL_FIX_CAPACITY ),
+
+ /*
++ * Reported by Icenowy Zheng <icenowy@aosc.io>
++ * The SMI SM3350 USB-UFS bridge controller will enter a wrong state
++ * that do not process read/write command if a long sense is requested,
++ * so force to use 18-byte sense.
++ */
++UNUSUAL_DEV( 0x090c, 0x3350, 0x0000, 0xffff,
++ "SMI",
++ "SM3350 UFS-to-USB-Mass-Storage bridge",
++ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
++ US_FL_BAD_SENSE ),
++
++/*
+ * Reported by Paul Hartman <paul.hartman+linux@gmail.com>
+ * This card reader returns "Illegal Request, Logical Block Address
+ * Out of Range" for the first READ(10) after a new card is inserted.
--- /dev/null
+From c5603d2fdb424849360fe7e3f8c1befc97571b8c Mon Sep 17 00:00:00 2001
+From: Icenowy Zheng <icenowy@aosc.io>
+Date: Thu, 3 Jan 2019 11:26:17 +0800
+Subject: USB: storage: don't insert sane sense for SPC3+ when bad sense specified
+
+From: Icenowy Zheng <icenowy@aosc.io>
+
+commit c5603d2fdb424849360fe7e3f8c1befc97571b8c upstream.
+
+Currently the code will set US_FL_SANE_SENSE flag unconditionally if
+device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to
+prevent this behavior, because SMI SM3350 UFS-USB bridge controller,
+which claims SPC4, will show strange behavior with 96-byte sense
+(put the chip into a wrong state that cannot read/write anything).
+
+Check the presence of US_FL_BAD_SENSE when assuming US_FL_SANE_SENSE on
+SPC4+ devices.
+
+Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/storage/scsiglue.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/storage/scsiglue.c
++++ b/drivers/usb/storage/scsiglue.c
+@@ -251,8 +251,12 @@ static int slave_configure(struct scsi_d
+ if (!(us->fflags & US_FL_NEEDS_CAP16))
+ sdev->try_rc_10_first = 1;
+
+- /* assume SPC3 or latter devices support sense size > 18 */
+- if (sdev->scsi_level > SCSI_SPC_2)
++ /*
++ * assume SPC3 or latter devices support sense size > 18
++ * unless US_FL_BAD_SENSE quirk is specified.
++ */
++ if (sdev->scsi_level > SCSI_SPC_2 &&
++ !(us->fflags & US_FL_BAD_SENSE))
+ us->fflags |= US_FL_SANE_SENSE;
+
+ /*
projects / thirdparty / kernel / stable-queue.git / commitdiff
