commit c37da90efff5f183bea6ae4c2af33571f61fe317
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Sep 3 11:24:31 2020 +0200

    Linux 4.19.143
    
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79361df22e723d97607b4a8e871f0b3720ada7be
Author: Hector Martin <marcan@marcan.st>
Date:   Sun Aug 16 17:44:31 2020 +0900

    ALSA: usb-audio: Update documentation comment for MS2109 quirk
    
    commit 74a2a7de81a2ef20732ec02087314e92692a7a1b upstream.
    
    As the recent fix addressed the channel swap problem more properly,
    update the comment as well.
    
    Fixes: 1b7ecc241a67 ("ALSA: usb-audio: work around streaming quirk for MacroSilicon MS2109")
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Link: https://lore.kernel.org/r/20200816084431.102151-1-marcan@marcan.st
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a83adbe00b32df180a108adc86c2620521574c8d
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date:   Wed Jul 29 07:37:12 2020 -0400

    HID: hiddev: Fix slab-out-of-bounds write in hiddev_ioctl_usage()
    
    commit 25a097f5204675550afb879ee18238ca917cba7a upstream.
    
    `uref->usage_index` is not always being properly checked, causing
    hiddev_ioctl_usage() to go out of bounds under some cases. Fix it.
    
    Reported-by: syzbot+34ee1b45d88571c2fa8b@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=f2aebe90b8c56806b050a20b36f51ed6acabe802
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc828b79feea72cfbc34fd6104a8386bade6fd78
Author: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date:   Mon Aug 31 14:59:29 2020 -0400

    tpm: Unify the mismatching TPM space buffer sizes
    
    [ Upstream commit 6c4e79d99e6f42b79040f1a33cd4018f5425030b ]
    
    The size of the buffers for storing context's and sessions can vary from
    arch to arch as PAGE_SIZE can be anything between 4 kB and 256 kB (the
    maximum for PPC64). Define a fixed buffer size set to 16 kB. This should be
    enough for most use with three handles (that is how many we allow at the
    moment). Parametrize the buffer size while doing this, so that it is easier
    to revisit this later on if required.
    
    Cc: stable@vger.kernel.org
    Reported-by: Stefan Berger <stefanb@linux.ibm.com>
    Fixes: 745b361e989a ("tpm: infrastructure for TPM spaces")
    Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Tested-by: Stefan Berger <stefanb@linux.ibm.com>
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c7514464430cb4d57182542fc15c09d07eb808d
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Aug 6 19:46:35 2020 -0700

    usb: dwc3: gadget: Handle ZLP for sg requests
    
    [ Upstream commit bc9a2e226ea95e1699f7590845554de095308b75 ]
    
    Currently dwc3 doesn't handle usb_request->zero for SG requests. This
    change checks and prepares extra TRBs for the ZLP for SG requests.
    
    Cc: <stable@vger.kernel.org> # v4.5+
    Fixes: 04c03d10e507 ("usb: dwc3: gadget: handle request->zero")
    Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7012bf6d6c3a56f2866c4c08539932be98b5585d
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Aug 6 19:46:29 2020 -0700

    usb: dwc3: gadget: Fix handling ZLP
    
    [ Upstream commit d2ee3ff79e6a3d4105e684021017d100524dc560 ]
    
    The usb_request->zero doesn't apply for isoc. Also, if we prepare a
    0-length (ZLP) TRB for the OUT direction, we need to prepare an extra
    TRB to pad up to the MPS alignment. Use the same bounce buffer for the
    ZLP TRB and the extra pad TRB.
    
    Cc: <stable@vger.kernel.org> # v4.5+
    Fixes: d6e5a549cc4d ("usb: dwc3: simplify ZLP handling")
    Fixes: 04c03d10e507 ("usb: dwc3: gadget: handle request->zero")
    Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4d7362a5cc5297bf79d3b3465c43722af5f3da7
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Aug 6 19:46:23 2020 -0700

    usb: dwc3: gadget: Don't setup more than requested
    
    [ Upstream commit 5d187c0454ef4c5e046a81af36882d4d515922ec ]
    
    The SG list may be set up with entry size more than the requested
    length. Check the usb_request->length and make sure that we don't setup
    the TRBs to send/receive more than requested. This case may occur when
    the SG entry is allocated up to a certain minimum size, but the request
    length is less than that. It can also occur when the request is reused
    for a different request length.
    
    Cc: <stable@vger.kernel.org> # v4.18+
    Fixes: a31e63b608ff ("usb: dwc3: gadget: Correct handling of scattergather lists")
    Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d037285c566f07319a3c4da9093bf3b8d7c197f
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Mon Aug 10 17:31:16 2020 -0400

    btrfs: check the right error variable in btrfs_del_dir_entries_in_log
    
    [ Upstream commit fb2fecbad50964b9f27a3b182e74e437b40753ef ]
    
    With my new locking code dbench is so much faster that I tripped over a
    transaction abort from ENOSPC.  This turned out to be because
    btrfs_del_dir_entries_in_log was checking for ret == -ENOSPC, but this
    function sets err on error, and returns err.  So instead of properly
    marking the inode as needing a full commit, we were returning -ENOSPC
    and aborting in __btrfs_unlink_inode.  Fix this by checking the proper
    variable so that we return the correct thing in the case of ENOSPC.
    
    The ENOENT needs to be checked, because btrfs_lookup_dir_item_index()
    can return -ENOENT if the dir item isn't in the tree log (which would
    happen if we hadn't fsync'ed this guy).  We actually handle that case in
    __btrfs_unlink_inode, so it's an expected error to get back.
    
    Fixes: 4a500fd178c8 ("Btrfs: Metadata ENOSPC handling for tree log")
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    [ add note and comment about ENOENT ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2cce2472d99164c5ffb910f4dac2e81bb62341ca
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Aug 26 10:32:29 2020 -0400

    usb: storage: Add unusual_uas entry for Sony PSZ drives
    
    commit 20934c0de13b49a072fb1e0ca79fe0fe0e40eae5 upstream.
    
    The PSZ-HA* family of USB disk drives from Sony can't handle the
    REPORT OPCODES command when using the UAS protocol.  This patch adds
    an appropriate quirks entry.
    
    Reported-and-tested-by: Till Dörges <doerges@pre-sense.de>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200826143229.GB400430@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77b8ac359dfb887cbf4517c54f7fb70fa1b7530d
Author: Tom Rix <trix@redhat.com>
Date:   Sat Aug 1 08:21:54 2020 -0700

    USB: cdc-acm: rework notification_buffer resizing
    
    commit f4b9d8a582f738c24ebeabce5cc15f4b8159d74e upstream.
    
    Clang static analysis reports this error
    
    cdc-acm.c:409:3: warning: Use of memory after it is freed
            acm_process_notification(acm, (unsigned char *)dr);
    
    There are three problems, the first one is that dr is not reset
    
    The variable dr is set with
    
    if (acm->nb_index)
            dr = (struct usb_cdc_notification *)acm->notification_buffer;
    
    But if the notification_buffer is too small it is resized with
    
                    if (acm->nb_size) {
                            kfree(acm->notification_buffer);
                            acm->nb_size = 0;
                    }
                    alloc_size = roundup_pow_of_two(expected_size);
                    /*
                     * kmalloc ensures a valid notification_buffer after a
                     * use of kfree in case the previous allocation was too
                     * small. Final freeing is done on disconnect.
                     */
                    acm->notification_buffer =
                            kmalloc(alloc_size, GFP_ATOMIC);
    
    dr should point to the new acm->notification_buffer.
    
    The second problem is any data in the notification_buffer is lost
    when the pointer is freed.  In the normal case, the current data
    is accumulated in the notification_buffer here.
    
            memcpy(&acm->notification_buffer[acm->nb_index],
                   urb->transfer_buffer, copy_size);
    
    When a resize happens, anything before
    notification_buffer[acm->nb_index] is garbage.
    
    The third problem is the acm->nb_index is not reset on a
    resizing buffer error.
    
    So switch resizing to using krealloc and reassign dr and
    reset nb_index.
    
    Fixes: ea2583529cd1 ("cdc-acm: reassemble fragmented notifications")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20200801152154.20683-1-trix@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a0e5894e9936a03f4c8087f408e1e4eff4439f2
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Aug 26 22:21:19 2020 +0300

    USB: gadget: u_f: Unbreak offset calculation in VLAs
    
    commit bfd08d06d978d0304eb6f7855b548aa2cd1c5486 upstream.
    
    Inadvertently the commit b1cd1b65afba ("USB: gadget: u_f: add overflow checks
    to VLA macros") makes VLA macros to always return 0 due to different scope of
    two variables of the same name. Obviously we need to have only one.
    
    Fixes: b1cd1b65afba ("USB: gadget: u_f: add overflow checks to VLA macros")
    Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Brooke Basile <brookebasile@gmail.com>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20200826192119.56450-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 471b23586387a32857778c511be60ab31c98dcfd
Author: Brooke Basile <brookebasile@gmail.com>
Date:   Tue Aug 25 09:07:27 2020 -0400

    USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb()
    
    commit 2b74b0a04d3e9f9f08ff026e5663dce88ff94e52 upstream.
    
    Some values extracted by ncm_unwrap_ntb() could possibly lead to several
    different out of bounds reads of memory.  Specifically the values passed
    to netdev_alloc_skb_ip_align() need to be checked so that memory is not
    overflowed.
    
    Resolve this by applying bounds checking to a number of different
    indexes and lengths of the structure parsing logic.
    
    Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
    Signed-off-by: Brooke Basile <brookebasile@gmail.com>
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbd25d805c30234826265e1cc1b2955731308a0d
Author: Brooke Basile <brookebasile@gmail.com>
Date:   Tue Aug 25 09:05:08 2020 -0400

    USB: gadget: u_f: add overflow checks to VLA macros
    
    commit b1cd1b65afba95971fa457dfdb2c941c60d38c5b upstream.
    
    size can potentially hold an overflowed value if its assigned expression
    is left unchecked, leading to a smaller than needed allocation when
    vla_group_size() is used by callers to allocate memory.
    To fix this, add a test for saturation before declaring variables and an
    overflow check to (n) * sizeof(type).
    If the expression results in overflow, vla_group_size() will return SIZE_MAX.
    
    Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
    Suggested-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Brooke Basile <brookebasile@gmail.com>
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3670e3e697a3ada2f5e342750e66fbbac1afa0b2
Author: Tang Bin <tangbin@cmss.chinamobile.com>
Date:   Wed Aug 26 22:49:31 2020 +0800

    usb: host: ohci-exynos: Fix error handling in exynos_ohci_probe()
    
    commit 1d4169834628d18b2392a2da92b7fbf5e8e2ce89 upstream.
    
    If the function platform_get_irq() failed, the negative value
    returned will not be detected here. So fix error handling in
    exynos_ohci_probe(). And when get irq failed, the function
    platform_get_irq() logs an error message, so remove redundant
    message here.
    
    Fixes: 62194244cf87 ("USB: Add Samsung Exynos OHCI diver")
    Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
    Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
    Link: https://lore.kernel.org/r/20200826144931.1828-1-tangbin@cmss.chinamobile.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2948369b5ee15f98951f24268121779129b53de0
Author: Cyril Roelandt <tipecaml@gmail.com>
Date:   Tue Aug 25 23:22:31 2020 +0200

    USB: Ignore UAS for JMicron JMS567 ATA/ATAPI Bridge
    
    commit 9aa37788e7ebb3f489fb4b71ce07adadd444264a upstream.
    
    This device does not support UAS properly and a similar entry already
    exists in drivers/usb/storage/unusual_uas.h. Without this patch,
    storage_probe() defers the handling of this device to UAS, which cannot
    handle it either.
    
    Tested-by: Brice Goglin <brice.goglin@gmail.com>
    Fixes: bc3bdb12bbb3 ("usb-storage: Disable UAS on JMicron SATA enclosure")
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    CC: <stable@vger.kernel.org>
    Signed-off-by: Cyril Roelandt <tipecaml@gmail.com>
    Link: https://lore.kernel.org/r/20200825212231.46309-1-tipecaml@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e8b409caa894946ae187ad1195a3356468a0e72
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Aug 26 15:46:24 2020 -0400

    USB: quirks: Ignore duplicate endpoint on Sound Devices MixPre-D
    
    commit 068834a2773b6a12805105cfadbb3d4229fc6e0a upstream.
    
    The Sound Devices MixPre-D audio card suffers from the same defect
    as the Sound Devices USBPre2: an endpoint shared between a normal
    audio interface and a vendor-specific interface, in violation of the
    USB spec.  Since the USB core now treats duplicated endpoints as bugs
    and ignores them, the audio endpoint isn't available and the card
    can't be used for audio capture.
    
    Along the same lines as commit bdd1b147b802 ("USB: quirks: blacklist
    duplicate ep on Sound Devices USBPre2"), this patch adds a quirks
    entry saying to ignore ep5in for interface 1, leaving it available for
    use with standard audio interface 2.
    
    Reported-and-tested-by: Jean-Christophe Barnoud <jcbarnoud@gmail.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: <stable@vger.kernel.org>
    Fixes: 3e4f8e21c4f2 ("USB: core: fix check for duplicate endpoints")
    Link: https://lore.kernel.org/r/20200826194624.GA412633@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9107ee9a118b6a5b3cd7ca633e4fbe5c672d0c80
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri Jul 31 13:16:20 2020 +0800

    USB: quirks: Add no-lpm quirk for another Raydium touchscreen
    
    commit 5967116e8358899ebaa22702d09b0af57fef23e1 upstream.
    
    There's another Raydium touchscreen needs the no-lpm quirk:
    [    1.339149] usb 1-9: New USB device found, idVendor=2386, idProduct=350e, bcdDevice= 0.00
    [    1.339150] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    [    1.339151] usb 1-9: Product: Raydium Touch System
    [    1.339152] usb 1-9: Manufacturer: Raydium Corporation
    ...
    [    6.450497] usb 1-9: can't set config #1, error -110
    
    BugLink: https://bugs.launchpad.net/bugs/1889446
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200731051622.28643-1-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e8bc59dfbb42f731c6487663f4c9e1f386075be
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Tue Aug 18 19:27:47 2020 -0700

    usb: uas: Add quirk for PNY Pro Elite
    
    commit 9a469bc9f32dd33c7aac5744669d21a023a719cd upstream.
    
    PNY Pro Elite USB 3.1 Gen 2 device (SSD) doesn't respond to ATA_12
    pass-through command (i.e. it just hangs). If it doesn't support this
    command, it should respond properly to the host. Let's just add a quirk
    to be able to move forward with other operations.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
    Link: https://lore.kernel.org/r/2b0585228b003eedcc82db84697b31477df152e0.1597803605.git.thinhn@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df9ad14fccdc1d167bb206cc6453dc9aa3dcf0c9
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Aug 10 14:29:54 2020 -0400

    USB: yurex: Fix bad gfp argument
    
    commit f176ede3a3bde5b398a6777a7f9ff091baa2d3ff upstream.
    
    The syzbot fuzzer identified a bug in the yurex driver: It passes
    GFP_KERNEL as a memory-allocation flag to usb_submit_urb() at a time
    when its state is TASK_INTERRUPTIBLE, not TASK_RUNNING:
    
    do not call blocking ops when !TASK_RUNNING; state=1 set at [<00000000370c7c68>] prepare_to_wait+0xb1/0x2a0 kernel/sched/wait.c:247
    WARNING: CPU: 1 PID: 340 at kernel/sched/core.c:7253 __might_sleep+0x135/0x190
    kernel/sched/core.c:7253
    Kernel panic - not syncing: panic_on_warn set ...
    CPU: 1 PID: 340 Comm: syz-executor677 Not tainted 5.8.0-syzkaller #0
    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+0xf6/0x16e lib/dump_stack.c:118
     panic+0x2aa/0x6e1 kernel/panic.c:231
     __warn.cold+0x20/0x50 kernel/panic.c:600
     report_bug+0x1bd/0x210 lib/bug.c:198
     handle_bug+0x41/0x80 arch/x86/kernel/traps.c:234
     exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254
     asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536
    RIP: 0010:__might_sleep+0x135/0x190 kernel/sched/core.c:7253
    Code: 65 48 8b 1c 25 40 ef 01 00 48 8d 7b 10 48 89 fe 48 c1 ee 03 80 3c 06 00 75
    2b 48 8b 73 10 48 c7 c7 e0 9e 06 86 e8 ed 12 f6 ff <0f> 0b e9 46 ff ff ff e8 1f
    b2 4b 00 e9 29 ff ff ff e8 15 b2 4b 00
    RSP: 0018:ffff8881cdb77a28 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff8881c6458000 RCX: 0000000000000000
    RDX: ffff8881c6458000 RSI: ffffffff8129ec93 RDI: ffffed1039b6ef37
    RBP: ffffffff86fdade2 R08: 0000000000000001 R09: ffff8881db32f54f
    R10: 0000000000000000 R11: 0000000030343354 R12: 00000000000001f2
    R13: 0000000000000000 R14: 0000000000000068 R15: ffffffff83c1b1aa
     slab_pre_alloc_hook.constprop.0+0xea/0x200 mm/slab.h:498
     slab_alloc_node mm/slub.c:2816 [inline]
     slab_alloc mm/slub.c:2900 [inline]
     kmem_cache_alloc_trace+0x46/0x220 mm/slub.c:2917
     kmalloc include/linux/slab.h:554 [inline]
     dummy_urb_enqueue+0x7a/0x880 drivers/usb/gadget/udc/dummy_hcd.c:1251
     usb_hcd_submit_urb+0x2b2/0x22d0 drivers/usb/core/hcd.c:1547
     usb_submit_urb+0xb4e/0x13e0 drivers/usb/core/urb.c:570
     yurex_write+0x3ea/0x820 drivers/usb/misc/yurex.c:495
    
    This patch changes the call to use GFP_ATOMIC instead of GFP_KERNEL.
    
    Reported-and-tested-by: syzbot+c2c3302f9c601a4b1be2@syzkaller.appspotmail.com
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200810182954.GB307778@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bb0a4e7760fd3b2a2df195b5a9698ca454981fe
Author: Evan Quan <evan.quan@amd.com>
Date:   Fri Aug 21 12:18:58 2020 +0800

    drm/amd/pm: correct Vega12 swctf limit setting
    
    commit e0ffd340249699ad27a6c91abdfa3e89f7823941 upstream.
    
    Correct the Vega12 thermal swctf limit.
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 513e0593f5aae022e4c2ca32392b1cebac8601d0
Author: Evan Quan <evan.quan@amd.com>
Date:   Fri Aug 21 12:05:03 2020 +0800

    drm/amd/pm: correct Vega10 swctf limit setting
    
    commit b05d71b51078fc428c6b72582126d9d75d3c1f4c upstream.
    
    Correct the Vega10 thermal swctf limit.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1267
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d55a510668d303ed411d19464013615b8dd2c81
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Aug 25 11:43:45 2020 -0400

    drm/amdgpu: Fix buffer overflow in INFO ioctl
    
    commit b5b97cab55eb71daba3283c8b1d2cce456d511a1 upstream.
    
    The values for "se_num" and "sh_num" come from the user in the ioctl.
    They can be in the 0-255 range but if they're more than
    AMDGPU_GFX_MAX_SE (4) or AMDGPU_GFX_MAX_SH_PER_SE (2) then it results in
    an out of bounds read.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93404fc8b630670170658bdb8d1ae8b2ab7d7634
Author: qiuguorui1 <qiuguorui1@huawei.com>
Date:   Thu Aug 20 11:16:29 2020 +0800

    irqchip/stm32-exti: Avoid losing interrupts due to clearing pending bits by mistake
    
    commit e579076ac0a3bebb440fab101aef3c42c9f4c709 upstream.
    
    In the current code, when the eoi callback of the exti clears the pending
    bit of the current interrupt, it will first read the values of fpr and
    rpr, then logically OR the corresponding bit of the interrupt number,
    and finally write back to fpr and rpr.
    
    We found through experiments that if two exti interrupts,
    we call them int1/int2, arrive almost at the same time. in our scenario,
    the time difference is 30 microseconds, assuming int1 is triggered first.
    
    there will be an extreme scenario: both int's pending bit are set to 1,
    the irq handle of int1 is executed first, and eoi handle is then executed,
    at this moment, all pending bits are cleared, but the int 2 has not
    finally been reported to the cpu yet, which eventually lost int2.
    
    According to stm32's TRM description about rpr and fpr: Writing a 1 to this
    bit will trigger a rising edge event on event x, Writing 0 has no
    effect.
    
    Therefore, when clearing the pending bit, we only need to clear the
    pending bit of the irq.
    
    Fixes: 927abfc4461e7 ("irqchip/stm32: Add stm32mp1 support with hierarchy domain")
    Signed-off-by: qiuguorui1 <qiuguorui1@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org # v4.18+
    Link: https://lore.kernel.org/r/20200820031629.15582-1-qiuguorui1@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9eeca1ed80366ad71906f868979d451e532af1c
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Aug 30 19:07:53 2020 +0200

    genirq/matrix: Deal with the sillyness of for_each_cpu() on UP
    
    commit 784a0830377d0761834e385975bc46861fea9fa0 upstream.
    
    Most of the CPU mask operations behave the same way, but for_each_cpu() and
    it's variants ignore the cpumask argument and claim that CPU0 is always in
    the mask. This is historical, inconsistent and annoying behaviour.
    
    The matrix allocator uses for_each_cpu() and can be called on UP with an
    empty cpumask. The calling code does not expect that this succeeds but
    until commit e027fffff799 ("x86/irq: Unbreak interrupt affinity setting")
    this went unnoticed. That commit added a WARN_ON() to catch cases which
    move an interrupt from one vector to another on the same CPU. The warning
    triggers on UP.
    
    Add a check for the cpumask being empty to prevent this.
    
    Fixes: 2f75d9e1c905 ("genirq: Implement bitmap matrix allocator")
    Reported-by: kernel test robot <rong.a.chen@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d57313ce14b6449369f04e07afd8bfe2c70a2bc
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Fri Aug 21 13:53:42 2020 +0300

    device property: Fix the secondary firmware node handling in set_primary_fwnode()
    
    commit c15e1bdda4365a5f17cdadf22bf1c1df13884a9e upstream.
    
    When the primary firmware node pointer is removed from a
    device (set to NULL) the secondary firmware node pointer,
    when it exists, is made the primary node for the device.
    However, the secondary firmware node pointer of the original
    primary firmware node is never cleared (set to NULL).
    
    To avoid situation where the secondary firmware node pointer
    is pointing to a non-existing object, clearing it properly
    when the primary node is removed from a device in
    set_primary_fwnode().
    
    Fixes: 97badf873ab6 ("device property: Make it possible to use secondary firmware nodes")
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 517b087a70a3fc59cdba5dcf99afcb8a2f90a3c7
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon Aug 24 19:35:31 2020 +0200

    PM: sleep: core: Fix the handling of pending runtime resume requests
    
    commit e3eb6e8fba65094328b8dca635d00de74ba75b45 upstream.
    
    It has been reported that system-wide suspend may be aborted in the
    absence of any wakeup events due to unforseen interactions of it with
    the runtume PM framework.
    
    One failing scenario is when there are multiple devices sharing an
    ACPI power resource and runtime-resume needs to be carried out for
    one of them during system-wide suspend (for example, because it needs
    to be reconfigured before the whole system goes to sleep).  In that
    case, the runtime-resume of that device involves turning the ACPI
    power resource "on" which in turn causes runtime-resume requests
    to be queued up for all of the other devices sharing it.  Those
    requests go to the runtime PM workqueue which is frozen during
    system-wide suspend, so they are not actually taken care of until
    the resume of the whole system, but the pm_runtime_barrier()
    call in __device_suspend() sees them and triggers system wakeup
    events for them which then cause the system-wide suspend to be
    aborted if wakeup source objects are in active use.
    
    Of course, the logic that leads to triggering those wakeup events is
    questionable in the first place, because clearly there are cases in
    which a pending runtime resume request for a device is not connected
    to any real wakeup events in any way (like the one above).  Moreover,
    it is racy, because the device may be resuming already by the time
    the pm_runtime_barrier() runs and so if the driver doesn't take care
    of signaling the wakeup event as appropriate, it will be lost.
    However, if the driver does take care of that, the extra
    pm_wakeup_event() call in the core is redundant.
    
    Accordingly, drop the conditional pm_wakeup_event() call fron
    __device_suspend() and make the latter call pm_runtime_barrier()
    alone.  Also modify the comment next to that call to reflect the new
    code and extend it to mention the need to avoid unwanted interactions
    between runtime PM and system-wide device suspend callbacks.
    
    Fixes: 1e2ef05bb8cf8 ("PM: Limit race conditions between runtime PM and system sleep (v2)")
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
    Tested-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
    Tested-by: Pengfei Xu <pengfei.xu@intel.com>
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc52d19b77e9ef49939dea2f8f8756d79f9533ae
Author: Ding Hui <dinghui@sangfor.com.cn>
Date:   Fri Aug 21 12:15:49 2020 +0300

    xhci: Always restore EP_SOFT_CLEAR_TOGGLE even if ep reset failed
    
    commit f1ec7ae6c9f8c016db320e204cb519a1da1581b8 upstream.
    
    Some device drivers call libusb_clear_halt when target ep queue
    is not empty. (eg. spice client connected to qemu for usb redir)
    
    Before commit f5249461b504 ("xhci: Clear the host side toggle
    manually when endpoint is soft reset"), that works well.
    But now, we got the error log:
    
        EP not empty, refuse reset
    
    xhci_endpoint_reset failed and left ep_state's EP_SOFT_CLEAR_TOGGLE
    bit still set
    
    So all the subsequent urb sumbits to the ep will fail with the
    warn log:
    
        Can't enqueue URB while manually clearing toggle
    
    We need to clear ep_state EP_SOFT_CLEAR_TOGGLE bit after
    xhci_endpoint_reset, even if it failed.
    
    Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset")
    Cc: stable <stable@vger.kernel.org> # v4.17+
    Signed-off-by: Ding Hui <dinghui@sangfor.com.cn>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20200821091549.20556-4-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de24ca614bad9279707ebd1e4d4b0cc78b423631
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri Aug 21 12:15:48 2020 +0300

    xhci: Do warm-reset when both CAS and XDEV_RESUME are set
    
    commit 904df64a5f4d5ebd670801d869ca0a6d6a6e8df6 upstream.
    
    Sometimes re-plugging a USB device during system sleep renders the device
    useless:
    [  173.418345] xhci_hcd 0000:00:14.0: Get port status 2-4 read: 0x14203e2, return 0x10262
    ...
    [  176.496485] usb 2-4: Waited 2000ms for CONNECT
    [  176.496781] usb usb2-port4: status 0000.0262 after resume, -19
    [  176.497103] usb 2-4: can't resume, status -19
    [  176.497438] usb usb2-port4: logical disconnect
    
    Because PLS equals to XDEV_RESUME, xHCI driver reports U3 to usbcore,
    despite of CAS bit is flagged.
    
    So proritize CAS over XDEV_RESUME to let usbcore handle warm-reset for
    the port.
    
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20200821091549.20556-3-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 567e1a915e8f0897972d190fd7a7ef8e9a35954c
Author: Li Jun <jun.li@nxp.com>
Date:   Fri Aug 21 12:15:47 2020 +0300

    usb: host: xhci: fix ep context print mismatch in debugfs
    
    commit 0077b1b2c8d9ad5f7a08b62fb8524cdb9938388f upstream.
    
    dci is 0 based and xhci_get_ep_ctx() will do ep index increment to get
    the ep context.
    
    [rename dci to ep_index -Mathias]
    Cc: stable <stable@vger.kernel.org> # v4.15+
    Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver")
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20200821091549.20556-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32a4f37b6849f7432cbbd00de05aa470cb01782f
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Aug 25 17:22:58 2020 +0200

    XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.
    
    commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream.
    
    handler data is meant for interrupt handlers and not for storing irq chip
    specific information as some devices require handler data to store internal
    per interrupt information, e.g. pinctrl/GPIO chained interrupt handlers.
    
    This obviously creates a conflict of interests and crashes the machine
    because the XEN pointer is overwritten by the driver pointer.
    
    As the XEN data is not handler specific it should be stored in
    irqdesc::irq_data::chip_data instead.
    
    A simple sed s/irq_[sg]et_handler_data/irq_[sg]et_chip_data/ cures that.
    
    Cc: stable@vger.kernel.org
    Reported-by: Roman Shaposhnik <roman@zededa.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Roman Shaposhnik <roman@zededa.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/87lfi2yckt.fsf@nanos.tec.linutronix.de
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c3d77a31b0633dd8d61e3ab7e3d919af6fded75
Author: Jan Kara <jack@suse.cz>
Date:   Fri May 29 16:08:58 2020 +0200

    writeback: Fix sync livelock due to b_dirty_time processing
    
    commit f9cae926f35e8230330f28c7b743ad088611a8de upstream.
    
    When we are processing writeback for sync(2), move_expired_inodes()
    didn't set any inode expiry value (older_than_this). This can result in
    writeback never completing if there's steady stream of inodes added to
    b_dirty_time list as writeback rechecks dirty lists after each writeback
    round whether there's more work to be done. Fix the problem by using
    sync(2) start time is inode expiry value when processing b_dirty_time
    list similarly as for ordinarily dirtied inodes. This requires some
    refactoring of older_than_this handling which simplifies the code
    noticeably as a bonus.
    
    Fixes: 0ae45f63d4ef ("vfs: add support for a lazytime mount option")
    CC: stable@vger.kernel.org
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be0937e03bf65b4e113213658bb3c54b5e5d4f0e
Author: Jan Kara <jack@suse.cz>
Date:   Fri May 29 15:05:22 2020 +0200

    writeback: Avoid skipping inode writeback
    
    commit 5afced3bf28100d81fb2fe7e98918632a08feaf5 upstream.
    
    Inode's i_io_list list head is used to attach inode to several different
    lists - wb->{b_dirty, b_dirty_time, b_io, b_more_io}. When flush worker
    prepares a list of inodes to writeback e.g. for sync(2), it moves inodes
    to b_io list. Thus it is critical for sync(2) data integrity guarantees
    that inode is not requeued to any other writeback list when inode is
    queued for processing by flush worker. That's the reason why
    writeback_single_inode() does not touch i_io_list (unless the inode is
    completely clean) and why __mark_inode_dirty() does not touch i_io_list
    if I_SYNC flag is set.
    
    However there are two flaws in the current logic:
    
    1) When inode has only I_DIRTY_TIME set but it is already queued in b_io
    list due to sync(2), concurrent __mark_inode_dirty(inode, I_DIRTY_SYNC)
    can still move inode back to b_dirty list resulting in skipping
    writeback of inode time stamps during sync(2).
    
    2) When inode is on b_dirty_time list and writeback_single_inode() races
    with __mark_inode_dirty() like:
    
    writeback_single_inode()                __mark_inode_dirty(inode, I_DIRTY_PAGES)
      inode->i_state |= I_SYNC
      __writeback_single_inode()
                                              inode->i_state |= I_DIRTY_PAGES;
                                              if (inode->i_state & I_SYNC)
                                                bail
      if (!(inode->i_state & I_DIRTY_ALL))
      - not true so nothing done
    
    We end up with I_DIRTY_PAGES inode on b_dirty_time list and thus
    standard background writeback will not writeback this inode leading to
    possible dirty throttling stalls etc. (thanks to Martijn Coenen for this
    analysis).
    
    Fix these problems by tracking whether inode is queued in b_io or
    b_more_io lists in a new I_SYNC_QUEUED flag. When this flag is set, we
    know flush worker has queued inode and we should not touch i_io_list.
    On the other hand we also know that once flush worker is done with the
    inode it will requeue the inode to appropriate dirty list. When
    I_SYNC_QUEUED is not set, __mark_inode_dirty() can (and must) move inode
    to appropriate dirty list.
    
    Reported-by: Martijn Coenen <maco@android.com>
    Reviewed-by: Martijn Coenen <maco@android.com>
    Tested-by: Martijn Coenen <maco@android.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Fixes: 0ae45f63d4ef ("vfs: add support for a lazytime mount option")
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f58ddc07eef098a32741e74516bb6ef18009ce1
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jun 10 17:36:03 2020 +0200

    writeback: Protect inode->i_io_list with inode->i_lock
    
    commit b35250c0816c7cf7d0a8de92f5fafb6a7508a708 upstream.
    
    Currently, operations on inode->i_io_list are protected by
    wb->list_lock. In the following patches we'll need to maintain
    consistency between inode->i_state and inode->i_io_list so change the
    code so that inode->i_lock protects also all inode's i_io_list handling.
    
    Reviewed-by: Martijn Coenen <maco@android.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    CC: stable@vger.kernel.org # Prerequisite for "writeback: Avoid skipping inode writeback"
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2eb35a11bbcc3636cdabd6228299d6a1b91cde00
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date:   Mon Aug 17 11:26:46 2020 +0900

    serial: 8250: change lock order in serial8250_do_startup()
    
    commit 205d300aea75623e1ae4aa43e0d265ab9cf195fd upstream.
    
    We have a number of "uart.port->desc.lock vs desc.lock->uart.port"
    lockdep reports coming from 8250 driver; this causes a bit of trouble
    to people, so let's fix it.
    
    The problem is reverse lock order in two different call paths:
    
    chain #1:
    
     serial8250_do_startup()
      spin_lock_irqsave(&port->lock);
       disable_irq_nosync(port->irq);
        raw_spin_lock_irqsave(&desc->lock)
    
    chain #2:
    
      __report_bad_irq()
       raw_spin_lock_irqsave(&desc->lock)
        for_each_action_of_desc()
         printk()
          spin_lock_irqsave(&port->lock);
    
    Fix this by changing the order of locks in serial8250_do_startup():
     do disable_irq_nosync() first, which grabs desc->lock, and grab
     uart->port after that, so that chain #1 and chain #2 have same lock
     order.
    
    Full lockdep splat:
    
     ======================================================
     WARNING: possible circular locking dependency detected
     5.4.39 #55 Not tainted
     ======================================================
    
     swapper/0/0 is trying to acquire lock:
     ffffffffab65b6c0 (console_owner){-...}, at: console_lock_spinning_enable+0x31/0x57
    
     but task is already holding lock:
     ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba
    
     which lock already depends on the new lock.
    
     the existing dependency chain (in reverse order) is:
    
     -> #2 (&irq_desc_lock_class){-.-.}:
            _raw_spin_lock_irqsave+0x61/0x8d
            __irq_get_desc_lock+0x65/0x89
            __disable_irq_nosync+0x3b/0x93
            serial8250_do_startup+0x451/0x75c
            uart_startup+0x1b4/0x2ff
            uart_port_activate+0x73/0xa0
            tty_port_open+0xae/0x10a
            uart_open+0x1b/0x26
            tty_open+0x24d/0x3a0
            chrdev_open+0xd5/0x1cc
            do_dentry_open+0x299/0x3c8
            path_openat+0x434/0x1100
            do_filp_open+0x9b/0x10a
            do_sys_open+0x15f/0x3d7
            kernel_init_freeable+0x157/0x1dd
            kernel_init+0xe/0x105
            ret_from_fork+0x27/0x50
    
     -> #1 (&port_lock_key){-.-.}:
            _raw_spin_lock_irqsave+0x61/0x8d
            serial8250_console_write+0xa7/0x2a0
            console_unlock+0x3b7/0x528
            vprintk_emit+0x111/0x17f
            printk+0x59/0x73
            register_console+0x336/0x3a4
            uart_add_one_port+0x51b/0x5be
            serial8250_register_8250_port+0x454/0x55e
            dw8250_probe+0x4dc/0x5b9
            platform_drv_probe+0x67/0x8b
            really_probe+0x14a/0x422
            driver_probe_device+0x66/0x130
            device_driver_attach+0x42/0x5b
            __driver_attach+0xca/0x139
            bus_for_each_dev+0x97/0xc9
            bus_add_driver+0x12b/0x228
            driver_register+0x64/0xed
            do_one_initcall+0x20c/0x4a6
            do_initcall_level+0xb5/0xc5
            do_basic_setup+0x4c/0x58
            kernel_init_freeable+0x13f/0x1dd
            kernel_init+0xe/0x105
            ret_from_fork+0x27/0x50
    
     -> #0 (console_owner){-...}:
            __lock_acquire+0x118d/0x2714
            lock_acquire+0x203/0x258
            console_lock_spinning_enable+0x51/0x57
            console_unlock+0x25d/0x528
            vprintk_emit+0x111/0x17f
            printk+0x59/0x73
            __report_bad_irq+0xa3/0xba
            note_interrupt+0x19a/0x1d6
            handle_irq_event_percpu+0x57/0x79
            handle_irq_event+0x36/0x55
            handle_fasteoi_irq+0xc2/0x18a
            do_IRQ+0xb3/0x157
            ret_from_intr+0x0/0x1d
            cpuidle_enter_state+0x12f/0x1fd
            cpuidle_enter+0x2e/0x3d
            do_idle+0x1ce/0x2ce
            cpu_startup_entry+0x1d/0x1f
            start_kernel+0x406/0x46a
            secondary_startup_64+0xa4/0xb0
    
     other info that might help us debug this:
    
     Chain exists of:
       console_owner --> &port_lock_key --> &irq_desc_lock_class
    
      Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(&irq_desc_lock_class);
                                    lock(&port_lock_key);
                                    lock(&irq_desc_lock_class);
       lock(console_owner);
    
      *** DEADLOCK ***
    
     2 locks held by swapper/0/0:
      #0: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba
      #1: ffffffffab65b5c0 (console_lock){+.+.}, at: console_trylock_spinning+0x20/0x181
    
     stack backtrace:
     CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.39 #55
     Hardware name: XXXXXX
     Call Trace:
      <IRQ>
      dump_stack+0xbf/0x133
      ? print_circular_bug+0xd6/0xe9
      check_noncircular+0x1b9/0x1c3
      __lock_acquire+0x118d/0x2714
      lock_acquire+0x203/0x258
      ? console_lock_spinning_enable+0x31/0x57
      console_lock_spinning_enable+0x51/0x57
      ? console_lock_spinning_enable+0x31/0x57
      console_unlock+0x25d/0x528
      ? console_trylock+0x18/0x4e
      vprintk_emit+0x111/0x17f
      ? lock_acquire+0x203/0x258
      printk+0x59/0x73
      __report_bad_irq+0xa3/0xba
      note_interrupt+0x19a/0x1d6
      handle_irq_event_percpu+0x57/0x79
      handle_irq_event+0x36/0x55
      handle_fasteoi_irq+0xc2/0x18a
      do_IRQ+0xb3/0x157
      common_interrupt+0xf/0xf
      </IRQ>
    
    Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Fixes: 768aec0b5bcc ("serial: 8250: fix shared interrupts issues with SMP and RT kernels")
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Reported-by: Raul Rangel <rrangel@google.com>
    BugLink: https://bugs.chromium.org/p/chromium/issues/detail?id=1114800
    Link: https://lore.kernel.org/lkml/CAHQZ30BnfX+gxjPm1DUd5psOTqbyDh4EJE=2=VAMW_VDafctkA@mail.gmail.com/T/#u
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200817022646.1484638-1-sergey.senozhatsky@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce755e4eae3e7f782d6a690ac6bd85ac9671b5e0
Author: Valmer Huhn <valmer.huhn@concurrent-rt.com>
Date:   Thu Aug 13 12:52:55 2020 -0400

    serial: 8250_exar: Fix number of ports for Commtech PCIe cards
    
    commit c6b9e95dde7b54e6a53c47241201ab5a4035c320 upstream.
    
    The following in 8250_exar.c line 589 is used to determine the number
    of ports for each Exar board:
    
    nr_ports = board->num_ports ? board->num_ports : pcidev->device & 0x0f;
    
    If the number of ports a card has is not explicitly specified, it defaults
    to the rightmost 4 bits of the PCI device ID. This is prone to error since
    not all PCI device IDs contain a number which corresponds to the number of
    ports that card provides.
    
    This particular case involves COMMTECH_4222PCIE, COMMTECH_4224PCIE and
    COMMTECH_4228PCIE cards with device IDs 0x0022, 0x0020 and 0x0021.
    Currently the multiport cards receive 2, 0 and 1 port instead of 2, 4 and
    8 ports respectively.
    
    To fix this, each Commtech Fastcom PCIe card is given a struct where the
    number of ports is explicitly specified. This ensures 'board->num_ports'
    is used instead of the default 'pcidev->device & 0x0f'.
    
    Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci")
    Signed-off-by: Valmer Huhn <valmer.huhn@concurrent-rt.com>
    Tested-by: Valmer Huhn <valmer.huhn@concurrent-rt.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200813165255.GC345440@icarus.concurrent-rt.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e12f36220f6f89ecf78edc98a153d548352d6951
Author: Lukas Wunner <lukas@wunner.de>
Date:   Thu Aug 13 12:59:54 2020 +0200

    serial: pl011: Don't leak amba_ports entry on driver register error
    
    commit 89efbe70b27dd325d8a8c177743a26b885f7faec upstream.
    
    pl011_probe() calls pl011_setup_port() to reserve an amba_ports[] entry,
    then calls pl011_register_port() to register the uart driver with the
    tty layer.
    
    If registration of the uart driver fails, the amba_ports[] entry is not
    released.  If this happens 14 times (value of UART_NR macro), then all
    amba_ports[] entries will have been leaked and driver probing is no
    longer possible.  (To be fair, that can only happen if the DeviceTree
    doesn't contain alias IDs since they cause the same entry to be used for
    a given port.)   Fix it.
    
    Fixes: ef2889f7ffee ("serial: pl011: Move uart_register_driver call to device")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: stable@vger.kernel.org # v3.15+
    Cc: Tushar Behera <tushar.behera@linaro.org>
    Link: https://lore.kernel.org/r/138f8c15afb2f184d8102583f8301575566064a6.1597316167.git.lukas@wunner.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eec2f7d9f0352a8bfe41980632e4e67a0d5c032b
Author: Lukas Wunner <lukas@wunner.de>
Date:   Thu Aug 13 12:52:40 2020 +0200

    serial: pl011: Fix oops on -EPROBE_DEFER
    
    commit 27afac93e3bd7fa89749cf11da5d86ac9cde4dba upstream.
    
    If probing of a pl011 gets deferred until after free_initmem(), an oops
    ensues because pl011_console_match() is called which has been freed.
    
    Fix by removing the __init attribute from the function and those it
    calls.
    
    Commit 10879ae5f12e ("serial: pl011: add console matching function")
    introduced pl011_console_match() not just for early consoles but
    regular preferred consoles, such as those added by acpi_parse_spcr().
    Regular consoles may be registered after free_initmem() for various
    reasons, one being deferred probing, another being dynamic enablement
    of serial ports using a DeviceTree overlay.
    
    Thus, pl011_console_match() must not be declared __init and the
    functions it calls mustn't either.
    
    Stack trace for posterity:
    
    Unable to handle kernel paging request at virtual address 80c38b58
    Internal error: Oops: 8000000d [#1] PREEMPT SMP ARM
    PC is at pl011_console_match+0x0/0xfc
    LR is at register_console+0x150/0x468
    [<80187004>] (register_console)
    [<805a8184>] (uart_add_one_port)
    [<805b2b68>] (pl011_register_port)
    [<805b3ce4>] (pl011_probe)
    [<80569214>] (amba_probe)
    [<805ca088>] (really_probe)
    [<805ca2ec>] (driver_probe_device)
    [<805ca5b0>] (__device_attach_driver)
    [<805c8060>] (bus_for_each_drv)
    [<805c9dfc>] (__device_attach)
    [<805ca630>] (device_initial_probe)
    [<805c90a8>] (bus_probe_device)
    [<805c95a8>] (deferred_probe_work_func)
    
    Fixes: 10879ae5f12e ("serial: pl011: add console matching function")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: stable@vger.kernel.org # v4.10+
    Cc: Aleksey Makarov <amakarov@marvell.com>
    Cc: Peter Hurley <peter@hurleysoftware.com>
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Christopher Covington <cov@codeaurora.org>
    Link: https://lore.kernel.org/r/f827ff09da55b8c57d316a1b008a137677b58921.1597315557.git.lukas@wunner.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a0d860cbdfd5557838bd0e46052907d5dcfdeb4
Author: Tamseel Shams <m.shams@samsung.com>
Date:   Mon Aug 10 08:30:21 2020 +0530

    serial: samsung: Removes the IRQ not found warning
    
    commit 8c6c378b0cbe0c9f1390986b5f8ffb5f6ff7593b upstream.
    
    In few older Samsung SoCs like s3c2410, s3c2412
    and s3c2440, UART IP is having 2 interrupt lines.
    However, in other SoCs like s3c6400, s5pv210,
    exynos5433, and exynos4210 UART is having only 1
    interrupt line. Due to this, "platform_get_irq(platdev, 1)"
    call in the driver gives the following false-positive error:
    "IRQ index 1 not found" on newer SoC's.
    
    This patch adds the condition to check for Tx interrupt
    only for the those SoC's which have 2 interrupt lines.
    
    Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
    Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
    Signed-off-by: Tamseel Shams <m.shams@samsung.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200810030021.45348-1-m.shams@samsung.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1221d11e5c35db18323ade3d4b2130bde89cc9df
Author: George Kennedy <george.kennedy@oracle.com>
Date:   Fri Jul 31 12:33:12 2020 -0400

    vt_ioctl: change VT_RESIZEX ioctl to check for error return from vc_resize()
    
    commit bc5269ca765057a1b762e79a1cfd267cd7bf1c46 upstream.
    
    vc_resize() can return with an error after failure. Change VT_RESIZEX ioctl
    to save struct vc_data values that are modified and restore the original
    values in case of error.
    
    Signed-off-by: George Kennedy <george.kennedy@oracle.com>
    Cc: stable <stable@vger.kernel.org>
    Reported-by: syzbot+38a3699c7eaf165b97a6@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/1596213192-6635-2-git-send-email-george.kennedy@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1fe757dd3d18497eaca831ed82aa20b4186affd
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Wed Jul 29 23:57:01 2020 +0900

    vt: defer kfree() of vc_screenbuf in vc_do_resize()
    
    commit f8d1653daec02315e06d30246cff4af72e76e54e upstream.
    
    syzbot is reporting UAF bug in set_origin() from vc_do_resize() [1], for
    vc_do_resize() calls kfree(vc->vc_screenbuf) before calling set_origin().
    
    Unfortunately, in set_origin(), vc->vc_sw->con_set_origin() might access
    vc->vc_pos when scroll is involved in order to manipulate cursor, but
    vc->vc_pos refers already released vc->vc_screenbuf until vc->vc_pos gets
    updated based on the result of vc->vc_sw->con_set_origin().
    
    Preserving old buffer and tolerating outdated vc members until set_origin()
    completes would be easier than preventing vc->vc_sw->con_set_origin() from
    accessing outdated vc members.
    
    [1] https://syzkaller.appspot.com/bug?id=6649da2081e2ebdc65c0642c214b27fe91099db3
    
    Reported-by: syzbot <syzbot+9116ecc1978ca3a12f43@syzkaller.appspotmail.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1596034621-4714-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c451eae80ee291315819728e8d5a2ee0930aa25
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Wed Aug 5 12:06:43 2020 +0300

    USB: lvtest: return proper error code in probe
    
    commit 531412492ce93ea29b9ca3b4eb5e3ed771f851dd upstream.
    
    lvs_rh_probe() can return some nonnegative value from usb_control_msg()
    when it is less than "USB_DT_HUB_NONVAR_SIZE + 2" that is considered as
    a failure. Make lvs_rh_probe() return -EINVAL in this case.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200805090643.3432-1-novikov@ispras.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72f099805dbc907fbe8fa19bccdc31d3e2ee6e9e
Author: George Kennedy <george.kennedy@oracle.com>
Date:   Fri Jul 31 12:33:11 2020 -0400

    fbcon: prevent user font height or width change from causing potential out-of-bounds access
    
    commit 39b3cffb8cf3111738ea993e2757ab382253d86a upstream.
    
    Add a check to fbcon_resize() to ensure that a possible change to user font
    height or user font width will not allow a font data out-of-bounds access.
    NOTE: must use original charcount in calculation as font charcount can
    change and cannot be used to determine the font data allocated size.
    
    Signed-off-by: George Kennedy <george.kennedy@oracle.com>
    Cc: stable <stable@vger.kernel.org>
    Reported-by: syzbot+38a3699c7eaf165b97a6@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/1596213192-6635-1-git-send-email-george.kennedy@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0186a11dfe7b2ee767b4e7acfea921594ecdb7f
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Aug 14 11:04:09 2020 +0100

    btrfs: fix space cache memory leak after transaction abort
    
    commit bbc37d6e475eee8ffa2156ec813efc6bbb43c06d upstream.
    
    If a transaction aborts it can cause a memory leak of the pages array of
    a block group's io_ctl structure. The following steps explain how that can
    happen:
    
    1) Transaction N is committing, currently in state TRANS_STATE_UNBLOCKED
       and it's about to start writing out dirty extent buffers;
    
    2) Transaction N + 1 already started and another task, task A, just called
       btrfs_commit_transaction() on it;
    
    3) Block group B was dirtied (extents allocated from it) by transaction
       N + 1, so when task A calls btrfs_start_dirty_block_groups(), at the
       very beginning of the transaction commit, it starts writeback for the
       block group's space cache by calling btrfs_write_out_cache(), which
       allocates the pages array for the block group's io_ctl with a call to
       io_ctl_init(). Block group A is added to the io_list of transaction
       N + 1 by btrfs_start_dirty_block_groups();
    
    4) While transaction N's commit is writing out the extent buffers, it gets
       an IO error and aborts transaction N, also setting the file system to
       RO mode;
    
    5) Task A has already returned from btrfs_start_dirty_block_groups(), is at
       btrfs_commit_transaction() and has set transaction N + 1 state to
       TRANS_STATE_COMMIT_START. Immediately after that it checks that the
       filesystem was turned to RO mode, due to transaction N's abort, and
       jumps to the "cleanup_transaction" label. After that we end up at
       btrfs_cleanup_one_transaction() which calls btrfs_cleanup_dirty_bgs().
       That helper finds block group B in the transaction's io_list but it
       never releases the pages array of the block group's io_ctl, resulting in
       a memory leak.
    
    In fact at the point when we are at btrfs_cleanup_dirty_bgs(), the pages
    array points to pages that were already released by us at
    __btrfs_write_out_cache() through the call to io_ctl_drop_pages(). We end
    up freeing the pages array only after waiting for the ordered extent to
    complete through btrfs_wait_cache_io(), which calls io_ctl_free() to do
    that. But in the transaction abort case we don't wait for the space cache's
    ordered extent to complete through a call to btrfs_wait_cache_io(), so
    that's why we end up with a memory leak - we wait for the ordered extent
    to complete indirectly by shutting down the work queues and waiting for
    any jobs in them to complete before returning from close_ctree().
    
    We can solve the leak simply by freeing the pages array right after
    releasing the pages (with the call to io_ctl_drop_pages()) at
    __btrfs_write_out_cache(), since we will never use it anymore after that
    and the pages array points to already released pages at that point, which
    is currently not a problem since no one will use it after that, but not a
    good practice anyway since it can easily lead to use-after-free issues.
    
    So fix this by freeing the pages array right after releasing the pages at
    __btrfs_write_out_cache().
    
    This issue can often be reproduced with test case generic/475 from fstests
    and kmemleak can detect it and reports it with the following trace:
    
    unreferenced object 0xffff9bbf009fa600 (size 512):
      comm "fsstress", pid 38807, jiffies 4298504428 (age 22.028s)
      hex dump (first 32 bytes):
        00 a0 7c 4d 3d ed ff ff 40 a0 7c 4d 3d ed ff ff  ..|M=...@.|M=...
        80 a0 7c 4d 3d ed ff ff c0 a0 7c 4d 3d ed ff ff  ..|M=.....|M=...
      backtrace:
        [<00000000f4b5cfe2>] __kmalloc+0x1a8/0x3e0
        [<0000000028665e7f>] io_ctl_init+0xa7/0x120 [btrfs]
        [<00000000a1f95b2d>] __btrfs_write_out_cache+0x86/0x4a0 [btrfs]
        [<00000000207ea1b0>] btrfs_write_out_cache+0x7f/0xf0 [btrfs]
        [<00000000af21f534>] btrfs_start_dirty_block_groups+0x27b/0x580 [btrfs]
        [<00000000c3c23d44>] btrfs_commit_transaction+0xa6f/0xe70 [btrfs]
        [<000000009588930c>] create_subvol+0x581/0x9a0 [btrfs]
        [<000000009ef2fd7f>] btrfs_mksubvol+0x3fb/0x4a0 [btrfs]
        [<00000000474e5187>] __btrfs_ioctl_snap_create+0x119/0x1a0 [btrfs]
        [<00000000708ee349>] btrfs_ioctl_snap_create_v2+0xb0/0xf0 [btrfs]
        [<00000000ea60106f>] btrfs_ioctl+0x12c/0x3130 [btrfs]
        [<000000005c923d6d>] __x64_sys_ioctl+0x83/0xb0
        [<0000000043ace2c9>] do_syscall_64+0x33/0x80
        [<00000000904efbce>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    CC: stable@vger.kernel.org # 4.9+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    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 ee203be4dff5c1500ac2989306d0eab0aad1d0dd
Author: Marcos Paulo de Souza <mpdesouza@suse.com>
Date:   Mon Aug 3 16:55:01 2020 -0300

    btrfs: reset compression level for lzo on remount
    
    commit 282dd7d7718444679b046b769d872b188818ca35 upstream.
    
    Currently a user can set mount "-o compress" which will set the
    compression algorithm to zlib, and use the default compress level for
    zlib (3):
    
      relatime,compress=zlib:3,space_cache
    
    If the user remounts the fs using "-o compress=lzo", then the old
    compress_level is used:
    
      relatime,compress=lzo:3,space_cache
    
    But lzo does not expose any tunable compression level. The same happens
    if we set any compress argument with different level, also with zstd.
    
    Fix this by resetting the compress_level when compress=lzo is
    specified.  With the fix applied, lzo is shown without compress level:
    
      relatime,compress=lzo,space_cache
    
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Marcos Paulo de Souza <mpdesouza@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 77064570e4c3636da26f30ed28e4d132256424ec
Author: Ming Lei <ming.lei@redhat.com>
Date:   Mon Aug 17 18:01:15 2020 +0800

    blk-mq: order adding requests to hctx->dispatch and checking SCHED_RESTART
    
    commit d7d8535f377e9ba87edbf7fbbd634ac942f3f54f upstream.
    
    SCHED_RESTART code path is relied to re-run queue for dispatch requests
    in hctx->dispatch. Meantime the SCHED_RSTART flag is checked when adding
    requests to hctx->dispatch.
    
    memory barriers have to be used for ordering the following two pair of OPs:
    
    1) adding requests to hctx->dispatch and checking SCHED_RESTART in
    blk_mq_dispatch_rq_list()
    
    2) clearing SCHED_RESTART and checking if there is request in hctx->dispatch
    in blk_mq_sched_restart().
    
    Without the added memory barrier, either:
    
    1) blk_mq_sched_restart() may miss requests added to hctx->dispatch meantime
    blk_mq_dispatch_rq_list() observes SCHED_RESTART, and not run queue in
    dispatch side
    
    or
    
    2) blk_mq_dispatch_rq_list still sees SCHED_RESTART, and not run queue
    in dispatch side, meantime checking if there is request in
    hctx->dispatch from blk_mq_sched_restart() is missed.
    
    IO hang in ltp/fs_fill test is reported by kernel test robot:
    
            https://lkml.org/lkml/2020/7/26/77
    
    Turns out it is caused by the above out-of-order OPs. And the IO hang
    can't be observed any more after applying this patch.
    
    Fixes: bd166ef183c2 ("blk-mq-sched: add framework for MQ capable IO schedulers")
    Reported-by: kernel test robot <rong.a.chen@intel.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Cc: Bart Van Assche <bvanassche@acm.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: David Jeffery <djeffery@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30028c328b82f00c19c1ef800b3026abff7ca982
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Aug 11 15:39:58 2020 +0200

    HID: i2c-hid: Always sleep 60ms after I2C_HID_PWR_ON commands
    
    commit eef4016243e94c438f177ca8226876eb873b9c75 upstream.
    
    Before this commit i2c_hid_parse() consists of the following steps:
    
    1. Send power on cmd
    2. usleep_range(1000, 5000)
    3. Send reset cmd
    4. Wait for reset to complete (device interrupt, or msleep(100))
    5. Send power on cmd
    6. Try to read HID descriptor
    
    Notice how there is an usleep_range(1000, 5000) after the first power-on
    command, but not after the second power-on command.
    
    Testing has shown that at least on the BMAX Y13 laptop's i2c-hid touchpad,
    not having a delay after the second power-on command causes the HID
    descriptor to read as all zeros.
    
    In case we hit this on other devices too, the descriptor being all zeros
    can be recognized by the following message being logged many, many times:
    
    hid-generic 0018:0911:5288.0002: unknown main item tag 0x0
    
    At the same time as the BMAX Y13's touchpad issue was debugged,
    Kai-Heng was working on debugging some issues with Goodix i2c-hid
    touchpads. It turns out that these need a delay after a PWR_ON command
    too, otherwise they stop working after a suspend/resume cycle.
    According to Goodix a delay of minimal 60ms is needed.
    
    Having multiple cases where we need a delay after sending the power-on
    command, seems to indicate that we should always sleep after the power-on
    command.
    
    This commit fixes the mentioned issues by moving the existing 1ms sleep to
    the i2c_hid_set_power() function and changing it to a 60ms sleep.
    
    Cc: stable@vger.kernel.org
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208247
    Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Reported-and-tested-by: Andrea Borgia <andrea@borgia.bo.it>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e7f61593b781c74d764b0c9bba1451161ffac1d
Author: Ming Lei <ming.lei@redhat.com>
Date:   Mon Aug 17 18:01:30 2020 +0800

    block: loop: set discard granularity and alignment for block device backed loop
    
    commit bcb21c8cc9947286211327d663ace69f07d37a76 upstream.
    
    In case of block device backend, if the backend supports write zeros, the
    loop device will set queue flag of QUEUE_FLAG_DISCARD. However,
    limits.discard_granularity isn't setup, and this way is wrong,
    see the following description in Documentation/ABI/testing/sysfs-block:
    
            A discard_granularity of 0 means that the device does not support
            discard functionality.
    
    Especially 9b15d109a6b2 ("block: improve discard bio alignment in
    __blkdev_issue_discard()") starts to take q->limits.discard_granularity
    for computing max discard sectors. And zero discard granularity may cause
    kernel oops, or fail discard request even though the loop queue claims
    discard support via QUEUE_FLAG_DISCARD.
    
    Fix the issue by setup discard granularity and alignment.
    
    Fixes: c52abf563049 ("loop: Better discard support for block devices")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Coly Li <colyli@suse.de>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Xiao Ni <xni@redhat.com>
    Cc: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: Evan Green <evgreen@chromium.org>
    Cc: Gwendal Grignou <gwendal@chromium.org>
    Cc: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bcaa460435cb332181fbefa4cf2136d4bdf9fd85
Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Date:   Thu Aug 6 08:46:32 2020 -0400

    powerpc/perf: Fix soft lockups due to missed interrupt accounting
    
    [ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]
    
    Performance monitor interrupt handler checks if any counter has
    overflown and calls record_and_restart() in core-book3s which invokes
    perf_event_overflow() to record the sample information. Apart from
    creating sample, perf_event_overflow() also does the interrupt and
    period checks via perf_event_account_interrupt().
    
    Currently we record information only if the SIAR (Sampled Instruction
    Address Register) valid bit is set (using siar_valid() check) and
    hence the interrupt check.
    
    But it is possible that we do sampling for some events that are not
    generating valid SIAR, and hence there is no chance to disable the
    event if interrupts are more than max_samples_per_tick. This leads to
    soft lockup.
    
    Fix this by adding perf_event_account_interrupt() in the invalid SIAR
    code path for a sampling event. ie if SIAR is invalid, just do
    interrupt check and don't record the sample information.
    
    Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50b83d19ab3f9a07a70d0bb6d8efb66bff970a4f
Author: Sumera Priyadarsini <sylphrenadin@gmail.com>
Date:   Wed Aug 19 00:22:41 2020 +0530

    net: gianfar: Add of_node_put() before goto statement
    
    [ Upstream commit 989e4da042ca4a56bbaca9223d1a93639ad11e17 ]
    
    Every iteration of for_each_available_child_of_node() decrements
    reference count of the previous node, however when control
    is transferred from the middle of the loop, as in the case of
    a return or break or goto, there is no decrement thus ultimately
    resulting in a memory leak.
    
    Fix a potential memory leak in gianfar.c by inserting of_node_put()
    before the goto statement.
    
    Issue found with Coccinelle.
    
    Signed-off-by: Sumera Priyadarsini <sylphrenadin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b12151989d2930328b85419c20037a0c9769ef52
Author: Alvin Å ipraga <alsi@bang-olufsen.dk>
Date:   Tue Aug 18 10:51:34 2020 +0200

    macvlan: validate setting of multiple remote source MAC addresses
    
    [ Upstream commit 8b61fba503904acae24aeb2bd5569b4d6544d48f ]
    
    Remote source MAC addresses can be set on a 'source mode' macvlan
    interface via the IFLA_MACVLAN_MACADDR_DATA attribute. This commit
    tightens the validation of these MAC addresses to match the validation
    already performed when setting or adding a single MAC address via the
    IFLA_MACVLAN_MACADDR attribute.
    
    iproute2 uses IFLA_MACVLAN_MACADDR_DATA for its 'macvlan macaddr set'
    command, and IFLA_MACVLAN_MACADDR for its 'macvlan macaddr add' command,
    which demonstrates the inconsistent behaviour that this commit
    addresses:
    
     # ip link add link eth0 name macvlan0 type macvlan mode source
     # ip link set link dev macvlan0 type macvlan macaddr add 01:00:00:00:00:00
     RTNETLINK answers: Cannot assign requested address
     # ip link set link dev macvlan0 type macvlan macaddr set 01:00:00:00:00:00
     # ip -d link show macvlan0
     5: macvlan0@eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 ...
         link/ether 2e:ac:fd:2d:69:f8 brd ff:ff:ff:ff:ff:ff promiscuity 0
         macvlan mode source remotes (1) 01:00:00:00:00:00 numtxqueues 1 ...
    
    With this change, the 'set' command will (rightly) fail in the same way
    as the 'add' command.
    
    Signed-off-by: Alvin Å ipraga <alsi@bang-olufsen.dk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d1a5f56ac7b74e78a25a43e0fa59fad6f79d570
Author: Saurav Kashyap <skashyap@marvell.com>
Date:   Thu Aug 6 04:10:13 2020 -0700

    Revert "scsi: qla2xxx: Fix crash on qla2x00_mailbox_command"
    
    [ Upstream commit de7e6194301ad31c4ce95395eb678e51a1b907e5 ]
    
    FCoE adapter initialization failed for ISP8021 with the following patch
    applied. In addition, reproduction of the issue the patch originally tried
    to address has been unsuccessful.
    
    This reverts commit 3cb182b3fa8b7a61f05c671525494697cba39c6a.
    
    Link: https://lore.kernel.org/r/20200806111014.28434-11-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f92ff03ee69f3d7e937a4c7421c478232fc55a78
Author: Quinn Tran <qutran@marvell.com>
Date:   Thu Aug 6 04:10:12 2020 -0700

    scsi: qla2xxx: Fix null pointer access during disconnect from subsystem
    
    [ Upstream commit 83949613fac61e8e37eadf8275bf072342302f4e ]
    
    NVMEAsync command is being submitted to QLA while the same NVMe controller
    is in the middle of reset. The reset path has deleted the association and
    freed aen_op->fcp_req.private. Add a check for this private pointer before
    issuing the command.
    
    ...
     6 [ffffb656ca11fce0] page_fault at ffffffff8c00114e
        [exception RIP: qla_nvme_post_cmd+394]
        RIP: ffffffffc0d012ba  RSP: ffffb656ca11fd98  RFLAGS: 00010206
        RAX: ffff8fb039eda228  RBX: ffff8fb039eda200  RCX: 00000000000da161
        RDX: ffffffffc0d4d0f0  RSI: ffffffffc0d26c9b  RDI: ffff8fb039eda220
        RBP: 0000000000000013   R8: ffff8fb47ff6aa80   R9: 0000000000000002
        R10: 0000000000000000  R11: ffffb656ca11fdc8  R12: ffff8fb27d04a3b0
        R13: ffff8fc46dd98a58  R14: 0000000000000000  R15: ffff8fc4540f0000
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
     7 [ffffb656ca11fe08] nvme_fc_start_fcp_op at ffffffffc0241568 [nvme_fc]
     8 [ffffb656ca11fe50] nvme_fc_submit_async_event at ffffffffc0241901 [nvme_fc]
     9 [ffffb656ca11fe68] nvme_async_event_work at ffffffffc014543d [nvme_core]
    10 [ffffb656ca11fe98] process_one_work at ffffffff8b6cd437
    11 [ffffb656ca11fed8] worker_thread at ffffffff8b6cdcef
    12 [ffffb656ca11ff10] kthread at ffffffff8b6d3402
    13 [ffffb656ca11ff50] ret_from_fork at ffffffff8c000255
    
    --
    PID: 37824  TASK: ffff8fb033063d80  CPU: 20  COMMAND: "kworker/u97:451"
     0 [ffffb656ce1abc28] __schedule at ffffffff8be629e3
     1 [ffffb656ce1abcc8] schedule at ffffffff8be62fe8
     2 [ffffb656ce1abcd0] schedule_timeout at ffffffff8be671ed
     3 [ffffb656ce1abd70] wait_for_completion at ffffffff8be639cf
     4 [ffffb656ce1abdd0] flush_work at ffffffff8b6ce2d5
     5 [ffffb656ce1abe70] nvme_stop_ctrl at ffffffffc0144900 [nvme_core]
     6 [ffffb656ce1abe80] nvme_fc_reset_ctrl_work at ffffffffc0243445 [nvme_fc]
     7 [ffffb656ce1abe98] process_one_work at ffffffff8b6cd437
     8 [ffffb656ce1abed8] worker_thread at ffffffff8b6cdb50
     9 [ffffb656ce1abf10] kthread at ffffffff8b6d3402
    10 [ffffb656ce1abf50] ret_from_fork at ffffffff8c000255
    
    Link: https://lore.kernel.org/r/20200806111014.28434-10-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aba997482bc5304d90b3adf42527089ac6d02c02
Author: Saurav Kashyap <skashyap@marvell.com>
Date:   Thu Aug 6 04:10:11 2020 -0700

    scsi: qla2xxx: Check if FW supports MQ before enabling
    
    [ Upstream commit dffa11453313a115157b19021cc2e27ea98e624c ]
    
    OS boot during Boot from SAN was stuck at dracut emergency shell after
    enabling NVMe driver parameter. For non-MQ support the driver was enabling
    MQ. Add a check to confirm if FW supports MQ.
    
    Link: https://lore.kernel.org/r/20200806111014.28434-9-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 023e0e6bd2d91ffff61cd040cece6f31bb826a38
Author: Stanley Chu <stanley.chu@mediatek.com>
Date:   Tue Aug 11 16:18:58 2020 +0200

    scsi: ufs: Clean up completed request without interrupt notification
    
    [ Upstream commit b10178ee7fa88b68a9e8adc06534d2605cb0ec23 ]
    
    If somehow no interrupt notification is raised for a completed request and
    its doorbell bit is cleared by host, UFS driver needs to cleanup its
    outstanding bit in ufshcd_abort(). Otherwise, system may behave abnormally
    in the following scenario:
    
    After ufshcd_abort() returns, this request will be requeued by SCSI layer
    with its outstanding bit set. Any future completed request will trigger
    ufshcd_transfer_req_compl() to handle all "completed outstanding bits". At
    this time the "abnormal outstanding bit" will be detected and the "requeued
    request" will be chosen to execute request post-processing flow. This is
    wrong because this request is still "alive".
    
    Link: https://lore.kernel.org/r/20200811141859.27399-2-huobean@gmail.com
    Reviewed-by: Can Guo <cang@codeaurora.org>
    Acked-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
    Signed-off-by: Bean Huo <beanhuo@micron.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31871fb7adca15a0c60e723bad673802ce647932
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Aug 11 16:39:36 2020 +0300

    scsi: ufs: Improve interrupt handling for shared interrupts
    
    [ Upstream commit 127d5f7c4b653b8be5eb3b2c7bbe13728f9003ff ]
    
    For shared interrupts, the interrupt status might be zero, so check that
    first.
    
    Link: https://lore.kernel.org/r/20200811133936.19171-2-adrian.hunter@intel.com
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f76a208c2f439c02fc5e25fef0790938662e723
Author: Stanley Chu <stanley.chu@mediatek.com>
Date:   Sun Aug 9 13:07:34 2020 +0800

    scsi: ufs: Fix possible infinite loop in ufshcd_hold
    
    [ Upstream commit 93b6c5db06028a3b55122bbb74d0715dd8ca4ae0 ]
    
    In ufshcd_suspend(), after clk-gating is suspended and link is set
    as Hibern8 state, ufshcd_hold() is still possibly invoked before
    ufshcd_suspend() returns. For example, MediaTek's suspend vops may
    issue UIC commands which would call ufshcd_hold() during the command
    issuing flow.
    
    Now if UFSHCD_CAP_HIBERN8_WITH_CLK_GATING capability is enabled,
    then ufshcd_hold() may enter infinite loops because there is no
    clk-ungating work scheduled or pending. In this case, ufshcd_hold()
    shall just bypass, and keep the link as Hibern8 state.
    
    Link: https://lore.kernel.org/r/20200809050734.18740-1-stanley.chu@mediatek.com
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Co-developed-by: Andy Teng <andy.teng@mediatek.com>
    Signed-off-by: Andy Teng <andy.teng@mediatek.com>
    Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2229e50f25a5d9e6fa9aa263530978a8c83ff944
Author: Mike Christie <michael.christie@oracle.com>
Date:   Fri Aug 7 15:23:33 2020 -0500

    scsi: fcoe: Fix I/O path allocation
    
    [ Upstream commit fa39ab5184d64563cd36f2fb5f0d3fbad83a432c ]
    
    ixgbe_fcoe_ddp_setup() can be called from the main I/O path and is called
    with a spin_lock held, so we have to use GFP_ATOMIC allocation instead of
    GFP_KERNEL.
    
    Link: https://lore.kernel.org/r/1596831813-9839-1-git-send-email-michael.christie@oracle.com
    cc: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00963a85dbb6f01001e4adf0f8145232221e4874
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Fri Jul 31 19:38:34 2020 +0200

    ASoC: wm8994: Avoid attempts to read unreadable registers
    
    [ Upstream commit f082bb59b72039a2326ec1a44496899fb8aa6d0e ]
    
    The driver supports WM1811, WM8994, WM8958 devices but according to
    documentation and the regmap definitions the WM8958_DSP2_* registers
    are only available on WM8958. In current code these registers are
    being accessed as if they were available on all the three chips.
    
    When starting playback on WM1811 CODEC multiple errors like:
    "wm8994-codec wm8994-codec: ASoC: error at soc_component_read_no_lock on wm8994-codec: -5"
    can be seen, which is caused by attempts to read an unavailable
    WM8958_DSP2_PROGRAM register. The issue has been uncovered by recent
    commit "e2329ee ASoC: soc-component: add soc_component_err()".
    
    This patch adds a check in wm8958_aif_ev() callback so the DSP2 handling
    is only done for WM8958.
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20200731173834.23832-1-s.nawrocki@samsung.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 017d36c59ca80898314a18c23e28f4045415f3b8
Author: Vineeth Vijayan <vneethv@linux.ibm.com>
Date:   Thu Jun 18 16:42:45 2020 +0200

    s390/cio: add cond_resched() in the slow_eval_known_fn() loop
    
    [ Upstream commit 0b8eb2ee9da1e8c9b8082f404f3948aa82a057b2 ]
    
    The scanning through subchannels during the time of an event could
    take significant amount of time in case of platforms with lots of
    known subchannels. This might result in higher scheduling latencies
    for other tasks especially on systems with a single CPU. Add
    cond_resched() call, as the loop in slow_eval_known_fn() can be
    executed for a longer duration.
    
    Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca57f450507548d2eb14a15764e0f159c784c842
Author: Amelie Delaunay <amelie.delaunay@st.com>
Date:   Mon Aug 10 09:12:36 2020 +0200

    spi: stm32: fix stm32_spi_prepare_mbr in case of odd clk_rate
    
    [ Upstream commit 9cc61973bf9385b19ff5dda4a2a7e265fcba85e4 ]
    
    Fix spi->clk_rate when it is odd to the nearest lowest even value because
    minimum SPI divider is 2.
    
    Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
    Signed-off-by: Alain Volmat <alain.volmat@st.com>
    Link: https://lore.kernel.org/r/1597043558-29668-4-git-send-email-alain.volmat@st.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4aaac9c537b79ffd0602db06cd5127a455e49275
Author: Xianting Tian <xianting_tian@126.com>
Date:   Fri Jul 31 12:10:25 2020 -0400

    fs: prevent BUG_ON in submit_bh_wbc()
    
    [ Upstream commit 377254b2cd2252c7c3151b113cbdf93a7736c2e9 ]
    
    If a device is hot-removed --- for example, when a physical device is
    unplugged from pcie slot or a nbd device's network is shutdown ---
    this can result in a BUG_ON() crash in submit_bh_wbc().  This is
    because the when the block device dies, the buffer heads will have
    their Buffer_Mapped flag get cleared, leading to the crash in
    submit_bh_wbc.
    
    We had attempted to work around this problem in commit a17712c8
    ("ext4: check superblock mapped prior to committing").  Unfortunately,
    it's still possible to hit the BUG_ON(!buffer_mapped(bh)) if the
    device dies between when the work-around check in ext4_commit_super()
    and when submit_bh_wbh() is finally called:
    
    Code path:
    ext4_commit_super
        judge if 'buffer_mapped(sbh)' is false, return <== commit a17712c8
              lock_buffer(sbh)
              ...
              unlock_buffer(sbh)
                   __sync_dirty_buffer(sbh,...
                        lock_buffer(sbh)
                            judge if 'buffer_mapped(sbh))' is false, return <== added by this patch
                                submit_bh(...,sbh)
                                    submit_bh_wbc(...,sbh,...)
    
    [100722.966497] kernel BUG at fs/buffer.c:3095! <== BUG_ON(!buffer_mapped(bh))' in submit_bh_wbc()
    [100722.966503] invalid opcode: 0000 [#1] SMP
    [100722.966566] task: ffff8817e15a9e40 task.stack: ffffc90024744000
    [100722.966574] RIP: 0010:submit_bh_wbc+0x180/0x190
    [100722.966575] RSP: 0018:ffffc90024747a90 EFLAGS: 00010246
    [100722.966576] RAX: 0000000000620005 RBX: ffff8818a80603a8 RCX: 0000000000000000
    [100722.966576] RDX: ffff8818a80603a8 RSI: 0000000000020800 RDI: 0000000000000001
    [100722.966577] RBP: ffffc90024747ac0 R08: 0000000000000000 R09: ffff88207f94170d
    [100722.966578] R10: 00000000000437c8 R11: 0000000000000001 R12: 0000000000020800
    [100722.966578] R13: 0000000000000001 R14: 000000000bf9a438 R15: ffff88195f333000
    [100722.966580] FS:  00007fa2eee27700(0000) GS:ffff88203d840000(0000) knlGS:0000000000000000
    [100722.966580] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [100722.966581] CR2: 0000000000f0b008 CR3: 000000201a622003 CR4: 00000000007606e0
    [100722.966582] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [100722.966583] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [100722.966583] PKRU: 55555554
    [100722.966583] Call Trace:
    [100722.966588]  __sync_dirty_buffer+0x6e/0xd0
    [100722.966614]  ext4_commit_super+0x1d8/0x290 [ext4]
    [100722.966626]  __ext4_std_error+0x78/0x100 [ext4]
    [100722.966635]  ? __ext4_journal_get_write_access+0xca/0x120 [ext4]
    [100722.966646]  ext4_reserve_inode_write+0x58/0xb0 [ext4]
    [100722.966655]  ? ext4_dirty_inode+0x48/0x70 [ext4]
    [100722.966663]  ext4_mark_inode_dirty+0x53/0x1e0 [ext4]
    [100722.966671]  ? __ext4_journal_start_sb+0x6d/0xf0 [ext4]
    [100722.966679]  ext4_dirty_inode+0x48/0x70 [ext4]
    [100722.966682]  __mark_inode_dirty+0x17f/0x350
    [100722.966686]  generic_update_time+0x87/0xd0
    [100722.966687]  touch_atime+0xa9/0xd0
    [100722.966690]  generic_file_read_iter+0xa09/0xcd0
    [100722.966694]  ? page_cache_tree_insert+0xb0/0xb0
    [100722.966704]  ext4_file_read_iter+0x4a/0x100 [ext4]
    [100722.966707]  ? __inode_security_revalidate+0x4f/0x60
    [100722.966709]  __vfs_read+0xec/0x160
    [100722.966711]  vfs_read+0x8c/0x130
    [100722.966712]  SyS_pread64+0x87/0xb0
    [100722.966716]  do_syscall_64+0x67/0x1b0
    [100722.966719]  entry_SYSCALL64_slow_path+0x25/0x25
    
    To address this, add the check of 'buffer_mapped(bh)' to
    __sync_dirty_buffer().  This also has the benefit of fixing this for
    other file systems.
    
    With this addition, we can drop the workaround in ext4_commit_supper().
    
    [ Commit description rewritten by tytso. ]
    
    Signed-off-by: Xianting Tian <xianting_tian@126.com>
    Link: https://lore.kernel.org/r/1596211825-8750-1-git-send-email-xianting_tian@126.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f6858a3b9361ca9ff89cc2b9cdc3cf3b9bee356
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 28 15:04:37 2020 +0200

    ext4: correctly restore system zone info when remount fails
    
    [ Upstream commit 0f5bde1db174f6c471f0bd27198575719dabe3e5 ]
    
    When remounting filesystem fails late during remount handling and
    block_validity mount option is also changed during the remount, we fail
    to restore system zone information to a state matching the mount option.
    This is mostly harmless, just the block validity checking will not match
    the situation described by the mount option. Make sure these two are always
    consistent.
    
    Reported-by: Lukas Czerner <lczerner@redhat.com>
    Reviewed-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20200728130437.7804-7-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c279f7a44fd3d1554561efb71340302a6b005ce9
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 28 15:04:32 2020 +0200

    ext4: handle error of ext4_setup_system_zone() on remount
    
    [ Upstream commit d176b1f62f242ab259ff665a26fbac69db1aecba ]
    
    ext4_setup_system_zone() can fail. Handle the failure in ext4_remount().
    
    Reviewed-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20200728130437.7804-2-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bfb8d9b74750e7c9b12f9e18b4885617a6433f6d
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Thu Jul 23 17:05:26 2020 +0200

    ext4: handle option set by mount flags correctly
    
    [ Upstream commit f25391ebb475d3ffb3aa61bb90e3594c841749ef ]
    
    Currently there is a problem with mount options that can be both set by
    vfs using mount flags or by a string parsing in ext4.
    
    i_version/iversion options gets lost after remount, for example
    
    $ mount -o i_version /dev/pmem0 /mnt
    $ grep pmem0 /proc/self/mountinfo | grep i_version
    310 95 259:0 / /mnt rw,relatime shared:163 - ext4 /dev/pmem0 rw,seclabel,i_version
    $ mount -o remount,ro /mnt
    $ grep pmem0 /proc/self/mountinfo | grep i_version
    
    nolazytime gets ignored by ext4 on remount, for example
    
    $ mount -o lazytime /dev/pmem0 /mnt
    $ grep pmem0 /proc/self/mountinfo | grep lazytime
    310 95 259:0 / /mnt rw,relatime shared:163 - ext4 /dev/pmem0 rw,lazytime,seclabel
    $ mount -o remount,nolazytime /mnt
    $ grep pmem0 /proc/self/mountinfo | grep lazytime
    310 95 259:0 / /mnt rw,relatime shared:163 - ext4 /dev/pmem0 rw,lazytime,seclabel
    
    Fix it by applying the SB_LAZYTIME and SB_I_VERSION flags from *flags to
    s_flags before we parse the option and use the resulting state of the
    same flags in *flags at the end of successful remount.
    
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com>
    Link: https://lore.kernel.org/r/20200723150526.19931-1-lczerner@redhat.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8eed535dada298f74806d4d91948305a4cea1d5f
Author: zhangyi (F) <yi.zhang@huawei.com>
Date:   Sat Jun 20 10:54:26 2020 +0800

    jbd2: abort journal if free a async write error metadata buffer
    
    [ Upstream commit c044f3d8360d2ecf831ba2cc9f08cf9fb2c699fb ]
    
    If we free a metadata buffer which has been failed to async write out
    in the background, the jbd2 checkpoint procedure will not detect this
    failure in jbd2_log_do_checkpoint(), so it may lead to filesystem
    inconsistency after cleanup journal tail. This patch abort the journal
    if free a buffer has write_io_error flag to prevent potential further
    inconsistency.
    
    Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
    Link: https://lore.kernel.org/r/20200620025427.1756360-5-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47788043e5fa6415fa9ff0b4af217079b06815af
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Fri Jul 17 11:06:05 2020 +0200

    ext4: handle read only external journal device
    
    [ Upstream commit 273108fa5015eeffc4bacfa5ce272af3434b96e4 ]
    
    Ext4 uses blkdev_get_by_dev() to get the block_device for journal device
    which does check to see if the read-only block device was opened
    read-only.
    
    As a result ext4 will hapily proceed mounting the file system with
    external journal on read-only device. This is bad as we would not be
    able to use the journal leading to errors later on.
    
    Instead of simply failing to mount file system in this case, treat it in
    a similar way we treat internal journal on read-only device. Allow to
    mount with -o noload in read-only mode.
    
    This can be reproduced easily like this:
    
    mke2fs -F -O journal_dev $JOURNAL_DEV 100M
    mkfs.$FSTYPE -F -J device=$JOURNAL_DEV $FS_DEV
    blockdev --setro $JOURNAL_DEV
    mount $FS_DEV $MNT
    touch $MNT/file
    umount $MNT
    
    leading to error like this
    
    [ 1307.318713] ------------[ cut here ]------------
    [ 1307.323362] generic_make_request: Trying to write to read-only block-device dm-2 (partno 0)
    [ 1307.331741] WARNING: CPU: 36 PID: 3224 at block/blk-core.c:855 generic_make_request_checks+0x2c3/0x580
    [ 1307.341041] Modules linked in: ext4 mbcache jbd2 rfkill intel_rapl_msr intel_rapl_common isst_if_commd
    [ 1307.419445] CPU: 36 PID: 3224 Comm: jbd2/dm-2 Tainted: G        W I       5.8.0-rc5 #2
    [ 1307.427359] Hardware name: Dell Inc. PowerEdge R740/01KPX8, BIOS 2.3.10 08/15/2019
    [ 1307.434932] RIP: 0010:generic_make_request_checks+0x2c3/0x580
    [ 1307.440676] Code: 94 03 00 00 48 89 df 48 8d 74 24 08 c6 05 cf 2b 18 01 01 e8 7f a4 ff ff 48 c7 c7 50e
    [ 1307.459420] RSP: 0018:ffffc0d70eb5fb48 EFLAGS: 00010286
    [ 1307.464646] RAX: 0000000000000000 RBX: ffff9b33b2978300 RCX: 0000000000000000
    [ 1307.471780] RDX: ffff9b33e12a81e0 RSI: ffff9b33e1298000 RDI: ffff9b33e1298000
    [ 1307.478913] RBP: ffff9b7b9679e0c0 R08: 0000000000000837 R09: 0000000000000024
    [ 1307.486044] R10: 0000000000000000 R11: ffffc0d70eb5f9f0 R12: 0000000000000400
    [ 1307.493177] R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000
    [ 1307.500308] FS:  0000000000000000(0000) GS:ffff9b33e1280000(0000) knlGS:0000000000000000
    [ 1307.508396] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 1307.514142] CR2: 000055eaf4109000 CR3: 0000003dee40a006 CR4: 00000000007606e0
    [ 1307.521273] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 1307.528407] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 1307.535538] PKRU: 55555554
    [ 1307.538250] Call Trace:
    [ 1307.540708]  generic_make_request+0x30/0x340
    [ 1307.544985]  submit_bio+0x43/0x190
    [ 1307.548393]  ? bio_add_page+0x62/0x90
    [ 1307.552068]  submit_bh_wbc+0x16a/0x190
    [ 1307.555833]  jbd2_write_superblock+0xec/0x200 [jbd2]
    [ 1307.560803]  jbd2_journal_update_sb_log_tail+0x65/0xc0 [jbd2]
    [ 1307.566557]  jbd2_journal_commit_transaction+0x2ae/0x1860 [jbd2]
    [ 1307.572566]  ? check_preempt_curr+0x7a/0x90
    [ 1307.576756]  ? update_curr+0xe1/0x1d0
    [ 1307.580421]  ? account_entity_dequeue+0x7b/0xb0
    [ 1307.584955]  ? newidle_balance+0x231/0x3d0
    [ 1307.589056]  ? __switch_to_asm+0x42/0x70
    [ 1307.592986]  ? __switch_to_asm+0x36/0x70
    [ 1307.596918]  ? lock_timer_base+0x67/0x80
    [ 1307.600851]  kjournald2+0xbd/0x270 [jbd2]
    [ 1307.604873]  ? finish_wait+0x80/0x80
    [ 1307.608460]  ? commit_timeout+0x10/0x10 [jbd2]
    [ 1307.612915]  kthread+0x114/0x130
    [ 1307.616152]  ? kthread_park+0x80/0x80
    [ 1307.619816]  ret_from_fork+0x22/0x30
    [ 1307.623400] ---[ end trace 27490236265b1630 ]---
    
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Link: https://lore.kernel.org/r/20200717090605.2612-1-lczerner@redhat.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a6d49257cbe53c7bca1a0353a6443f53cbed9cc7
Author: Jan Kara <jack@suse.cz>
Date:   Fri Jul 10 16:07:59 2020 +0200

    ext4: don't BUG on inconsistent journal feature
    
    [ Upstream commit 11215630aada28307ba555a43138db6ac54fa825 ]
    
    A customer has reported a BUG_ON in ext4_clear_journal_err() hitting
    during an LTP testing. Either this has been caused by a test setup
    issue where the filesystem was being overwritten while LTP was mounting
    it or the journal replay has overwritten the superblock with invalid
    data. In either case it is preferable we don't take the machine down
    with a BUG_ON. So handle the situation of unexpectedly missing
    has_journal feature more gracefully. We issue warning and fail the mount
    in the cases where the race window is narrow and the failed check is
    most likely a programming error. In cases where fs corruption is more
    likely, we do full ext4_error() handling before failing mount / remount.
    
    Reviewed-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20200710140759.18031-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3b1a4ea0028afe0194971c2b6910474a3eb89012
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Wed Jun 17 11:25:49 2020 +0200

    jbd2: make sure jh have b_transaction set in refile/unfile_buffer
    
    [ Upstream commit 24dc9864914eb5813173cfa53313fcd02e4aea7d ]
    
    Callers of __jbd2_journal_unfile_buffer() and
    __jbd2_journal_refile_buffer() assume that the b_transaction is set. In
    fact if it's not, we can end up with journal_head refcounting errors
    leading to crash much later that might be very hard to track down. Add
    asserts to make sure that is the case.
    
    We also make sure that b_next_transaction is NULL in
    __jbd2_journal_unfile_buffer() since the callers expect that as well and
    we should not get into that stage in this state anyway, leading to
    problems later on if we do.
    
    Tested with fstests.
    
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20200617092549.6712-1-lczerner@redhat.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4627ea08b85019f77a71ce1a7d11a2ff139d2280
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Aug 14 07:55:01 2020 +0200

    usb: gadget: f_tcm: Fix some resource leaks in some error paths
    
    [ Upstream commit 07c8434150f4eb0b65cae288721c8af1080fde17 ]
    
    If a memory allocation fails within a 'usb_ep_alloc_request()' call, the
    already allocated memory must be released.
    
    Fix a mix-up in the code and free the correct requests.
    
    Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69a11b99ce82be228138aa565e7ba2b63b77bc6e
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Mon Aug 17 14:19:30 2020 +0200

    i2c: rcar: in slave mode, clear NACK earlier
    
    [ Upstream commit 914a7b3563b8fb92f976619bbd0fa3a4a708baae ]
    
    Currently, a NACK in slave mode is set/cleared when SCL is held low by
    the IP core right before the bit is about to be pushed out. This is too
    late for clearing and then a NACK from the previous byte is still used
    for the current one. Now, let's clear the NACK right after we detected
    the STOP condition following the NACK.
    
    Fixes: de20d1857dd6 ("i2c: rcar: add slave support")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 515903c16bde320ba4c9fbce97944f1214d7a464
Author: Hou Pu <houpu@bytedance.com>
Date:   Fri Aug 21 04:34:42 2020 -0400

    null_blk: fix passing of REQ_FUA flag in null_handle_rq
    
    [ Upstream commit 2d62e6b038e729c3e4bfbfcfbd44800ef0883680 ]
    
    REQ_FUA should be checked using rq->cmd_flags instead of req_op().
    
    Fixes: deb78b419dfda ("nullb: emulate cache")
    Signed-off-by: Hou Pu <houpu@bytedance.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ece300942e050e30300cf108d6c71f13c0e424e
Author: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Date:   Sun Aug 2 19:15:45 2020 +0800

    nvme-fc: Fix wrong return value in __nvme_fc_init_request()
    
    [ Upstream commit f34448cd0dc697723fb5f4118f8431d9233b370d ]
    
    On an error exit path, a negative error code should be returned
    instead of a positive return value.
    
    Fixes: e399441de9115 ("nvme-fabrics: Add host support for FC transport")
    Cc: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14cb42ed874b742fae0e3acf10b43eb2ca0217aa
Author: Rob Clark <robdclark@chromium.org>
Date:   Wed Aug 12 17:03:09 2020 -0700

    drm/msm/adreno: fix updating ring fence
    
    [ Upstream commit f228af11dfa1d1616bc67f3a4119ab77c36181f1 ]
    
    We need to set it to the most recent completed fence, not the most
    recent submitted.  Otherwise we have races where we think we can retire
    submits that the GPU is not finished with, if the GPU doesn't manage to
    overwrite the seqno before we look at it.
    
    This can show up with hang recovery if one of the submits after the
    crashing submit also hangs after it is replayed.
    
    Fixes: f97decac5f4c ("drm/msm: Support multiple ringbuffers")
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0961d7fe12491b474546952e25b441b9e56915c6
Author: Sean Young <sean@mess.org>
Date:   Sat May 2 14:50:52 2020 +0200

    media: gpio-ir-tx: improve precision of transmitted signal due to scheduling
    
    [ Upstream commit ea8912b788f8144e7d32ee61e5ccba45424bef83 ]
    
    usleep_range() may take longer than the max argument due to scheduling,
    especially under load. This is causing random errors in the transmitted
    IR. Remove the usleep_range() in favour of busy-looping with udelay().
    
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70323cca909d68ec88d44141a357b4c77e194492
Author: Zhi Chen <zhichen@codeaurora.org>
Date:   Tue Jan 14 12:35:21 2020 +0800

    Revert "ath10k: fix DMA related firmware crashes on multiple devices"
    
    [ Upstream commit a1769bb68a850508a492e3674ab1e5e479b11254 ]
    
    This reverts commit 76d164f582150fd0259ec0fcbc485470bcd8033e.
    PCIe hung issue was observed on multiple platforms. The issue was reproduced
    when DUT was configured as AP and associated with 50+ STAs.
    
    For QCA9984/QCA9888, the DMA_BURST_SIZE register controls the AXI burst size
    of the RD/WR access to the HOST MEM.
    0 - No split , RAW read/write transfer size from MAC is put out on bus
        as burst length
    1 - Split at 256 byte boundary
    2,3 - Reserved
    
    With PCIe protocol analyzer, we can see DMA Read crossing 4KB boundary when
    issue happened. It broke PCIe spec and caused PCIe stuck. So revert
    the default value from 0 to 1.
    
    Tested:  IPQ8064 + QCA9984 with firmware 10.4-3.10-00047
             QCS404 + QCA9984 with firmware 10.4-3.9.0.2--00044
             Synaptics AS370 + QCA9888  with firmware 10.4-3.9.0.2--00040
    
    Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0e0e6185ea7762e224cecc27c0da5bf42d8b363b
Author: Andrey Konovalov <andreyknvl@google.com>
Date:   Thu Aug 6 23:25:01 2020 -0700

    efi: provide empty efi_enter_virtual_mode implementation
    
    [ Upstream commit 2c547f9da0539ad1f7ef7f08c8c82036d61b011a ]
    
    When CONFIG_EFI is not enabled, we might get an undefined reference to
    efi_enter_virtual_mode() error, if this efi_enabled() call isn't inlined
    into start_kernel().  This happens in particular, if start_kernel() is
    annodated with __no_sanitize_address.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Elena Petrova <lenaptr@google.com>
    Cc: Marco Elver <elver@google.com>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: Walter Wu <walter-zh.wu@mediatek.com>
    Link: http://lkml.kernel.org/r/6514652d3a32d3ed33d6eb5c91d0af63bf0d1a0c.1596544734.git.andreyknvl@google.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5b61db89d201dee13cc400eab1f7e0e49f4f7b2
Author: Changming Liu <charley.ashbringer@gmail.com>
Date:   Sat Jul 11 00:30:18 2020 -0400

    USB: sisusbvga: Fix a potential UB casued by left shifting a negative value
    
    [ Upstream commit 2b53a19284f537168fb506f2f40d7fda40a01162 ]
    
    The char buffer buf, receives data directly from user space,
    so its content might be negative and its elements are left
    shifted to form an unsigned integer.
    
    Since left shifting a negative value is undefined behavior, thus
    change the char to u8 to elimintate this UB.
    
    Signed-off-by: Changming Liu <charley.ashbringer@gmail.com>
    Link: https://lore.kernel.org/r/20200711043018.928-1-charley.ashbringer@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a76cddecff0c7420c1d6785b77dd1823f36219d
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jul 6 15:22:46 2020 +0200

    powerpc/spufs: add CONFIG_COREDUMP dependency
    
    [ Upstream commit b648a5132ca3237a0f1ce5d871fff342b0efcf8a ]
    
    The kernel test robot pointed out a slightly different error message
    after recent commit 5456ffdee666 ("powerpc/spufs: simplify spufs core
    dumping") to spufs for a configuration that never worked:
    
       powerpc64-linux-ld: arch/powerpc/platforms/cell/spufs/file.o: in function `.spufs_proxydma_info_dump':
    >> file.c:(.text+0x4c68): undefined reference to `.dump_emit'
       powerpc64-linux-ld: arch/powerpc/platforms/cell/spufs/file.o: in function `.spufs_dma_info_dump':
       file.c:(.text+0x4d70): undefined reference to `.dump_emit'
       powerpc64-linux-ld: arch/powerpc/platforms/cell/spufs/file.o: in function `.spufs_wbox_info_dump':
       file.c:(.text+0x4df4): undefined reference to `.dump_emit'
    
    Add a Kconfig dependency to prevent this from happening again.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Jeremy Kerr <jk@ozlabs.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200706132302.3885935-1-arnd@arndb.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit acf3356196b882fe5d060bb87bcb3ce7b9b5f890
Author: David Brazdil <dbrazdil@google.com>
Date:   Thu Jun 25 14:14:06 2020 +0100

    KVM: arm64: Fix symbol dependency in __hyp_call_panic_nvhe
    
    [ Upstream commit b38b298aa4397e2dc74a89b4dd3eac9e59b64c96 ]
    
    __hyp_call_panic_nvhe contains inline assembly which did not declare
    its dependency on the __hyp_panic_string symbol.
    
    The static-declared string has previously been kept alive because of a use in
    __hyp_call_panic_vhe. Fix this in preparation for separating the source files
    between VHE and nVHE when the two users land in two different compilation
    units. The static variable otherwise gets dropped when compiling the nVHE
    source file, causing an undefined symbol linker error later.
    
    Signed-off-by: David Brazdil <dbrazdil@google.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20200625131420.71444-2-dbrazdil@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c10826fbfb5c958701207031503a4432ac556656
Author: Jason Baron <jbaron@akamai.com>
Date:   Thu Jul 16 14:25:11 2020 -0400

    EDAC/ie31200: Fallback if host bridge device is already initialized
    
    [ Upstream commit 709ed1bcef12398ac1a35c149f3e582db04456c2 ]
    
    The Intel uncore driver may claim some of the pci ids from ie31200 which
    means that the ie31200 edac driver will not initialize them as part of
    pci_register_driver().
    
    Let's add a fallback for this case to 'pci_get_device()' to get a
    reference on the device such that it can still be configured. This is
    similar in approach to other edac drivers.
    
    Signed-off-by: Jason Baron <jbaron@akamai.com>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: linux-edac <linux-edac@vger.kernel.org>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/1594923911-10885-1-git-send-email-jbaron@akamai.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15f15650ee10ff24cd5736dca5f9d693fc9f56d4
Author: Javed Hasan <jhasan@marvell.com>
Date:   Wed Jul 29 01:18:24 2020 -0700

    scsi: fcoe: Memory leak fix in fcoe_sysfs_fcf_del()
    
    [ Upstream commit e95b4789ff4380733006836d28e554dc296b2298 ]
    
    In fcoe_sysfs_fcf_del(), we first deleted the fcf from the list and then
    freed it if ctlr_dev was not NULL. This was causing a memory leak.
    
    Free the fcf even if ctlr_dev is NULL.
    
    Link: https://lore.kernel.org/r/20200729081824.30996-3-jhasan@marvell.com
    Reviewed-by: Girish Basrur <gbasrur@marvell.com>
    Reviewed-by: Santosh Vernekar <svernekar@marvell.com>
    Reviewed-by: Saurav Kashyap <skashyap@marvell.com>
    Reviewed-by: Shyam Sundar <ssundar@marvell.com>
    Signed-off-by: Javed Hasan <jhasan@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0335766691f37dcedc4f39a94a181a294951776
Author: Xiubo Li <xiubli@redhat.com>
Date:   Wed Jul 1 01:52:48 2020 -0400

    ceph: fix potential mdsc use-after-free crash
    
    [ Upstream commit fa9967734227b44acb1b6918033f9122dc7825b9 ]
    
    Make sure the delayed work stopped before releasing the resources.
    
    cancel_delayed_work_sync() will only guarantee that the work finishes
    executing if the work is already in the ->worklist.  That means after
    the cancel_delayed_work_sync() returns, it will leave the work requeued
    if it was rearmed at the end. That can lead to a use after free once the
    work struct is freed.
    
    Fix it by flushing the delayed work instead of trying to cancel it, and
    ensure that the work doesn't rearm if the mdsc is stopping.
    
    URL: https://tracker.ceph.com/issues/46293
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d10ceeb835b5db394e4b8443498190c6827e0576
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date:   Mon Jun 15 16:12:26 2020 +0800

    scsi: iscsi: Do not put host in iscsi_set_flashnode_param()
    
    [ Upstream commit 68e12e5f61354eb42cfffbc20a693153fc39738e ]
    
    If scsi_host_lookup() fails we will jump to put_host which may cause a
    panic. Jump to exit_set_fnode instead.
    
    Link: https://lore.kernel.org/r/20200615081226.183068-1-jingxiangfeng@huawei.com
    Reviewed-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d20e391d9e821cbfe35c9bcf9e965690121386c
Author: Qu Wenruo <wqu@suse.com>
Date:   Wed Jun 10 09:04:42 2020 +0800

    btrfs: file: reserve qgroup space after the hole punch range is locked
    
    [ Upstream commit a7f8b1c2ac21bf081b41264c9cfd6260dffa6246 ]
    
    The incoming qgroup reserved space timing will move the data reservation
    to ordered extent completely.
    
    However in btrfs_punch_hole_lock_range() will call
    btrfs_invalidate_page(), which will clear QGROUP_RESERVED bit for the
    range.
    
    In current stage it's OK, but if we're making ordered extents handle the
    reserved space, then btrfs_punch_hole_lock_range() can clear the
    QGROUP_RESERVED bit before we submit ordered extent, leading to qgroup
    reserved space leakage.
    
    So here change the timing to make reserve data space after
    btrfs_punch_hole_lock_range().
    The new timing is fine for either current code or the new code.
    
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db454f8ab4b694eaf6a23b97479aa4b42c38e6e3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Jul 25 19:51:10 2020 +0100

    locking/lockdep: Fix overflow in presentation of average lock-time
    
    [ Upstream commit a7ef9b28aa8d72a1656fa6f0a01bbd1493886317 ]
    
    Though the number of lock-acquisitions is tracked as unsigned long, this
    is passed as the divisor to div_s64() which interprets it as a s32,
    giving nonsense values with more than 2 billion acquisitons. E.g.
    
      acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg
      -------------------------------------------------------------------------
        2350439395           0.07         353.38   649647067.36          0.-32
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20200725185110.11588-1-chris@chris-wilson.co.uk
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 66e1e18133c43e0cfff609054aa64ad0652371fa
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Sat Jun 13 20:22:23 2020 -0500

    drm/nouveau: Fix reference count leak in nouveau_connector_detect
    
    [ Upstream commit 990a1162986e8eff7ca18cc5a0e03b4304392ae2 ]
    
    nouveau_connector_detect() calls pm_runtime_get_sync and in turn
    increments the reference count. In case of failure, decrement the
    ref count before returning the error.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e15bc26ff99cdcb459a59ba5f35ebe2549ed9390
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Sat Jun 13 20:29:18 2020 -0500

    drm/nouveau: fix reference count leak in nv50_disp_atomic_commit
    
    [ Upstream commit a2cdf39536b0d21fb06113f5e16692513d7bcb9c ]
    
    nv50_disp_atomic_commit() calls calls pm_runtime_get_sync and in turn
    increments the reference count. In case of failure, decrement the
    ref count before returning the error.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83443512a9493281dd9481681194ea45dbdfd5ee
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Sat Jun 13 20:33:42 2020 -0500

    drm/nouveau/drm/noveau: fix reference count leak in nouveau_fbcon_open
    
    [ Upstream commit bfad51c7633325b5d4b32444efe04329d53297b2 ]
    
    nouveau_fbcon_open() calls calls pm_runtime_get_sync() that
    increments the reference count. In case of failure, decrement the
    ref count before returning the error.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8cfbac12a68bb660491759d56e37049a05289691
Author: Li Guifu <bluce.liguifu@huawei.com>
Date:   Fri Jul 24 09:38:11 2020 +0800

    f2fs: fix use-after-free issue
    
    [ Upstream commit 99c787cfd2bd04926f1f553b30bd7dcea2caaba1 ]
    
    During umount, f2fs_put_super() unregisters procfs entries after
    f2fs_destroy_segment_manager(), it may cause use-after-free
    issue when umount races with procfs accessing, fix it by relocating
    f2fs_unregister_sysfs().
    
    [Chao Yu: change commit title/message a bit]
    
    Signed-off-by: Li Guifu <bluce.liguifu@huawei.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9094d83e14661b0fe8c1d7014e734443b8f4cbb0
Author: Ikjoon Jang <ikjn@chromium.org>
Date:   Tue Jul 21 14:54:09 2020 +0800

    HID: quirks: add NOGET quirk for Logitech GROUP
    
    [ Upstream commit 68f775ddd2a6f513e225f9a565b054ab48fef142 ]
    
    Add HID_QUIRK_NOGET for Logitech GROUP device.
    
    Logitech GROUP is a compound with camera and audio.
    When the HID interface in an audio device is requested to get
    specific report id, all following control transfers are stalled
    and never be restored back.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=203419
    Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da489549711e61bd43f3fd6fe19bb538eb575b39
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Fri Jun 26 12:44:26 2020 +0200

    cec-api: prevent leaking memory through hole in structure
    
    [ Upstream commit 6c42227c3467549ddc65efe99c869021d2f4a570 ]
    
    Fix this smatch warning:
    
    drivers/media/cec/core/cec-api.c:156 cec_adap_g_log_addrs() warn: check that 'log_addrs' doesn't leak information (struct has a hole after
    'features')
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a48f3e865420f3dc48d45040b00d0f05e5f32b86
Author: Peng Fan <fanpeng@loongson.cn>
Date:   Tue Jul 14 20:30:18 2020 +0800

    mips/vdso: Fix resource leaks in genvdso.c
    
    [ Upstream commit a859647b4e6bfeb192284d27d24b6a0c914cae1d ]
    
    Close "fd" before the return of map_vdso() and close "out_file"
    in main().
    
    Signed-off-by: Peng Fan <fanpeng@loongson.cn>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 644e4f2425a64b45ac8bcca6ae86e2d3cc50729c
Author: Reto Schneider <code@reto-schneider.ch>
Date:   Mon Jun 22 15:21:12 2020 +0200

    rtlwifi: rtl8192cu: Prevent leaking urb
    
    [ Upstream commit 03128643eb5453a798db5770952c73dc64fcaf00 ]
    
    If usb_submit_urb fails the allocated urb should be unanchored and
    released.
    
    Signed-off-by: Reto Schneider <code@reto-schneider.ch>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200622132113.14508-3-code@reto-schneider.ch
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4841465f8901e6b84e24b08875f5d1bf5af59360
Author: Yangbo Lu <yangbo.lu@nxp.com>
Date:   Fri May 22 09:30:52 2020 +0800

    ARM: dts: ls1021a: output PPS signal on FIPER2
    
    [ Upstream commit 5656bb3857c4904d1dec6e1b8f876c1c0337274e ]
    
    The timer fixed interval period pulse generator register
    is used to generate periodic pulses. The down count
    register loads the value programmed in the fixed period
    interval (FIPER). At every tick of the timer accumulator
    overflow, the counter decrements by the value of
    TMR_CTRL[TCLK_PERIOD]. It generates a pulse when the down
    counter value reaches zero. It reloads the down counter
    in the cycle following a pulse.
    
    To use the TMR_FIPER register to generate desired periodic
    pulses. The value should programmed is,
    desired_period - tclk_period
    
    Current tmr-fiper2 value is to generate 100us periodic pulses.
    (But the value should have been 99995, not 99990. The tclk_period is 5.)
    This patch is to generate 1 second periodic pulses with value
    999999995 programmed which is more desired by user.
    
    Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 03f4e517e6ac202d6a6ca50f02a1319a4a70cdd6
Author: Qiushi Wu <wu000273@umn.edu>
Date:   Wed May 27 21:13:22 2020 -0500

    PCI: Fix pci_create_slot() reference count leak
    
    [ Upstream commit 8a94644b440eef5a7b9c104ac8aa7a7f413e35e5 ]
    
    kobject_init_and_add() takes a reference even when it fails.  If it returns
    an error, kobject_put() must be called to clean up the memory associated
    with the object.
    
    When kobject_init_and_add() fails, call kobject_put() instead of kfree().
    
    b8eb718348b8 ("net-sysfs: Fix reference count leak in
    rx|netdev_queue_add_kobject") fixed a similar problem.
    
    Link: https://lore.kernel.org/r/20200528021322.1984-1-wu000273@umn.edu
    Signed-off-by: Qiushi Wu <wu000273@umn.edu>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c33c23b931d0b0e38aa436a90c2c527414e2fc5
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Sat Jun 13 22:05:18 2020 -0500

    omapfb: fix multiple reference count leaks due to pm_runtime_get_sync
    
    [ Upstream commit 78c2ce9bde70be5be7e3615a2ae7024ed8173087 ]
    
    On calling pm_runtime_get_sync() the reference count of the device
    is incremented. In case of failure, decrement the
    reference count before returning the error.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Cc: kjlu@umn.edu
    Cc: wu000273@umn.edu
    Cc: Allison Randal <allison@lohutok.net>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Enrico Weigelt <info@metux.net>
    cc: "Andrew F. Davis" <afd@ti.com>
    Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Cc: Alexios Zavras <alexios.zavras@intel.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200614030528.128064-1-pakki001@umn.edu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e2c212d7c96d25f0dd53abfe5745ddb88266a33
Author: Chao Yu <chao@kernel.org>
Date:   Mon Jul 6 18:23:36 2020 +0800

    f2fs: fix error path in do_recover_data()
    
    [ Upstream commit 9627a7b31f3c4ff8bc8f3be3683983ffe6eaebe6 ]
    
    - don't panic kernel if f2fs_get_node_page() fails in
    f2fs_recover_inline_data() or f2fs_recover_inline_xattr();
    - return error number of f2fs_truncate_blocks() to
    f2fs_recover_inline_data()'s caller;
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c74fe263acd8d7a5d16bfb3a282ef34abd36d4e
Author: Desnes A. Nunes do Rosario <desnesn@linux.ibm.com>
Date:   Fri Jun 26 13:47:37 2020 -0300

    selftests/powerpc: Purge extra count_pmc() calls of ebb selftests
    
    [ Upstream commit 3337bf41e0dd70b4064cdf60acdfcdc2d050066c ]
    
    An extra count on ebb_state.stats.pmc_count[PMC_INDEX(pmc)] is being per-
    formed when count_pmc() is used to reset PMCs on a few selftests. This
    extra pmc_count can occasionally invalidate results, such as the ones from
    cycles_test shown hereafter. The ebb_check_count() failed with an above
    the upper limit error due to the extra value on ebb_state.stats.pmc_count.
    
    Furthermore, this extra count is also indicated by extra PMC1 trace_log on
    the output of the cycle test (as well as on pmc56_overflow_test):
    
    ==========
       ...
       [21]: counter = 8
       [22]: register SPRN_MMCR0 = 0x0000000080000080
       [23]: register SPRN_PMC1  = 0x0000000080000004
       [24]: counter = 9
       [25]: register SPRN_MMCR0 = 0x0000000080000080
       [26]: register SPRN_PMC1  = 0x0000000080000004
       [27]: counter = 10
       [28]: register SPRN_MMCR0 = 0x0000000080000080
       [29]: register SPRN_PMC1  = 0x0000000080000004
    >> [30]: register SPRN_PMC1  = 0x000000004000051e
    PMC1 count (0x280000546) above upper limit 0x2800003e8 (+0x15e)
    [FAIL] Test FAILED on line 52
    failure: cycles
    ==========
    
    Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.ibm.com>
    Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200626164737.21943-1-desnesn@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6af2bb145126e4907ff0a64bbee04fa0b499f09c
Author: Dave Chinner <dchinner@redhat.com>
Date:   Mon Jun 29 14:48:45 2020 -0700

    xfs: Don't allow logging of XFS_ISTALE inodes
    
    [ Upstream commit 96355d5a1f0ee6dcc182c37db4894ec0c29f1692 ]
    
    In tracking down a problem in this patchset, I discovered we are
    reclaiming dirty stale inodes. This wasn't discovered until inodes
    were always attached to the cluster buffer and then the rcu callback
    that freed inodes was assert failing because the inode still had an
    active pointer to the cluster buffer after it had been reclaimed.
    
    Debugging the issue indicated that this was a pre-existing issue
    resulting from the way the inodes are handled in xfs_inactive_ifree.
    When we free a cluster buffer from xfs_ifree_cluster, all the inodes
    in cache are marked XFS_ISTALE. Those that are clean have nothing
    else done to them and so eventually get cleaned up by background
    reclaim. i.e. it is assumed we'll never dirty/relog an inode marked
    XFS_ISTALE.
    
    On journal commit dirty stale inodes as are handled by both
    buffer and inode log items to run though xfs_istale_done() and
    removed from the AIL (buffer log item commit) or the log item will
    simply unpin it because the buffer log item will clean it. What happens
    to any specific inode is entirely dependent on which log item wins
    the commit race, but the result is the same - stale inodes are
    clean, not attached to the cluster buffer, and not in the AIL. Hence
    inode reclaim can just free these inodes without further care.
    
    However, if the stale inode is relogged, it gets dirtied again and
    relogged into the CIL. Most of the time this isn't an issue, because
    relogging simply changes the inode's location in the current
    checkpoint. Problems arise, however, when the CIL checkpoints
    between two transactions in the xfs_inactive_ifree() deferops
    processing. This results in the XFS_ISTALE inode being redirtied
    and inserted into the CIL without any of the other stale cluster
    buffer infrastructure being in place.
    
    Hence on journal commit, it simply gets unpinned, so it remains
    dirty in memory. Everything in inode writeback avoids XFS_ISTALE
    inodes so it can't be written back, and it is not tracked in the AIL
    so there's not even a trigger to attempt to clean the inode. Hence
    the inode just sits dirty in memory until inode reclaim comes along,
    sees that it is XFS_ISTALE, and goes to reclaim it. This reclaiming
    of a dirty inode caused use after free, list corruptions and other
    nasty issues later in this patchset.
    
    Hence this patch addresses a violation of the "never log XFS_ISTALE
    inodes" caused by the deferops processing rolling a transaction
    and relogging a stale inode in xfs_inactive_free. It also adds a
    bunch of asserts to catch this problem in debug kernels so that
    we don't reintroduce this problem in future.
    
    Reproducer for this issue was generic/558 on a v4 filesystem.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f28249fbb663f0bc09d13654bf2e303f5c24d86b
Author: Dick Kennedy <dick.kennedy@broadcom.com>
Date:   Tue Jun 30 14:49:54 2020 -0700

    scsi: lpfc: Fix shost refcount mismatch when deleting vport
    
    [ Upstream commit 03dbfe0668e6692917ac278883e0586cd7f7d753 ]
    
    When vports are deleted, it is observed that there is memory/kthread
    leakage as the vport isn't fully being released.
    
    There is a shost reference taken in scsi_add_host_dma that is not released
    during scsi_remove_host. It was noticed that other drivers resolve this by
    doing a scsi_host_put after calling scsi_remove_host.
    
    The vport_delete routine is taking two references one that corresponds to
    an access to the scsi_host in the vport_delete routine and another that is
    released after the adapter mailbox command completes that destroys the VPI
    that corresponds to the vport.
    
    Remove one of the references taken such that the second reference that is
    put will complete the missing scsi_add_host_dma reference and the shost
    will be terminated.
    
    Link: https://lore.kernel.org/r/20200630215001.70793-8-jsmart2021@gmail.com
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f93736e489642e7fdece41ed29aeb0fe1bef5fd3
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Sun Jun 14 02:05:28 2020 -0500

    drm/amdgpu/display: fix ref count leak when pm_runtime_get_sync fails
    
    [ Upstream commit f79f94765f8c39db0b7dec1d335ab046aac03f20 ]
    
    The call to pm_runtime_get_sync increments the counter even in case of
    failure, leading to incorrect ref count.
    In case of failure, decrement the ref count before returning.
    
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d94a5e441cf1a7bf9f88580248fb5f8205b26c53
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Sun Jun 14 02:09:44 2020 -0500

    drm/amdgpu: fix ref count leak in amdgpu_display_crtc_set_config
    
    [ Upstream commit e008fa6fb41544b63973a529b704ef342f47cc65 ]
    
    in amdgpu_display_crtc_set_config, the call to pm_runtime_get_sync
    increments the counter even in case of failure, leading to incorrect
    ref count. In case of failure, decrement the ref count before returning.
    
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 214b2803ba44538f929dad7d196224c2acd06740
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Sun Jun 14 02:14:50 2020 -0500

    drm/amd/display: fix ref count leak in amdgpu_drm_ioctl
    
    [ Upstream commit 5509ac65f2fe5aa3c0003237ec629ca55024307c ]
    
    in amdgpu_drm_ioctl the call to pm_runtime_get_sync increments the
    counter even in case of failure, leading to incorrect
    ref count. In case of failure, decrement the ref count before returning.
    
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9006d622156a5c4a6699d303472fe24786cd10c9
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Sun Jun 14 02:12:29 2020 -0500

    drm/amdgpu: fix ref count leak in amdgpu_driver_open_kms
    
    [ Upstream commit 9ba8923cbbe11564dd1bf9f3602add9a9cfbb5c6 ]
    
    in amdgpu_driver_open_kms the call to pm_runtime_get_sync increments the
    counter even in case of failure, leading to incorrect
    ref count. In case of failure, decrement the ref count before returning.
    
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93d3e58c97741f25c3e6c15e3dd61ab684f72cb2
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Sat Jun 13 20:55:39 2020 -0500

    drm/radeon: fix multiple reference count leak
    
    [ Upstream commit 6f2e8acdb48ed166b65d47837c31b177460491ec ]
    
    On calling pm_runtime_get_sync() the reference count of the device
    is incremented. In case of failure, decrement the
    reference count before returning the error.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74d20579fcf02320fb51efd12bad1ff320e0d4f0
Author: Qiushi Wu <wu000273@umn.edu>
Date:   Sat Jun 13 14:32:26 2020 -0500

    drm/amdkfd: Fix reference count leaks.
    
    [ Upstream commit 20eca0123a35305e38b344d571cf32768854168c ]
    
    kobject_init_and_add() takes reference even when it fails.
    If this function returns an error, kobject_put() must be called to
    properly clean up the memory associated with the object.
    
    Signed-off-by: Qiushi Wu <wu000273@umn.edu>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c9723816024195e6d68255e29db0dd4658f76ff
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Tue Jun 2 14:08:18 2020 +0100

    iommu/iova: Don't BUG on invalid PFNs
    
    [ Upstream commit d3e3d2be688b4b5864538de61e750721a311e4fc ]
    
    Unlike the other instances which represent a complete loss of
    consistency within the rcache mechanism itself, or a fundamental
    and obvious misconfiguration by an IOMMU driver, the BUG_ON() in
    iova_magazine_free_pfns() can be provoked at more or less any time
    in a "spooky action-at-a-distance" manner by any old device driver
    passing nonsense to dma_unmap_*() which then propagates through to
    queue_iova().
    
    Not only is this well outside the IOVA layer's control, it's also
    nowhere near fatal enough to justify panicking anyway - all that
    really achieves is to make debugging the offending driver more
    difficult. Let's simply WARN and otherwise ignore bogus PFNs.
    
    Reported-by: Prakash Gupta <guptap@codeaurora.org>
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Reviewed-by: Prakash Gupta <guptap@codeaurora.org>
    Link: https://lore.kernel.org/r/acbd2d092b42738a03a21b417ce64e27f8c91c86.1591103298.git.robin.murphy@arm.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5cd5c1e708721c421e6a101a949d462a8d840f4
Author: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Date:   Mon Jun 29 11:37:56 2020 +0200

    scsi: target: tcmu: Fix crash on ARM during cmd completion
    
    [ Upstream commit 5a0c256d96f020e4771f6fd5524b80f89a2d3132 ]
    
    If tcmu_handle_completions() has to process a padding shorter than
    sizeof(struct tcmu_cmd_entry), the current call to
    tcmu_flush_dcache_range() with sizeof(struct tcmu_cmd_entry) as length
    param is wrong and causes crashes on e.g. ARM, because
    tcmu_flush_dcache_range() in this case calls
    flush_dcache_page(vmalloc_to_page(start)); with start being an invalid
    address above the end of the vmalloc'ed area.
    
    The fix is to use the minimum of remaining ring space and sizeof(struct
    tcmu_cmd_entry) as the length param.
    
    The patch was tested on kernel 4.19.118.
    
    See https://bugzilla.kernel.org/show_bug.cgi?id=208045#c10
    
    Link: https://lore.kernel.org/r/20200629093756.8947-1-bstroesser@ts.fujitsu.com
    Tested-by: JiangYu <lnsyyj@hotmail.com>
    Acked-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f4e860765108133941c9c964af336769b487c388
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Fri Jun 19 20:47:29 2020 +0000

    blktrace: ensure our debugfs dir exists
    
    [ Upstream commit b431ef837e3374da0db8ff6683170359aaa0859c ]
    
    We make an assumption that a debugfs directory exists, but since
    this can fail ensure it exists before allowing blktrace setup to
    complete. Otherwise we end up stuffing blktrace files on the debugfs
    root directory. In the worst case scenario this *in theory* can create
    an eventual panic *iff* in the future a similarly named file is created
    prior on the debugfs root directory. This theoretical crash can happen
    due to a recursive removal followed by a specific dentry removal.
    
    This doesn't fix any known crash, however I have seen the files
    go into the main debugfs root directory in cases where the debugfs
    directory was not created due to other internal bugs with blktrace
    now fixed.
    
    blktrace is also completely useless without this directory, so
    this ensures to userspace we only setup blktrace if the kernel
    can stuff files where they are supposed to go into.
    
    debugfs directory creations typically aren't checked for, and we have
    maintainers doing sweep removals of these checks, but since we need this
    check to ensure proper userspace blktrace functionality we make sure
    to annotate the justification for the check.
    
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 882e00b601c27999e4d12bac9a3233737bcbf9d9
Author: Jia-Ju Bai <baijiaju@tsinghua.edu.cn>
Date:   Sat May 30 16:42:08 2020 +0200

    media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()
    
    [ Upstream commit 6499a0db9b0f1e903d52f8244eacc1d4be00eea2 ]
    
    The value av7110->debi_virt is stored in DMA memory, and it is assigned
    to data, and thus data[0] can be modified at any time by malicious
    hardware. In this case, "if (data[0] < 2)" can be passed, but then
    data[0] can be changed into a large number, which may cause buffer
    overflow when the code "av7110->ci_slot[data[0]]" is used.
    
    To fix this possible bug, data[0] is assigned to a local variable, which
    replaces the use of data[0].
    
    Signed-off-by: Jia-Ju Bai <baijiaju@tsinghua.edu.cn>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1838bdf6cabc2b6b0c12363b82f19d388cbd20e9
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Fri Jun 12 14:33:03 2020 +1000

    powerpc/xive: Ignore kmemleak false positives
    
    [ Upstream commit f0993c839e95dd6c7f054a1015e693c87e33e4fb ]
    
    xive_native_provision_pages() allocates memory and passes the pointer to
    OPAL so kmemleak cannot find the pointer usage in the kernel memory and
    produces a false positive report (below) (even if the kernel did scan
    OPAL memory, it is unable to deal with __pa() addresses anyway).
    
    This silences the warning.
    
    unreferenced object 0xc000200350c40000 (size 65536):
      comm "qemu-system-ppc", pid 2725, jiffies 4294946414 (age 70776.530s)
      hex dump (first 32 bytes):
        02 00 00 00 50 00 00 00 00 00 00 00 00 00 00 00  ....P...........
        01 00 08 07 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<0000000081ff046c>] xive_native_alloc_vp_block+0x120/0x250
        [<00000000d555d524>] kvmppc_xive_compute_vp_id+0x248/0x350 [kvm]
        [<00000000d69b9c9f>] kvmppc_xive_connect_vcpu+0xc0/0x520 [kvm]
        [<000000006acbc81c>] kvm_arch_vcpu_ioctl+0x308/0x580 [kvm]
        [<0000000089c69580>] kvm_vcpu_ioctl+0x19c/0xae0 [kvm]
        [<00000000902ae91e>] ksys_ioctl+0x184/0x1b0
        [<00000000f3e68bd7>] sys_ioctl+0x48/0xb0
        [<0000000001b2c127>] system_call_exception+0x124/0x1f0
        [<00000000d2b2ee40>] system_call_common+0xe8/0x214
    
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200612043303.84894-1-aik@ozlabs.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 49c469ac2b637fc85e44b3cb85683b21ceeffd73
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Fri Jun 5 20:59:15 2020 +0200

    arm64: dts: qcom: msm8916: Pull down PDM GPIOs during sleep
    
    [ Upstream commit e2ee9edc282961783d519c760bbaa20fed4dec38 ]
    
    The original qcom kernel changed the PDM GPIOs to be pull-down
    during sleep at some point. Reportedly this was done because
    there was some "leakage at PDM outputs during sleep":
    
      https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/?id=0f87e08c1cd3e6484a6f7fb3e74e37340bdcdee0
    
    I cannot say how effective this is, but everything seems to work
    fine with this change so let's apply the same to mainline just
    to be sure.
    
    Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Link: https://lore.kernel.org/r/20200605185916.318494-3-stephan@gerhold.net
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8524be5aafb78d1c8715910345fcc963e62fac86
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Jun 15 19:10:32 2020 +0300

    mfd: intel-lpss: Add Intel Emmitsburg PCH PCI IDs
    
    [ Upstream commit 3ea2e4eab64cefa06055bb0541fcdedad4b48565 ]
    
    Intel Emmitsburg PCH has the same LPSS than Intel Ice Lake.
    Add the new IDs to the list of supported devices.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ff0d9154ef86b2f90ecf75149a30cd3d9253241
Author: Qiushi Wu <wu000273@umn.edu>
Date:   Sat Jun 13 15:44:19 2020 -0500

    ASoC: tegra: Fix reference count leaks.
    
    [ Upstream commit deca195383a6085be62cb453079e03e04d618d6e ]
    
    Calling pm_runtime_get_sync increments the counter even in case of
    failure, causing incorrect ref count if pm_runtime_put is not called in
    error handling paths. Call pm_runtime_put if pm_runtime_get_sync fails.
    
    Signed-off-by: Qiushi Wu <wu000273@umn.edu>
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Link: https://lore.kernel.org/r/20200613204422.24484-1-wu000273@umn.edu
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 951fba03cf3ed5981d53c91e93ab3dd5f3d0ebbd
Author: Qiushi Wu <wu000273@umn.edu>
Date:   Sat Jun 13 22:33:43 2020 -0500

    ASoC: img-parallel-out: Fix a reference count leak
    
    [ Upstream commit 6b9fbb073636906eee9fe4d4c05a4f445b9e2a23 ]
    
    pm_runtime_get_sync() increments the runtime PM usage counter even
    when it returns an error code, causing incorrect ref count if
    pm_runtime_put_noidle() is not called in error handling paths.
    Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails.
    
    Signed-off-by: Qiushi Wu <wu000273@umn.edu>
    Link: https://lore.kernel.org/r/20200614033344.1814-1-wu000273@umn.edu
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6978222ea037ca8dcefaa0b37fea2cc41320a7f4
Author: Qiushi Wu <wu000273@umn.edu>
Date:   Sat Jun 13 22:37:48 2020 -0500

    ASoC: img: Fix a reference count leak in img_i2s_in_set_fmt
    
    [ Upstream commit c4c59b95b7f7d4cef5071b151be2dadb33f3287b ]
    
    pm_runtime_get_sync() increments the runtime PM usage counter even
    when it returns an error code, causing incorrect ref count if
    pm_runtime_put_noidle() is not called in error handling paths.
    Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails.
    
    Signed-off-by: Qiushi Wu <wu000273@umn.edu>
    Link: https://lore.kernel.org/r/20200614033749.2975-1-wu000273@umn.edu
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 65b121aa00b699069e549a77b171e505bdcc1cab
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Wed Aug 5 19:19:26 2020 -0700

    ALSA: pci: delete repeated words in comments
    
    [ Upstream commit c7fabbc51352f50cc58242a6dc3b9c1a3599849b ]
    
    Drop duplicated words in sound/pci/.
    {and, the, at}
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Link: https://lore.kernel.org/r/20200806021926.32418-1-rdunlap@infradead.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 76791cccd967c382384c6164df4c0e9bf9b9c61f
Author: Mahesh Bandewar <maheshb@google.com>
Date:   Fri Aug 14 22:53:24 2020 -0700

    ipvlan: fix device features
    
    [ Upstream commit d0f5c7076e01fef6fcb86988d9508bf3ce258bd4 ]
    
    Processing NETDEV_FEAT_CHANGE causes IPvlan links to lose
    NETIF_F_LLTX feature because of the incorrect handling of
    features in ipvlan_fix_features().
    
    --before--
    lpaa10:~# ethtool -k ipvl0 | grep tx-lockless
    tx-lockless: on [fixed]
    lpaa10:~# ethtool -K ipvl0 tso off
    Cannot change tcp-segmentation-offload
    Actual changes:
    vlan-challenged: off [fixed]
    tx-lockless: off [fixed]
    lpaa10:~# ethtool -k ipvl0 | grep tx-lockless
    tx-lockless: off [fixed]
    lpaa10:~#
    
    --after--
    lpaa10:~# ethtool -k ipvl0 | grep tx-lockless
    tx-lockless: on [fixed]
    lpaa10:~# ethtool -K ipvl0 tso off
    Cannot change tcp-segmentation-offload
    Could not change any device features
    lpaa10:~# ethtool -k ipvl0 | grep tx-lockless
    tx-lockless: on [fixed]
    lpaa10:~#
    
    Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
    Signed-off-by: Mahesh Bandewar <maheshb@google.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb14103b29bf40d691ca5214626aa472e1c940b5
Author: Shay Agroskin <shayagr@amazon.com>
Date:   Wed Aug 19 20:28:38 2020 +0300

    net: ena: Make missed_tx stat incremental
    
    [ Upstream commit ccd143e5150f24b9ba15145c7221b61dd9e41021 ]
    
    Most statistics in ena driver are incremented, meaning that a stat's
    value is a sum of all increases done to it since driver/queue
    initialization.
    
    This patch makes all statistics this way, effectively making missed_tx
    statistic incremental.
    Also added a comment regarding rx_drops and tx_drops to make it
    clearer how these counters are calculated.
    
    Fixes: 11095fdb712b ("net: ena: add statistics for missed tx packets")
    Signed-off-by: Shay Agroskin <shayagr@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d43753b0273731997a180f11d426d22f61bbb7d
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Sat Aug 15 16:29:15 2020 -0700

    tipc: fix uninit skb->data in tipc_nl_compat_dumpit()
    
    [ Upstream commit 47733f9daf4fe4f7e0eb9e273f21ad3a19130487 ]
    
    __tipc_nl_compat_dumpit() has two callers, and it expects them to
    pass a valid nlmsghdr via arg->data. This header is artificial and
    crafted just for __tipc_nl_compat_dumpit().
    
    tipc_nl_compat_publ_dump() does so by putting a genlmsghdr as well
    as some nested attribute, TIPC_NLA_SOCK. But the other caller
    tipc_nl_compat_dumpit() does not, this leaves arg->data uninitialized
    on this call path.
    
    Fix this by just adding a similar nlmsghdr without any payload in
    tipc_nl_compat_dumpit().
    
    This bug exists since day 1, but the recent commit 6ea67769ff33
    ("net: tipc: prepare attrs in __tipc_nl_compat_dumpit()") makes it
    easier to appear.
    
    Reported-and-tested-by: syzbot+0e7181deafa7e0b79923@syzkaller.appspotmail.com
    Fixes: d0796d1ef63d ("tipc: convert legacy nl bearer dump to nl compat")
    Cc: Jon Maloy <jmaloy@redhat.com>
    Cc: Ying Xue <ying.xue@windriver.com>
    Cc: Richard Alpe <richard.alpe@ericsson.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c8c02c99b25e491a8ac7ed21cbedb327a2d2728
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date:   Thu Aug 20 16:30:52 2020 +0200

    net/smc: Prevent kernel-infoleak in __smc_diag_dump()
    
    [ Upstream commit ce51f63e63c52a4e1eee4dd040fb0ba0af3b43ab ]
    
    __smc_diag_dump() is potentially copying uninitialized kernel stack memory
    into socket buffers, since the compiler may leave a 4-byte hole near the
    beginning of `struct smcd_diag_dmbinfo`. Fix it by initializing `dinfo`
    with memset().
    
    Fixes: 4b1b7d3b30a6 ("net/smc: add SMC-D diag support")
    Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a794b35f625761a24bf7b0b32ce94a266ff2729
Author: Necip Fazil Yildiran <necip@google.com>
Date:   Mon Aug 17 15:54:48 2020 +0000

    net: qrtr: fix usage of idr in port assignment to socket
    
    [ Upstream commit 8dfddfb79653df7c38a9c8c4c034f242a36acee9 ]
    
    Passing large uint32 sockaddr_qrtr.port numbers for port allocation
    triggers a warning within idr_alloc() since the port number is cast
    to int, and thus interpreted as a negative number. This leads to
    the rejection of such valid port numbers in qrtr_port_assign() as
    idr_alloc() fails.
    
    To avoid the problem, switch to idr_alloc_u32() instead.
    
    Fixes: bdabad3e363d ("net: Add Qualcomm IPC router")
    Reported-by: syzbot+f31428628ef672716ea8@syzkaller.appspotmail.com
    Signed-off-by: Necip Fazil Yildiran <necip@google.com>
    Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad270a5a9a04923da92238eaabfe04ad3cb06c16
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Sat Aug 15 04:44:31 2020 -0400

    net: Fix potential wrong skb->protocol in skb_vlan_untag()
    
    [ Upstream commit 55eff0eb7460c3d50716ed9eccf22257b046ca92 ]
    
    We may access the two bytes after vlan_hdr in vlan_set_encap_proto(). So
    we should pull VLAN_HLEN + sizeof(unsigned short) in skb_vlan_untag() or
    we may access the wrong data.
    
    Fixes: 0d5501c1c828 ("net: Always untag vlan-tagged traffic on input.")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3f242a608040074ff54fc67d74b168408c92899
Author: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
Date:   Wed Aug 19 13:53:58 2020 +1200

    gre6: Fix reception with IP6_TNL_F_RCV_DSCP_COPY
    
    [ Upstream commit 272502fcb7cda01ab07fc2fcff82d1d2f73d43cc ]
    
    When receiving an IPv4 packet inside an IPv6 GRE packet, and the
    IP6_TNL_F_RCV_DSCP_COPY flag is set on the tunnel, the IPv4 header would
    get corrupted. This is due to the common ip6_tnl_rcv() function assuming
    that the inner header is always IPv6. This patch checks the tunnel
    protocol for IPv4 inner packets, but still defaults to IPv6.
    
    Fixes: 308edfdf1563 ("gre6: Cleanup GREv6 receive path, call common GRE functions")
    Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f81b1d34b57cab7e131087a708116a63f3325ba9
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu May 28 00:58:40 2020 +1000

    powerpc/64s: Don't init FSCR_DSCR in __init_FSCR()
    
    commit 0828137e8f16721842468e33df0460044a0c588b upstream.
    
    __init_FSCR() was added originally in commit 2468dcf641e4 ("powerpc:
    Add support for context switching the TAR register") (Feb 2013), and
    only set FSCR_TAR.
    
    At that point FSCR (Facility Status and Control Register) was not
    context switched, so the setting was permanent after boot.
    
    Later we added initialisation of FSCR_DSCR to __init_FSCR(), in commit
    54c9b2253d34 ("powerpc: Set DSCR bit in FSCR setup") (Mar 2013), again
    that was permanent after boot.
    
    Then commit 2517617e0de6 ("powerpc: Fix context switch DSCR on
    POWER8") (Aug 2013) added a limited context switch of FSCR, just the
    FSCR_DSCR bit was context switched based on thread.dscr_inherit. That
    commit said "This clears the H/FSCR DSCR bit initially", but it
    didn't, it left the initialisation of FSCR_DSCR in __init_FSCR().
    However the initial context switch from init_task to pid 1 would clear
    FSCR_DSCR because thread.dscr_inherit was 0.
    
    That commit also introduced the requirement that FSCR_DSCR be clear
    for user processes, so that we can take the facility unavailable
    interrupt in order to manage dscr_inherit.
    
    Then in commit 152d523e6307 ("powerpc: Create context switch helpers
    save_sprs() and restore_sprs()") (Dec 2015) FSCR was added to
    thread_struct. However it still wasn't fully context switched, we just
    took the existing value and set FSCR_DSCR if the new thread had
    dscr_inherit set. FSCR was still initialised at boot to FSCR_DSCR |
    FSCR_TAR, but that value was not propagated into the thread_struct, so
    the initial context switch set FSCR_DSCR back to 0.
    
    Finally commit b57bd2de8c6c ("powerpc: Improve FSCR init and context
    switching") (Jun 2016) added a full context switch of the FSCR, and
    added an initialisation of init_task.thread.fscr to FSCR_TAR |
    FSCR_EBB, but omitted FSCR_DSCR.
    
    The end result is that swapper runs with FSCR_DSCR set because of the
    initialisation in __init_FSCR(), but no other processes do, they use
    the value from init_task.thread.fscr.
    
    Having FSCR_DSCR set for swapper allows it to access SPR 3 from
    userspace, but swapper never runs userspace, so it has no useful
    effect. It's also confusing to have the value initialised in two
    places to two different values.
    
    So remove FSCR_DSCR from __init_FSCR(), this at least gets us to the
    point where there's a single value of FSCR, even if it's still set in
    two places.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Tested-by: Alistair Popple <alistair@popple.id.au>
    Link: https://lore.kernel.org/r/20200527145843.2761782-1-mpe@ellerman.id.au
    Cc: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>