commit aafe133906196555c6fa4a1d65977dc3cd2c4349
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Sep 3 11:19:28 2020 +0200

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

commit bd80272251d27d263ff9ca63d85193adf556678f
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 61f5f326ff04e31ce12c6ff2747376dd6e7ff0d3
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 14edfd508f43723961ed70c07afb9f8ed5341f9d
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 973152b568cc28c15fb59ba446382486352bd099
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 3fae4606bc497728d4a3c11a83136623f555ec6f
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 e69382df6724cce4ff8f2cde08e04e48264ba008
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 1fa308e648c1ef18eb56e8e316367bd6fc58ce2f
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 a0788be4fb41c2f94018d239d0d800735d5baaf3
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 9c218a4ad3d146a14c596e83426dc5ef3787cc3b
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 31f5f13cb06da0090b93bae0e6d545926d9bed5a
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 b7e4ff6327aedb546b1fa5f9702bfe1577a47e47
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 6fa4be261454dd5091e045539138bff1c2dc5605
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 dd45bd060396d51ef30826ac5cee0b6a7c17e9aa
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 402050e52ce05ba654a9ae13a8934012e555105f
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 05829bc2388c3b2f3b114fe90f669e97026a7bd4
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 311e34b3b4dcc669f2d272b4281c41b109256b94
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 bf485f58b464029f80bc0bed7ac2fded6f4078e8
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 e779f66d74ff6c68cc18f28cc36c3f93c835e6db
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 ac2148d3e671b4e2ab248bc74cb279a4c5c47324
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 f24fa90862acb02ba5caa4bf9060d8b829bceb82
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 130c03c86d23aa411ae669a8223cb409f4ff0f2a
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 e35d476bca93c276aeaa481d4b4da0eb21c50b80
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 ae021a904ac82d9fc81c25329d3c465c5a7d5686
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 6f8f77d9fd130592c072d1ad621a66106c2f10fe
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 00b94b3e7898ef655501818b7d4883ed4912b5e8
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 c86b5b56fb1b356b8f71973b6ac6bd9bfb842f2c
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 35af8a3a8402aa8629674e8f101608d3643f1495
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 2889f4beb39cb624253b497653eed4a240c08c6d
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 0a4314699907d6f62c61604b8562a268c9a777d1
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 08496baa47361f8e4d4710800dbe4ad59d73c086
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 eebbe8dbd88893b86c25bc24ffe3227a0ca9b245
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 d7bf4ae5b98909ab7bf4e700da36ea7e52959503
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 0685dde3e21df9b1143adb3b07b70528d0c8b37e
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Thu Jul 23 19:04:53 2020 +0200

    media: davinci: vpif_capture: fix potential double free
    
    [ Upstream commit 602649eadaa0c977e362e641f51ec306bc1d365d ]
    
    In case of errors vpif_probe_complete() releases memory for vpif_obj.sd
    and unregisters the V4L2 device. But then this is done again by
    vpif_probe() itself. The patch removes the cleaning from
    vpif_probe_complete().
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    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 ef898164bf570fabc9751a1ccc9df93e14986e93
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 bd64f40ad711f8960a62c229d2a26375accd92f6
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 a54a180e4c23a4d4dbaa4532d38441720f2f1941
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 753068bc2cdc6f1a88a41c8de98c009fd6bcd757
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 c75c7581937bf2668bcba1d958ff48954d8bba88
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 28bec409535ee09f7f121807cdb9e394eab47562
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 7592eb3b6cf80eaeb1e648a258a3031e95141f64
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 a43f5de749e72a960003264833dab4407af00fbd
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 ab75ab9165de8fb8d037454856afb165e8d8b06d
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 d22aec437d771dc6b57b73ef14454a1aef44fa8c
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 535f69f4217178fd64c03b7b3c1421cfaf3d6e10
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 f515dc79ef81b21e4745bcc79a056a29b8f4c06d
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 28e269f9e6ac6dd13fc8342994130d2d90c77ee6
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 9b1e3b74c4e35eaaa2fc41c9bb805405c9390fa7
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 0d097bfa614a0b13224ddc4536c2a464f0e0b5fe
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 6d0364cd0f378fdb5d4a707f0a6c3111bcea7b32
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 87fe5b5f59beeec0780990a1ea2ebc857d17e965
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 c9cfd9445098b88776729168d9ec5244442052df
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 c533db361549bdabb30fa88f2b712c2766580e6a
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 eb08c18bf7cb0e09de15142becabd193614f2704
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 ed36291b5c426b21210972dc8d28f591e22294fc
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 1e2b25b071d3dd1d3fe069d957798713cb961baa
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 fe9184c3b534d95b9ee8d5996081d43936d468fd
Author: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Date:   Thu Aug 27 13:13:07 2020 +0530

    powerpc/pseries: Do not initiate shutdown when system is running on UPS
    
    commit 90a9b102eddf6a3f987d15f4454e26a2532c1c98 upstream.
    
    As per PAPR we have to look for both EPOW sensor value and event
    modifier to identify the type of event and take appropriate action.
    
    In LoPAPR v1.1 section 10.2.2 includes table 136 "EPOW Action Codes":
    
      SYSTEM_SHUTDOWN 3
    
      The system must be shut down. An EPOW-aware OS logs the EPOW error
      log information, then schedules the system to be shut down to begin
      after an OS defined delay internal (default is 10 minutes.)
    
    Then in section 10.3.2.2.8 there is table 146 "Platform Event Log
    Format, Version 6, EPOW Section", which includes the "EPOW Event
    Modifier":
    
      For EPOW sensor value = 3
      0x01 = Normal system shutdown with no additional delay
      0x02 = Loss of utility power, system is running on UPS/Battery
      0x03 = Loss of system critical functions, system should be shutdown
      0x04 = Ambient temperature too high
      All other values = reserved
    
    We have a user space tool (rtas_errd) on LPAR to monitor for
    EPOW_SHUTDOWN_ON_UPS. Once it gets an event it initiates shutdown
    after predefined time. It also starts monitoring for any new EPOW
    events. If it receives "Power restored" event before predefined time
    it will cancel the shutdown. Otherwise after predefined time it will
    shutdown the system.
    
    Commit 79872e35469b ("powerpc/pseries: All events of
    EPOW_SYSTEM_SHUTDOWN must initiate shutdown") changed our handling of
    the "on UPS/Battery" case, to immediately shutdown the system. This
    breaks existing setups that rely on the userspace tool to delay
    shutdown and let the system run on the UPS.
    
    Fixes: 79872e35469b ("powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown")
    Cc: stable@vger.kernel.org # v4.0+
    Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
    [mpe: Massage change log and add PAPR references]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200820061844.306460-1-hegdevasant@linux.vnet.ibm.com
    Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6270d3cd0954707f0c4db83117fb6600b45038d
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Fri Aug 14 20:05:58 2020 -0700

    bonding: fix a potential double-unregister
    
    [ Upstream commit 832707021666411d04795c564a4adea5d6b94f17 ]
    
    When we tear down a network namespace, we unregister all
    the netdevices within it. So we may queue a slave device
    and a bonding device together in the same unregister queue.
    
    If the only slave device is non-ethernet, it would
    automatically unregister the bonding device as well. Thus,
    we may end up unregistering the bonding device twice.
    
    Workaround this special case by checking reg_state.
    
    Fixes: 9b5e383c11b0 ("net: Introduce unregister_netdevice_many()")
    Reported-by: syzbot+af23e7f3e0a7e10c8b67@syzkaller.appspotmail.com
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Andy Gospodarek <andy@greyhouse.net>
    Cc: Jay Vosburgh <j.vosburgh@gmail.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ddbef045e8cc9fc984995c248478646d959445b
Author: Jarod Wilson <jarod@redhat.com>
Date:   Thu Aug 13 10:09:00 2020 -0400

    bonding: show saner speed for broadcast mode
    
    [ Upstream commit 4ca0d9ac3fd8f9f90b72a15d8da2aca3ffb58418 ]
    
    Broadcast mode bonds transmit a copy of all traffic simultaneously out of
    all interfaces, so the "speed" of the bond isn't really the aggregate of
    all interfaces, but rather, the speed of the slowest active interface.
    
    Also, the type of the speed field is u32, not unsigned long, so adjust
    that accordingly, as required to make min() function here without
    complaining about mismatching types.
    
    Fixes: bb5b052f751b ("bond: add support to read speed and duplex via ethtool")
    CC: Jay Vosburgh <j.vosburgh@gmail.com>
    CC: Veaceslav Falico <vfalico@gmail.com>
    CC: Andy Gospodarek <andy@greyhouse.net>
    CC: "David S. Miller" <davem@davemloft.net>
    CC: netdev@vger.kernel.org
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: Jarod Wilson <jarod@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7f299f1a5021d968df7af9fcbeba8c465671b0a
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 a0953a565fb04d45fd8f8326f8ed0fb175e4698c
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 c40fc891ca6c7ada3b10e5c16593e6469d4dfa22
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>