commit 67957f12548c785d0e0b14fd104d2297f3a71835
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 9 19:04:32 2020 +0200

    Linux 4.19.144
    
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    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 4a986bc9bef88e885c1e0202d424af39c77e3ab5
Author: Himadri Pandya <himadrispandya@gmail.com>
Date:   Thu Aug 27 12:23:55 2020 +0530

    net: usb: Fix uninit-was-stored issue in asix_read_phy_addr()
    
    commit a092b7233f0e000cc6f2c71a49e2ecc6f917a5fc upstream.
    
    The buffer size is 2 Bytes and we expect to receive the same amount of
    data. But sometimes we receive less data and run into uninit-was-stored
    issue upon read. Hence modify the error check on the return value to match
    with the buffer size as a prevention.
    
    Reported-and-tested by: syzbot+a7e220df5a81d1ab400e@syzkaller.appspotmail.com
    Signed-off-by: Himadri Pandya <himadrispandya@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b097d5d41a19cca34116ce8ebef566c9c61c482
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Aug 19 10:46:48 2020 +0200

    cfg80211: regulatory: reject invalid hints
    
    commit 47caf685a6854593348f216e0b489b71c10cbe03 upstream.
    
    Reject invalid hints early in order to not cause a kernel
    WARN later if they're restored to or similar.
    
    Reported-by: syzbot+d451401ffd00a60677ee@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?extid=d451401ffd00a60677ee
    Link: https://lore.kernel.org/r/20200819084648.13956-1-johannes@sipsolutions.net
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 221ea9a3da9169dc3c9a364a5f938e215db6419e
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Fri Sep 4 16:36:13 2020 -0700

    mm/hugetlb: fix a race between hugetlb sysctl handlers
    
    commit 17743798d81238ab13050e8e2833699b54e15467 upstream.
    
    There is a race between the assignment of `table->data` and write value
    to the pointer of `table->data` in the __do_proc_doulongvec_minmax() on
    the other thread.
    
      CPU0:                                 CPU1:
                                            proc_sys_write
      hugetlb_sysctl_handler                  proc_sys_call_handler
      hugetlb_sysctl_handler_common             hugetlb_sysctl_handler
        table->data = &tmp;                       hugetlb_sysctl_handler_common
                                                    table->data = &tmp;
          proc_doulongvec_minmax
            do_proc_doulongvec_minmax           sysctl_head_finish
              __do_proc_doulongvec_minmax         unuse_table
                i = table->data;
                *i = val;  // corrupt CPU1's stack
    
    Fix this by duplicating the `table`, and only update the duplicate of
    it.  And introduce a helper of proc_hugetlb_doulongvec_minmax() to
    simplify the code.
    
    The following oops was seen:
    
        BUG: kernel NULL pointer dereference, address: 0000000000000000
        #PF: supervisor instruction fetch in kernel mode
        #PF: error_code(0x0010) - not-present page
        Code: Bad RIP value.
        ...
        Call Trace:
         ? set_max_huge_pages+0x3da/0x4f0
         ? alloc_pool_huge_page+0x150/0x150
         ? proc_doulongvec_minmax+0x46/0x60
         ? hugetlb_sysctl_handler_common+0x1c7/0x200
         ? nr_hugepages_store+0x20/0x20
         ? copy_fd_bitmaps+0x170/0x170
         ? hugetlb_sysctl_handler+0x1e/0x20
         ? proc_sys_call_handler+0x2f1/0x300
         ? unregister_sysctl_table+0xb0/0xb0
         ? __fd_install+0x78/0x100
         ? proc_sys_write+0x14/0x20
         ? __vfs_write+0x4d/0x90
         ? vfs_write+0xef/0x240
         ? ksys_write+0xc0/0x160
         ? __ia32_sys_read+0x50/0x50
         ? __close_fd+0x129/0x150
         ? __x64_sys_write+0x43/0x50
         ? do_syscall_64+0x6c/0x200
         ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: e5ff215941d5 ("hugetlb: multiple hstates for multiple page sizes")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/20200828031146.43035-1-songmuchun@bytedance.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5927539f17dd0c15f5760003d25ad83c107e053
Author: Mrinal Pandey <mrinalmni@gmail.com>
Date:   Fri Sep 4 16:35:52 2020 -0700

    checkpatch: fix the usage of capture group ( ... )
    
    commit 13e45417cedbfc44b1926124b1846f5ee8c6ba4a upstream.
    
    The usage of "capture group (...)" in the immediate condition after `&&`
    results in `$1` being uninitialized.  This issues a warning "Use of
    uninitialized value $1 in regexp compilation at ./scripts/checkpatch.pl
    line 2638".
    
    I noticed this bug while running checkpatch on the set of commits from
    v5.7 to v5.8-rc1 of the kernel on the commits with a diff content in
    their commit message.
    
    This bug was introduced in the script by commit e518e9a59ec3
    ("checkpatch: emit an error when there's a diff in a changelog").  It
    has been in the script since then.
    
    The author intended to store the match made by capture group in variable
    `$1`.  This should have contained the name of the file as `[\w/]+`
    matched.  However, this couldn't be accomplished due to usage of capture
    group and `$1` in the same regular expression.
    
    Fix this by placing the capture group in the condition before `&&`.
    Thus, `$1` can be initialized to the text that capture group matches
    thereby setting it to the desired and required value.
    
    Fixes: e518e9a59ec3 ("checkpatch: emit an error when there's a diff in a changelog")
    Signed-off-by: Mrinal Pandey <mrinalmni@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Tested-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
    Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
    Cc: Joe Perches <joe@perches.com>
    Link: https://lkml.kernel.org/r/20200714032352.f476hanaj2dlmiot@mrinalpandey
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81fb345971c404c796ba28b1bae0b555c35d1376
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Thu Jun 25 11:04:23 2020 -0600

    vfio/pci: Fix SR-IOV VF handling with MMIO blocking
    
    commit ebfa440ce38b7e2e04c3124aa89c8a9f4094cf21 upstream.
    
    SR-IOV VFs do not implement the memory enable bit of the command
    register, therefore this bit is not set in config space after
    pci_enable_device().  This leads to an unintended difference
    between PF and VF in hand-off state to the user.  We can correct
    this by setting the initial value of the memory enable bit in our
    virtualized config space.  There's really no need however to
    ever fault a user on a VF though as this would only indicate an
    error in the user's management of the enable bit, versus a PF
    where the same access could trigger hardware faults.
    
    Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory")
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcaf364fcad9182f6456ffe5b8df0563115fe5ad
Author: James Morse <james.morse@arm.com>
Date:   Wed Sep 2 11:08:21 2020 +0100

    KVM: arm64: Set HCR_EL2.PTW to prevent AT taking synchronous exception
    
    commit 71a7f8cb1ca4ca7214a700b1243626759b6c11d4 upstream.
    
    AT instructions do a translation table walk and return the result, or
    the fault in PAR_EL1. KVM uses these to find the IPA when the value is
    not provided by the CPU in HPFAR_EL1.
    
    If a translation table walk causes an external abort it is taken as an
    exception, even if it was due to an AT instruction. (DDI0487F.a's D5.2.11
    "Synchronous faults generated by address translation instructions")
    
    While we previously made KVM resilient to exceptions taken due to AT
    instructions, the device access causes mismatched attributes, and may
    occur speculatively. Prevent this, by forbidding a walk through memory
    described as device at stage2. Now such AT instructions will report a
    stage2 fault.
    
    Such a fault will cause KVM to restart the guest. If the AT instructions
    always walk the page tables, but guest execution uses the translation cached
    in the TLB, the guest can't make forward progress until the TLB entry is
    evicted. This isn't a problem, as since commit 5dcd0fdbb492 ("KVM: arm64:
    Defer guest entry when an asynchronous exception is pending"), KVM will
    return to the host to process IRQs allowing the rest of the system to keep
    running.
    
    Cc: stable@vger.kernel.org # v4.19
    Signed-off-by: James Morse <james.morse@arm.com>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4df1ff5f836b21c65e799b507e649c3ece7a6c89
Author: James Morse <james.morse@arm.com>
Date:   Wed Sep 2 11:08:20 2020 +0100

    KVM: arm64: Survive synchronous exceptions caused by AT instructions
    
    commit 88a84ccccb3966bcc3f309cdb76092a9892c0260 upstream.
    
    KVM doesn't expect any synchronous exceptions when executing, any such
    exception leads to a panic(). AT instructions access the guest page
    tables, and can cause a synchronous external abort to be taken.
    
    The arm-arm is unclear on what should happen if the guest has configured
    the hardware update of the access-flag, and a memory type in TCR_EL1 that
    does not support atomic operations. B2.2.6 "Possible implementation
    restrictions on using atomic instructions" from DDI0487F.a lists
    synchronous external abort as a possible behaviour of atomic instructions
    that target memory that isn't writeback cacheable, but the page table
    walker may behave differently.
    
    Make KVM robust to synchronous exceptions caused by AT instructions.
    Add a get_user() style helper for AT instructions that returns -EFAULT
    if an exception was generated.
    
    While KVM's version of the exception table mixes synchronous and
    asynchronous exceptions, only one of these can occur at each location.
    
    Re-enter the guest when the AT instructions take an exception on the
    assumption the guest will take the same exception. This isn't guaranteed
    to make forward progress, as the AT instructions may always walk the page
    tables, but guest execution may use the translation cached in the TLB.
    
    This isn't a problem, as since commit 5dcd0fdbb492 ("KVM: arm64: Defer guest
    entry when an asynchronous exception is pending"), KVM will return to the
    host to process IRQs allowing the rest of the system to keep running.
    
    Cc: stable@vger.kernel.org # v4.19
    Signed-off-by: James Morse <james.morse@arm.com>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 204f38310ff14ff2ed68428afa3aca012920faa9
Author: James Morse <james.morse@arm.com>
Date:   Wed Sep 2 11:08:19 2020 +0100

    KVM: arm64: Defer guest entry when an asynchronous exception is pending
    
    commit 5dcd0fdbb492d49dac6bf21c436dfcb5ded0a895 upstream.
    
    SError that occur during world-switch's entry to the guest will be
    accounted to the guest, as the exception is masked until we enter the
    guest... but we want to attribute the SError as precisely as possible.
    
    Reading DISR_EL1 before guest entry requires free registers, and using
    ESB+DISR_EL1 to consume and read back the ESR would leave KVM holding
    a host SError... We would rather leave the SError pending and let the
    host take it once we exit world-switch. To do this, we need to defer
    guest-entry if an SError is pending.
    
    Read the ISR to see if SError (or an IRQ) is pending. If so fake an
    exit. Place this check between __guest_enter()'s save of the host
    registers, and restore of the guest's. SError that occur between
    here and the eret into the guest must have affected the guest's
    registers, which we can naturally attribute to the guest.
    
    The dsb is needed to ensure any previous writes have been done before
    we read ISR_EL1. On systems without the v8.2 RAS extensions this
    doesn't give us anything as we can't contain errors, and the ESR bits
    to describe the severity are all implementation-defined. Replace
    this with a nop for these systems.
    
    Cc: stable@vger.kernel.org # v4.19
    Signed-off-by: James Morse <james.morse@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3290c6ffef87e5acf213e90cb5013bf744e5b607
Author: James Morse <james.morse@arm.com>
Date:   Fri Aug 21 15:07:05 2020 +0100

    KVM: arm64: Add kvm_extable for vaxorcism code
    
    commit e9ee186bb735bfc17fa81dbc9aebf268aee5b41e upstream.
    
    KVM has a one instruction window where it will allow an SError exception
    to be consumed by the hypervisor without treating it as a hypervisor bug.
    This is used to consume asynchronous external abort that were caused by
    the guest.
    
    As we are about to add another location that survives unexpected exceptions,
    generalise this code to make it behave like the host's extable.
    
    KVM's version has to be mapped to EL2 to be accessible on nVHE systems.
    
    The SError vaxorcism code is a one instruction window, so has two entries
    in the extable. Because the KVM code is copied for VHE and nVHE, we end up
    with four entries, half of which correspond with code that isn't mapped.
    
    Signed-off-by: James Morse <james.morse@arm.com>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af2cf2c5a268071dffd53f493ef51fd85891cc2e
Author: Eugeniu Rosca <erosca@de.adit-jv.com>
Date:   Fri Sep 4 16:35:30 2020 -0700

    mm: slub: fix conversion of freelist_corrupted()
    
    commit dc07a728d49cf025f5da2c31add438d839d076c0 upstream.
    
    Commit 52f23478081ae0 ("mm/slub.c: fix corrupted freechain in
    deactivate_slab()") suffered an update when picked up from LKML [1].
    
    Specifically, relocating 'freelist = NULL' into 'freelist_corrupted()'
    created a no-op statement.  Fix it by sticking to the behavior intended
    in the original patch [1].  In addition, make freelist_corrupted()
    immune to passing NULL instead of &freelist.
    
    The issue has been spotted via static analysis and code review.
    
    [1] https://lore.kernel.org/linux-mm/20200331031450.12182-1-dongli.zhang@oracle.com/
    
    Fixes: 52f23478081ae0 ("mm/slub.c: fix corrupted freechain in deactivate_slab()")
    Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Dongli Zhang <dongli.zhang@oracle.com>
    Cc: Joe Jin <joe.jin@oracle.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20200824130643.10291-1-erosca@de.adit-jv.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c00ee626ed48c6ba1f10b8350a8c118846db9ce
Author: Ye Bin <yebin10@huawei.com>
Date:   Tue Sep 1 14:25:43 2020 +0800

    dm thin metadata: Avoid returning cmd->bm wild pointer on error
    
    commit 219403d7e56f9b716ad80ab87db85d29547ee73e upstream.
    
    Maybe __create_persistent_data_objects() caller will use PTR_ERR as a
    pointer, it will lead to some strange things.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67f03c3d6829cf9c4b4015b24326a2cb7b8d6664
Author: Ye Bin <yebin10@huawei.com>
Date:   Tue Sep 1 14:25:42 2020 +0800

    dm cache metadata: Avoid returning cmd->bm wild pointer on error
    
    commit d16ff19e69ab57e08bf908faaacbceaf660249de upstream.
    
    Maybe __create_persistent_data_objects() caller will use PTR_ERR as a
    pointer, it will lead to some strange things.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 154096e9966123f198cfc2f959bc559c562fc6b7
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Aug 24 11:09:47 2020 -0400

    dm writecache: handle DAX to partitions on persistent memory correctly
    
    commit f9e040efcc28309e5c592f7e79085a9a52e31f58 upstream.
    
    The function dax_direct_access doesn't take partitions into account,
    it always maps pages from the beginning of the device. Therefore,
    persistent_memory_claim() must get the partition offset using
    get_start_sect() and add it to the page offsets passed to
    dax_direct_access().
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Fixes: 48debafe4f2f ("dm: add writecache target")
    Cc: stable@vger.kernel.org # 4.18+
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8bb7740aa313994bfa4c21cba399f65985a8a35
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Sep 2 12:32:45 2020 -0400

    libata: implement ATA_HORKAGE_MAX_TRIM_128M and apply to Sandisks
    
    commit 3b5455636fe26ea21b4189d135a424a6da016418 upstream.
    
    All three generations of Sandisk SSDs lock up hard intermittently.
    Experiments showed that disabling NCQ lowered the failure rate significantly
    and the kernel has been disabling NCQ for some models of SD7's and 8's,
    which is obviously undesirable.
    
    Karthik worked with Sandisk to root cause the hard lockups to trim commands
    larger than 128M. This patch implements ATA_HORKAGE_MAX_TRIM_128M which
    limits max trim size to 128M and applies it to all three generations of
    Sandisk SSDs.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Karthik Shivaram <karthikgs@fb.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b48bcb664b657ae94b19c0728978c88e012f7a37
Author: Ming Lei <ming.lei@redhat.com>
Date:   Mon Aug 17 18:00:55 2020 +0800

    block: allow for_each_bvec to support zero len bvec
    
    commit 7e24969022cbd61ddc586f14824fc205661bb124 upstream.
    
    Block layer usually doesn't support or allow zero-length bvec. Since
    commit 1bdc76aea115 ("iov_iter: use bvec iterator to implement
    iterate_bvec()"), iterate_bvec() switches to bvec iterator. However,
    Al mentioned that 'Zero-length segments are not disallowed' in iov_iter.
    
    Fixes for_each_bvec() so that it can move on after seeing one zero
    length bvec.
    
    Fixes: 1bdc76aea115 ("iov_iter: use bvec iterator to implement iterate_bvec()")
    Reported-by: syzbot <syzbot+61acc40a49a3e46e25ea@syzkaller.appspotmail.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Tested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: <stable@vger.kernel.org>
    Link: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2262077.html
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0a689f84d53a8b923302cfab10527ada27d962c
Author: Max Staudt <max@enpas.org>
Date:   Thu Aug 27 17:49:00 2020 +0200

    affs: fix basic permission bits to actually work
    
    commit d3a84a8d0dde4e26bc084b36ffcbdc5932ac85e2 upstream.
    
    The basic permission bits (protection bits in AmigaOS) have been broken
    in Linux' AFFS - it would only set bits, but never delete them.
    Also, contrary to the documentation, the Archived bit was not handled.
    
    Let's fix this for good, and set the bits such that Linux and classic
    AmigaOS can coexist in the most peaceful manner.
    
    Also, update the documentation to represent the current state of things.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Max Staudt <max@enpas.org>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd1c0e39c65dfc2c7a5274dd4d6de50c3c355025
Author: Sean Young <sean@mess.org>
Date:   Sat Aug 8 13:19:12 2020 +0200

    media: rc: uevent sysfs file races with rc_unregister_device()
    
    commit 4f0835d6677dc69263f90f976524cb92b257d9f4 upstream.
    
    Only report uevent file contents if device still registered, else we
    might read freed memory.
    
    Reported-by: syzbot+ceef16277388d6f24898@syzkaller.appspotmail.com
    Cc: Hillf Danton <hdanton@sina.com>
    Cc: <stable@vger.kernel.org> # 4.16+
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 814f95011c5197683335df082761482667d5ba51
Author: Sean Young <sean@mess.org>
Date:   Sat Aug 8 13:38:02 2020 +0200

    media: rc: do not access device via sysfs after rc_unregister_device()
    
    commit a2e2d73fa28136598e84db9d021091f1b98cbb1a upstream.
    
    Device drivers do not expect to have change_protocol or wakeup
    re-programming to be accesed after rc_unregister_device(). This can
    cause the device driver to access deallocated resources.
    
    Cc: <stable@vger.kernel.org> # 4.16+
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0a7b7fe0e0f7baa7c1779e401d293d176307c51
Author: Dan Crawford <dnlcrwfrd@gmail.com>
Date:   Sat Aug 29 12:49:46 2020 +1000

    ALSA: hda - Fix silent audio output and corrupted input on MSI X570-A PRO
    
    commit 15cbff3fbbc631952c346744f862fb294504b5e2 upstream.
    
    Following Christian Lachner's patch for Gigabyte X570-based motherboards,
    also patch the MSI X570-A PRO motherboard; the ALC1220 codec requires the
    same workaround for Clevo laptops to enforce the DAC/mixer connection
    path. Set up a quirk entry for that.
    
    I suspect most if all X570 motherboards will require similar patches.
    
    [ The entries reordered in the SSID order -- tiwai ]
    
    Related buglink: https://bugzilla.kernel.org/show_bug.cgi?id=205275
    Signed-off-by: Dan Crawford <dnlcrwfrd@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200829024946.5691-1-dnlcrwfrd@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3319b83f6cc68b709ec43eb90d8617be2d7fa834
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sun Aug 23 16:55:45 2020 +0900

    ALSA: firewire-digi00x: exclude Avid Adrenaline from detection
    
    commit acd46a6b6de88569654567810acad2b0a0a25cea upstream.
    
    Avid Adrenaline is reported that ALSA firewire-digi00x driver is bound to.
    However, as long as he investigated, the design of this model is hardly
    similar to the one of Digi 00x family. It's better to exclude the model
    from modalias of ALSA firewire-digi00x driver.
    
    This commit changes device entries so that the model is excluded.
    
    $ python3 crpp < ~/git/am-config-rom/misc/avid-adrenaline.img
                   ROM header and bus information block
                   -----------------------------------------------------------------
    400  04203a9c  bus_info_length 4, crc_length 32, crc 15004
    404  31333934  bus_name "1394"
    408  e064a002  irmc 1, cmc 1, isc 1, bmc 0, cyc_clk_acc 100, max_rec 10 (2048)
    40c  00a07e01  company_id 00a07e     |
    410  00085257  device_id 0100085257  | EUI-64 00a07e0100085257
    
                   root directory
                   -----------------------------------------------------------------
    414  0005d08c  directory_length 5, crc 53388
    418  0300a07e  vendor
    41c  8100000c  --> descriptor leaf at 44c
    420  0c008380  node capabilities
    424  8d000002  --> eui-64 leaf at 42c
    428  d1000004  --> unit directory at 438
    
                   eui-64 leaf at 42c
                   -----------------------------------------------------------------
    42c  0002410f  leaf_length 2, crc 16655
    430  00a07e01  company_id 00a07e     |
    434  00085257  device_id 0100085257  | EUI-64 00a07e0100085257
    
                   unit directory at 438
                   -----------------------------------------------------------------
    438  0004d6c9  directory_length 4, crc 54985
    43c  1200a02d  specifier id: 1394 TA
    440  13014001  version: Vender Unique and AV/C
    444  17000001  model
    448  81000009  --> descriptor leaf at 46c
    
                   descriptor leaf at 44c
                   -----------------------------------------------------------------
    44c  00077205  leaf_length 7, crc 29189
    450  00000000  textual descriptor
    454  00000000  minimal ASCII
    458  41766964  "Avid"
    45c  20546563  " Tec"
    460  686e6f6c  "hnol"
    464  6f677900  "ogy"
    468  00000000
    
                   descriptor leaf at 46c
                   -----------------------------------------------------------------
    46c  000599a5  leaf_length 5, crc 39333
    470  00000000  textual descriptor
    474  00000000  minimal ASCII
    478  41647265  "Adre"
    47c  6e616c69  "nali"
    480  6e650000  "ne"
    
    Reported-by: Simon Wood <simon@mungewell.org>
    Fixes: 9edf723fd858 ("ALSA: firewire-digi00x: add skeleton for Digi 002/003 family")
    Cc: <stable@vger.kernel.org> # 4.4+
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://lore.kernel.org/r/20200823075545.56305-1-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 374843e4df7503ad71fd9db89df1a964958a9607
Author: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Date:   Wed Aug 26 20:03:06 2020 +0300

    ALSA: hda/hdmi: always check pin power status in i915 pin fixup
    
    commit 858e0ad9301d1270c02b5aca97537d2d6ee9dd68 upstream.
    
    When system is suspended with active audio playback to HDMI/DP, two
    alternative sequences can happen at resume:
      a) monitor is detected first and ALSA prepare follows normal
         stream setup sequence, or
      b) ALSA prepare is called first, but monitor is not yet detected,
         so PCM is restarted without a pin,
    
    In case of (b), on i915 systems, haswell_verify_D0() is not called at
    resume and the pin power state may be incorrect. Result is lack of audio
    after resume with no error reported back to user-space.
    
    Fix the problem by always verifying converter and pin state in the
    i915_pin_cvt_fixup().
    
    BugLink: https://github.com/thesofproject/linux/issues/2388
    Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200826170306.701566-1-kai.vehmanen@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 569e1b621797a9cdba8369f45fc5612ce1bec323
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Sep 1 15:18:02 2020 +0200

    ALSA: pcm: oss: Remove superfluous WARN_ON() for mulaw sanity check
    
    commit 949a1ebe8cea7b342085cb6a4946b498306b9493 upstream.
    
    The PCM OSS mulaw plugin has a check of the format of the counter part
    whether it's a linear format.  The check is with snd_BUG_ON() that
    emits WARN_ON() when the debug config is set, and it confuses
    syzkaller as if it were a serious issue.  Let's drop snd_BUG_ON() for
    avoiding that.
    
    While we're at it, correct the error code to a more suitable, EINVAL.
    
    Reported-by: syzbot+23b22dc2e0b81cbfcc95@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200901131802.18157-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a69e790bce633b69759817cc53d22e0c8ab1c657
Author: Tong Zhang <ztong0001@gmail.com>
Date:   Mon Aug 24 18:45:41 2020 -0400

    ALSA: ca0106: fix error code handling
    
    commit ee0761d1d8222bcc5c86bf10849dc86cf008557c upstream.
    
    snd_ca0106_spi_write() returns 1 on error, snd_ca0106_pcm_power_dac()
    is returning the error code directly, and the caller is expecting an
    negative error code
    
    Signed-off-by: Tong Zhang <ztong0001@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200824224541.1260307-1-ztong0001@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 669f22290ec9204145b38a6eedcb8461c279769b
Author: Rogan Dawes <rogan@dawes.za.net>
Date:   Wed Jul 17 11:14:33 2019 +0200

    usb: qmi_wwan: add D-Link DWM-222 A2 device ID
    
    [ Upstream commit 7d6053097311643545a8118100175a39bd6fa637 ]
    
    Signed-off-by: Rogan Dawes <rogan@dawes.za.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d7de9fe191d4a86ba40f7a549bb265e05635f84
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Wed Oct 9 11:07:18 2019 +0200

    net: usb: qmi_wwan: add Telit 0x1050 composition
    
    [ Upstream commit e0ae2c578d3909e60e9448207f5d83f785f1129f ]
    
    This patch adds support for Telit FN980 0x1050 composition
    
    0x1050: tty, adb, rmnet, tty, tty, tty, tty
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c9bf5c3ed15fd6ad777663c636a6f4a5d9edf2c
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Mon Aug 10 11:42:27 2020 -0400

    btrfs: fix potential deadlock in the search ioctl
    
    [ Upstream commit a48b73eca4ceb9b8a4b97f290a065335dbcd8a04 ]
    
    With the conversion of the tree locks to rwsem I got the following
    lockdep splat:
    
      ======================================================
      WARNING: possible circular locking dependency detected
      5.8.0-rc7-00165-g04ec4da5f45f-dirty #922 Not tainted
      ------------------------------------------------------
      compsize/11122 is trying to acquire lock:
      ffff889fabca8768 (&mm->mmap_lock#2){++++}-{3:3}, at: __might_fault+0x3e/0x90
    
      but task is already holding lock:
      ffff889fe720fe40 (btrfs-fs-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x39/0x180
    
      which lock already depends on the new lock.
    
      the existing dependency chain (in reverse order) is:
    
      -> #2 (btrfs-fs-00){++++}-{3:3}:
             down_write_nested+0x3b/0x70
             __btrfs_tree_lock+0x24/0x120
             btrfs_search_slot+0x756/0x990
             btrfs_lookup_inode+0x3a/0xb4
             __btrfs_update_delayed_inode+0x93/0x270
             btrfs_async_run_delayed_root+0x168/0x230
             btrfs_work_helper+0xd4/0x570
             process_one_work+0x2ad/0x5f0
             worker_thread+0x3a/0x3d0
             kthread+0x133/0x150
             ret_from_fork+0x1f/0x30
    
      -> #1 (&delayed_node->mutex){+.+.}-{3:3}:
             __mutex_lock+0x9f/0x930
             btrfs_delayed_update_inode+0x50/0x440
             btrfs_update_inode+0x8a/0xf0
             btrfs_dirty_inode+0x5b/0xd0
             touch_atime+0xa1/0xd0
             btrfs_file_mmap+0x3f/0x60
             mmap_region+0x3a4/0x640
             do_mmap+0x376/0x580
             vm_mmap_pgoff+0xd5/0x120
             ksys_mmap_pgoff+0x193/0x230
             do_syscall_64+0x50/0x90
             entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
      -> #0 (&mm->mmap_lock#2){++++}-{3:3}:
             __lock_acquire+0x1272/0x2310
             lock_acquire+0x9e/0x360
             __might_fault+0x68/0x90
             _copy_to_user+0x1e/0x80
             copy_to_sk.isra.32+0x121/0x300
             search_ioctl+0x106/0x200
             btrfs_ioctl_tree_search_v2+0x7b/0xf0
             btrfs_ioctl+0x106f/0x30a0
             ksys_ioctl+0x83/0xc0
             __x64_sys_ioctl+0x16/0x20
             do_syscall_64+0x50/0x90
             entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
      other info that might help us debug this:
    
      Chain exists of:
        &mm->mmap_lock#2 --> &delayed_node->mutex --> btrfs-fs-00
    
       Possible unsafe locking scenario:
    
             CPU0                    CPU1
             ----                    ----
        lock(btrfs-fs-00);
                                     lock(&delayed_node->mutex);
                                     lock(btrfs-fs-00);
        lock(&mm->mmap_lock#2);
    
       *** DEADLOCK ***
    
      1 lock held by compsize/11122:
       #0: ffff889fe720fe40 (btrfs-fs-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x39/0x180
    
      stack backtrace:
      CPU: 17 PID: 11122 Comm: compsize Kdump: loaded Not tainted 5.8.0-rc7-00165-g04ec4da5f45f-dirty #922
      Hardware name: Quanta Tioga Pass Single Side 01-0030993006/Tioga Pass Single Side, BIOS F08_3A18 12/20/2018
      Call Trace:
       dump_stack+0x78/0xa0
       check_noncircular+0x165/0x180
       __lock_acquire+0x1272/0x2310
       lock_acquire+0x9e/0x360
       ? __might_fault+0x3e/0x90
       ? find_held_lock+0x72/0x90
       __might_fault+0x68/0x90
       ? __might_fault+0x3e/0x90
       _copy_to_user+0x1e/0x80
       copy_to_sk.isra.32+0x121/0x300
       ? btrfs_search_forward+0x2a6/0x360
       search_ioctl+0x106/0x200
       btrfs_ioctl_tree_search_v2+0x7b/0xf0
       btrfs_ioctl+0x106f/0x30a0
       ? __do_sys_newfstat+0x5a/0x70
       ? ksys_ioctl+0x83/0xc0
       ksys_ioctl+0x83/0xc0
       __x64_sys_ioctl+0x16/0x20
       do_syscall_64+0x50/0x90
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    The problem is we're doing a copy_to_user() while holding tree locks,
    which can deadlock if we have to do a page fault for the copy_to_user().
    This exists even without my locking changes, so it needs to be fixed.
    Rework the search ioctl to do the pre-fault and then
    copy_to_user_nofault for the copying.
    
    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>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfb4721fce554cb596ea86af116d3d68a4d91254
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Sat Nov 2 00:17:56 2019 +0100

    uaccess: Add non-pagefault user-space write function
    
    [ Upstream commit 1d1585ca0f48fe7ed95c3571f3e4a82b2b5045dc ]
    
    Commit 3d7081822f7f ("uaccess: Add non-pagefault user-space read functions")
    missed to add probe write function, therefore factor out a probe_write_common()
    helper with most logic of probe_kernel_write() except setting KERNEL_DS, and
    add a new probe_user_write() helper so it can be used from BPF side.
    
    Again, on some archs, the user address space and kernel address space can
    co-exist and be overlapping, so in such case, setting KERNEL_DS would mean
    that the given address is treated as being in kernel address space.
    
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Andrii Nakryiko <andriin@fb.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Link: https://lore.kernel.org/bpf/9df2542e68141bfa3addde631441ee45503856a8.1572649915.git.daniel@iogearbox.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 61135a9c74c8f79fce637c28f6109ab58467d5bd
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Wed May 15 14:38:18 2019 +0900

    uaccess: Add non-pagefault user-space read functions
    
    [ Upstream commit 3d7081822f7f9eab867d9bcc8fd635208ec438e0 ]
    
    Add probe_user_read(), strncpy_from_unsafe_user() and
    strnlen_unsafe_user() which allows caller to access user-space
    in IRQ context.
    
    Current probe_kernel_read() and strncpy_from_unsafe() are
    not available for user-space memory, because it sets
    KERNEL_DS while accessing data. On some arch, user address
    space and kernel address space can be co-exist, but others
    can not. In that case, setting KERNEL_DS means given
    address is treated as a kernel address space.
    Also strnlen_user() is only available from user context since
    it can sleep if pagefault is enabled.
    
    To access user-space memory without pagefault, we need
    these new functions which sets USER_DS while accessing
    the data.
    
    Link: http://lkml.kernel.org/r/155789869802.26965.4940338412595759063.stgit@devnote2
    
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4689380be50c038b584933171c2f1dbca90a56be
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Mon Aug 10 11:42:31 2020 -0400

    btrfs: set the lockdep class for log tree extent buffers
    
    [ Upstream commit d3beaa253fd6fa40b8b18a216398e6e5376a9d21 ]
    
    These are special extent buffers that get rewound in order to lookup
    the state of the tree at a specific point in time.  As such they do not
    go through the normal initialization paths that set their lockdep class,
    so handle them appropriately when they are created and before they are
    locked.
    
    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>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88814d0bc8cdbf651e03a62de1d4530d337b8952
Author: Nikolay Borisov <nborisov@suse.com>
Date:   Wed Aug 15 18:26:54 2018 +0300

    btrfs: Remove extraneous extent_buffer_get from tree_mod_log_rewind
    
    [ Upstream commit 24cee18a1c1d7c731ea5987e0c99daea22ae7f4a ]
    
    When a rewound buffer is created it already has a ref count of 1 and the
    dummy flag set. Then another ref is taken bumping the count to 2.
    Finally when this buffer is released from btrfs_release_path the extra
    reference is decremented by the special handling code in
    free_extent_buffer.
    
    However, this special code is in fact redundant sinca ref count of 1 is
    still correct since the buffer is only accessed via btrfs_path struct.
    This paves the way forward of removing the special handling in
    free_extent_buffer.
    
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ca6e25f06070fb5a8f8429f4e7a53ff538d1673
Author: Nikolay Borisov <nborisov@suse.com>
Date:   Wed Aug 15 18:26:53 2018 +0300

    btrfs: Remove redundant extent_buffer_get in get_old_root
    
    [ Upstream commit 6c122e2a0c515cfb3f3a9cefb5dad4cb62109c78 ]
    
    get_old_root used used only by btrfs_search_old_slot to initialise the
    path structure. The old root is always a cloned buffer (either via alloc
    dummy or via btrfs_clone_extent_buffer) and its reference count is 2: 1
    from allocation, 1 from extent_buffer_get call in get_old_root.
    
    This latter explicit ref count acquire operation is in fact unnecessary
    since the semantic is such that the newly allocated buffer is handed
    over to the btrfs_path for lifetime management. Considering this just
    remove the extra extent_buffer_get in get_old_root.
    
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da7aea6eb5608695f590dcd72523536b709d0399
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Sep 7 15:47:22 2020 +0530

    vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
    
    commit abafbc551fddede3e0a08dee1dcde08fc0eb8476 upstream.
    
    Accessing the disabled memory space of a PCI device would typically
    result in a master abort response on conventional PCI, or an
    unsupported request on PCI express.  The user would generally see
    these as a -1 response for the read return data and the write would be
    silently discarded, possibly with an uncorrected, non-fatal AER error
    triggered on the host.  Some systems however take it upon themselves
    to bring down the entire system when they see something that might
    indicate a loss of data, such as this discarded write to a disabled
    memory space.
    
    To avoid this, we want to try to block the user from accessing memory
    spaces while they're disabled.  We start with a semaphore around the
    memory enable bit, where writers modify the memory enable state and
    must be serialized, while readers make use of the memory region and
    can access in parallel.  Writers include both direct manipulation via
    the command register, as well as any reset path where the internal
    mechanics of the reset may both explicitly and implicitly disable
    memory access, and manipulation of the MSI-X configuration, where the
    MSI-X vector table resides in MMIO space of the device.  Readers
    include the read and write file ops to access the vfio device fd
    offsets as well as memory mapped access.  In the latter case, we make
    use of our new vma list support to zap, or invalidate, those memory
    mappings in order to force them to be faulted back in on access.
    
    Our semaphore usage will stall user access to MMIO spaces across
    internal operations like reset, but the user might experience new
    behavior when trying to access the MMIO space while disabled via the
    PCI command register.  Access via read or write while disabled will
    return -EIO and access via memory maps will result in a SIGBUS.  This
    is expected to be compatible with known use cases and potentially
    provides better error handling capabilities than present in the
    hardware, while avoiding the more readily accessible and severe
    platform error responses that might otherwise occur.
    
    Fixes: CVE-2020-12888
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    [Ajay: Regenerated the patch for v4.19]
    Signed-off-by: Ajay Kaher <akaher@vmware.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c7f2f24a886a398a539baf30f56688308f93b70
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Sep 7 15:47:21 2020 +0530

    vfio-pci: Fault mmaps to enable vma tracking
    
    commit 11c4cd07ba111a09f49625f9e4c851d83daf0a22 upstream.
    
    Rather than calling remap_pfn_range() when a region is mmap'd, setup
    a vm_ops handler to support dynamic faulting of the range on access.
    This allows us to manage a list of vmas actively mapping the area that
    we can later use to invalidate those mappings.  The open callback
    invalidates the vma range so that all tracking is inserted in the
    fault handler and removed in the close handler.
    
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    [Ajay: Regenerated the patch for v4.19]
    Signed-off-by: Ajay Kaher <akaher@vmware.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6df210762f80f174affd2bbcb346f2f0b233546c
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Sep 7 15:47:20 2020 +0530

    vfio/type1: Support faulting PFNMAP vmas
    
    commit 41311242221e3482b20bfed10fa4d9db98d87016 upstream.
    
    With conversion to follow_pfn(), DMA mapping a PFNMAP range depends on
    the range being faulted into the vma.  Add support to manually provide
    that, in the same way as done on KVM with hva_to_pfn_remapped().
    
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    [Ajay: Regenerated the patch for v4.19]
    Signed-off-by: Ajay Kaher <akaher@vmware.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43eadb9e37a2b0888d38e1ebe5d2206928a38e3b
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Mon Aug 10 11:42:26 2020 -0400

    btrfs: drop path before adding new uuid tree entry
    
    commit 9771a5cf937129307d9f58922d60484d58ababe7 upstream.
    
    With the conversion of the tree locks to rwsem I got the following
    lockdep splat:
    
      ======================================================
      WARNING: possible circular locking dependency detected
      5.8.0-rc7-00167-g0d7ba0c5b375-dirty #925 Not tainted
      ------------------------------------------------------
      btrfs-uuid/7955 is trying to acquire lock:
      ffff88bfbafec0f8 (btrfs-root-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x39/0x180
    
      but task is already holding lock:
      ffff88bfbafef2a8 (btrfs-uuid-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x39/0x180
    
      which lock already depends on the new lock.
    
      the existing dependency chain (in reverse order) is:
    
      -> #1 (btrfs-uuid-00){++++}-{3:3}:
             down_read_nested+0x3e/0x140
             __btrfs_tree_read_lock+0x39/0x180
             __btrfs_read_lock_root_node+0x3a/0x50
             btrfs_search_slot+0x4bd/0x990
             btrfs_uuid_tree_add+0x89/0x2d0
             btrfs_uuid_scan_kthread+0x330/0x390
             kthread+0x133/0x150
             ret_from_fork+0x1f/0x30
    
      -> #0 (btrfs-root-00){++++}-{3:3}:
             __lock_acquire+0x1272/0x2310
             lock_acquire+0x9e/0x360
             down_read_nested+0x3e/0x140
             __btrfs_tree_read_lock+0x39/0x180
             __btrfs_read_lock_root_node+0x3a/0x50
             btrfs_search_slot+0x4bd/0x990
             btrfs_find_root+0x45/0x1b0
             btrfs_read_tree_root+0x61/0x100
             btrfs_get_root_ref.part.50+0x143/0x630
             btrfs_uuid_tree_iterate+0x207/0x314
             btrfs_uuid_rescan_kthread+0x12/0x50
             kthread+0x133/0x150
             ret_from_fork+0x1f/0x30
    
      other info that might help us debug this:
    
       Possible unsafe locking scenario:
    
             CPU0                    CPU1
             ----                    ----
        lock(btrfs-uuid-00);
                                     lock(btrfs-root-00);
                                     lock(btrfs-uuid-00);
        lock(btrfs-root-00);
    
       *** DEADLOCK ***
    
      1 lock held by btrfs-uuid/7955:
       #0: ffff88bfbafef2a8 (btrfs-uuid-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x39/0x180
    
      stack backtrace:
      CPU: 73 PID: 7955 Comm: btrfs-uuid Kdump: loaded Not tainted 5.8.0-rc7-00167-g0d7ba0c5b375-dirty #925
      Hardware name: Quanta Tioga Pass Single Side 01-0030993006/Tioga Pass Single Side, BIOS F08_3A18 12/20/2018
      Call Trace:
       dump_stack+0x78/0xa0
       check_noncircular+0x165/0x180
       __lock_acquire+0x1272/0x2310
       lock_acquire+0x9e/0x360
       ? __btrfs_tree_read_lock+0x39/0x180
       ? btrfs_root_node+0x1c/0x1d0
       down_read_nested+0x3e/0x140
       ? __btrfs_tree_read_lock+0x39/0x180
       __btrfs_tree_read_lock+0x39/0x180
       __btrfs_read_lock_root_node+0x3a/0x50
       btrfs_search_slot+0x4bd/0x990
       btrfs_find_root+0x45/0x1b0
       btrfs_read_tree_root+0x61/0x100
       btrfs_get_root_ref.part.50+0x143/0x630
       btrfs_uuid_tree_iterate+0x207/0x314
       ? btree_readpage+0x20/0x20
       btrfs_uuid_rescan_kthread+0x12/0x50
       kthread+0x133/0x150
       ? kthread_create_on_node+0x60/0x60
       ret_from_fork+0x1f/0x30
    
    This problem exists because we have two different rescan threads,
    btrfs_uuid_scan_kthread which creates the uuid tree, and
    btrfs_uuid_tree_iterate that goes through and updates or deletes any out
    of date roots.  The problem is they both do things in different order.
    btrfs_uuid_scan_kthread() reads the tree_root, and then inserts entries
    into the uuid_root.  btrfs_uuid_tree_iterate() scans the uuid_root, but
    then does a btrfs_get_fs_root() which can read from the tree_root.
    
    It's actually easy enough to not be holding the path in
    btrfs_uuid_scan_kthread() when we add a uuid entry, as we already drop
    it further down and re-start the search when we loop.  So simply move
    the path release before we add our entry to the uuid tree.
    
    This also fixes a problem where we're holding a path open after we do
    btrfs_end_transaction(), which has it's own problems.
    
    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>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 884fee7632168ab59ed49a26de430fa3ed5c6a86
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Sat Sep 5 08:13:02 2020 -0400

    xfs: don't update mtime on COW faults
    
    commit b17164e258e3888d376a7434415013175d637377 upstream.
    
    When running in a dax mode, if the user maps a page with MAP_PRIVATE and
    PROT_WRITE, the xfs filesystem would incorrectly update ctime and mtime
    when the user hits a COW fault.
    
    This breaks building of the Linux kernel.  How to reproduce:
    
     1. extract the Linux kernel tree on dax-mounted xfs filesystem
     2. run make clean
     3. run make -j12
     4. run make -j12
    
    at step 4, make would incorrectly rebuild the whole kernel (although it
    was already built in step 3).
    
    The reason for the breakage is that almost all object files depend on
    objtool.  When we run objtool, it takes COW page fault on its .data
    section, and these faults will incorrectly update the timestamp of the
    objtool binary.  The updated timestamp causes make to rebuild the whole
    tree.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da0d5ccf845fd5337ce9afaddd46e99859f78502
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Sat Sep 5 08:12:01 2020 -0400

    ext2: don't update mtime on COW faults
    
    commit 1ef6ea0efe8e68d0299dad44c39dc6ad9e5d1f39 upstream.
    
    When running in a dax mode, if the user maps a page with MAP_PRIVATE and
    PROT_WRITE, the ext2 filesystem would incorrectly update ctime and mtime
    when the user hits a COW fault.
    
    This breaks building of the Linux kernel.  How to reproduce:
    
     1. extract the Linux kernel tree on dax-mounted ext2 filesystem
     2. run make clean
     3. run make -j12
     4. run make -j12
    
    at step 4, make would incorrectly rebuild the whole kernel (although it
    was already built in step 3).
    
    The reason for the breakage is that almost all object files depend on
    objtool.  When we run objtool, it takes COW page fault on its .data
    section, and these faults will incorrectly update the timestamp of the
    objtool binary.  The updated timestamp causes make to rebuild the whole
    tree.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95968e5cbb5db7ff33288d01a95349d476f19248
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Fri Sep 4 16:36:19 2020 -0700

    include/linux/log2.h: add missing () around n in roundup_pow_of_two()
    
    [ Upstream commit 428fc0aff4e59399ec719ffcc1f7a5d29a4ee476 ]
    
    Otherwise gcc generates warnings if the expression is complicated.
    
    Fixes: 312a0c170945 ("[PATCH] LOG2: Alter roundup_pow_of_two() so that it can use a ilog2() on a constant")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Link: https://lkml.kernel.org/r/0-v1-8a2697e3c003+41165-log_brackets_jgg@nvidia.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0a3e33221cc9e6ba141d9d62c178c9022f56989
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Jul 6 11:33:38 2020 -0700

    thermal: ti-soc-thermal: Fix bogus thermal shutdowns for omap4430
    
    [ Upstream commit 30d24faba0532d6972df79a1bf060601994b5873 ]
    
    We can sometimes get bogus thermal shutdowns on omap4430 at least with
    droid4 running idle with a battery charger connected:
    
    thermal thermal_zone0: critical temperature reached (143 C), shutting down
    
    Dumping out the register values shows we can occasionally get a 0x7f value
    that is outside the TRM listed values in the ADC conversion table. And then
    we get a normal value when reading again after that. Reading the register
    multiple times does not seem help avoiding the bogus values as they stay
    until the next sample is ready.
    
    Looking at the TRM chapter "18.4.10.2.3 ADC Codes Versus Temperature", we
    should have values from 13 to 107 listed with a total of 95 values. But
    looking at the omap4430_adc_to_temp array, the values are off, and the
    end values are missing. And it seems that the 4430 ADC table is similar
    to omap3630 rather than omap4460.
    
    Let's fix the issue by using values based on the omap3630 table and just
    ignoring invalid values. Compared to the 4430 TRM, the omap3630 table has
    the missing values added while the TRM table only shows every second
    value.
    
    Note that sometimes the ADC register values within the valid table can
    also be way off for about 1 out of 10 values. But it seems that those
    just show about 25 C too low values rather than too high values. So those
    do not cause a bogus thermal shutdown.
    
    Fixes: 1a31270e54d7 ("staging: omap-thermal: add OMAP4 data structures")
    Cc: Merlijn Wajer <merlijn@wizzup.org>
    Cc: Pavel Machek <pavel@ucw.cz>
    Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20200706183338.25622-1-tony@atomide.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 519837cc18e3389a95ffbff5f165030c0b3d7d42
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Fri Aug 28 08:06:15 2020 +0800

    iommu/vt-d: Serialize IOMMU GCMD register modifications
    
    [ Upstream commit 6e4e9ec65078093165463c13d4eb92b3e8d7b2e8 ]
    
    The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG General
    Description) that:
    
    If multiple control fields in this register need to be modified, software
    must serialize the modifications through multiple writes to this register.
    
    However, in irq_remapping.c, modifications of IRE and CFI are done in one
    write. We need to do two separate writes with STS checking after each. It
    also checks the status register before writing command register to avoid
    unnecessary register write.
    
    Fixes: af8d102f999a4 ("x86/intel/irq_remapping: Clean up x2apic opt-out security warning mess")
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Cc: Kevin Tian <kevin.tian@intel.com>
    Cc: Ashok Raj <ashok.raj@intel.com>
    Link: https://lore.kernel.org/r/20200828000615.8281-1-baolu.lu@linux.intel.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f10d77cdedbe8b4aaf2799f4cea6126b2612dd93
Author: Huang Ying <ying.huang@intel.com>
Date:   Fri Sep 4 14:10:47 2020 +0800

    x86, fakenuma: Fix invalid starting node ID
    
    [ Upstream commit ccae0f36d500aef727f98acd8d0601e6b262a513 ]
    
    Commit:
    
      cc9aec03e58f ("x86/numa_emulation: Introduce uniform split capability")
    
    uses "-1" as the starting node ID, which causes the strange kernel log as
    follows, when "numa=fake=32G" is added to the kernel command line:
    
        Faking node -1 at [mem 0x0000000000000000-0x0000000893ffffff] (35136MB)
        Faking node 0 at [mem 0x0000001840000000-0x000000203fffffff] (32768MB)
        Faking node 1 at [mem 0x0000000894000000-0x000000183fffffff] (64192MB)
        Faking node 2 at [mem 0x0000002040000000-0x000000283fffffff] (32768MB)
        Faking node 3 at [mem 0x0000002840000000-0x000000303fffffff] (32768MB)
    
    And finally the kernel crashes:
    
        BUG: Bad page state in process swapper  pfn:00011
        page:(____ptrval____) refcount:0 mapcount:1 mapping:(____ptrval____) index:0x55cd7e44b270 pfn:0x11
        failed to read mapping contents, not a valid kernel address?
        flags: 0x5(locked|uptodate)
        raw: 0000000000000005 000055cd7e44af30 000055cd7e44af50 0000000100000006
        raw: 000055cd7e44b270 000055cd7e44b290 0000000000000000 000055cd7e44b510
        page dumped because: page still charged to cgroup
        page->mem_cgroup:000055cd7e44b510
        Modules linked in:
        CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-rc2 #1
        Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
        Call Trace:
         dump_stack+0x57/0x80
         bad_page.cold+0x63/0x94
         __free_pages_ok+0x33f/0x360
         memblock_free_all+0x127/0x195
         mem_init+0x23/0x1f5
         start_kernel+0x219/0x4f5
         secondary_startup_64+0xb6/0xc0
    
    Fix this bug via using 0 as the starting node ID.  This restores the
    original behavior before cc9aec03e58f.
    
    [ mingo: Massaged the changelog. ]
    
    Fixes: cc9aec03e58f ("x86/numa_emulation: Introduce uniform split capability")
    Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20200904061047.612950-1-ying.huang@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aea7be6444a67e455ebcfcc0501c32bee50a47d6
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Thu Sep 3 14:28:54 2020 -0400

    tg3: Fix soft lockup when tg3_reset_task() fails.
    
    [ Upstream commit 556699341efa98243e08e34401b3f601da91f5a3 ]
    
    If tg3_reset_task() fails, the device state is left in an inconsistent
    state with IFF_RUNNING still set but NAPI state not enabled.  A
    subsequent operation, such as ifdown or AER error can cause it to
    soft lock up when it tries to disable NAPI state.
    
    Fix it by bringing down the device to !IFF_RUNNING state when
    tg3_reset_task() fails.  tg3_reset_task() running from workqueue
    will now call tg3_close() when the reset fails.  We need to
    modify tg3_reset_task_cancel() slightly to avoid tg3_close()
    calling cancel_work_sync() to cancel tg3_reset_task().  Otherwise
    cancel_work_sync() will wait forever for tg3_reset_task() to
    finish.
    
    Reported-by: David Christensen <drc@linux.vnet.ibm.com>
    Reported-by: Baptiste Covolato <baptiste@arista.com>
    Fixes: db2199737990 ("tg3: Schedule at most one tg3_reset_task run")
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit faec94592f7364be5f1e512f6330d3b86136166b
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Fri Sep 4 00:25:10 2020 +0900

    perf jevents: Fix suspicious code in fixregex()
    
    [ Upstream commit e62458e3940eb3dfb009481850e140fbee183b04 ]
    
    The new string should have enough space for the original string and the
    back slashes IMHO.
    
    Fixes: fbc2844e84038ce3 ("perf vendor events: Use more flexible pattern matching for CPU identification for mapfile.csv")
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Reviewed-by: Ian Rogers <irogers@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: John Garry <john.garry@huawei.com>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: William Cohen <wcohen@redhat.com>
    Link: http://lore.kernel.org/lkml/20200903152510.489233-1-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab2413892e2d26015eae2f279f30935846ca24aa
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Wed Sep 2 10:47:02 2020 -0700

    xfs: fix xfs_bmap_validate_extent_raw when checking attr fork of rt files
    
    [ Upstream commit d0c20d38af135b2b4b90aa59df7878ef0c8fbef4 ]
    
    The realtime flag only applies to the data fork, so don't use the
    realtime block number checks on the attr fork of a realtime file.
    
    Fixes: 30b0984d9117 ("xfs: refactor bmap record validation")
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a7241fe4d340bce8c13854976f0eabf2a72d4eb
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Sep 2 14:56:31 2020 +0300

    net: gemini: Fix another missing clk_disable_unprepare() in probe
    
    [ Upstream commit eb0f3bc463d59d86402f19c59aa44e82dc3fab6d ]
    
    We recently added some calls to clk_disable_unprepare() but we missed
    the last error path if register_netdev() fails.
    
    I made a couple cleanups so we avoid mistakes like this in the future.
    First I reversed the "if (!ret)" condition and pulled the code in one
    indent level.  Also, the "port->netdev = NULL;" is not required because
    "port" isn't used again outside this function so I deleted that line.
    
    Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37d933e8b41b83bb8278815e366aec5a542b7e31
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Sep 2 11:30:48 2020 -0400

    fix regression in "epoll: Keep a reference on files added to the check list"
    
    [ Upstream commit 77f4689de17c0887775bb77896f4cc11a39bf848 ]
    
    epoll_loop_check_proc() can run into a file already committed to destruction;
    we can't grab a reference on those and don't need to add them to the set for
    reverse path check anyway.
    
    Tested-by: Marc Zyngier <maz@kernel.org>
    Fixes: a9ed4a6560b8 ("epoll: Keep a reference on files added to the check list")
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f00d82c3fb4368afb41cba89b287801a7888627c
Author: Shung-Hsi Yu <shung-hsi.yu@suse.com>
Date:   Mon Aug 31 22:37:09 2020 +0800

    net: ethernet: mlx4: Fix memory allocation in mlx4_buddy_init()
    
    [ Upstream commit cbedcb044e9cc4e14bbe6658111224bb923094f4 ]
    
    On machines with much memory (> 2 TByte) and log_mtts_per_seg == 0, a
    max_order of 31 will be passed to mlx_buddy_init(), which results in
    s = BITS_TO_LONGS(1 << 31) becoming a negative value, leading to
    kvmalloc_array() failure when it is converted to size_t.
    
      mlx4_core 0000:b1:00.0: Failed to initialize memory region table, aborting
      mlx4_core: probe of 0000:b1:00.0 failed with error -12
    
    Fix this issue by changing the left shifting operand from a signed literal to
    an unsigned one.
    
    Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
    Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5154e806105266406156b3fa67d05df7a398aa6c
Author: Al Grant <al.grant@foss.arm.com>
Date:   Tue Sep 1 12:10:14 2020 -0300

    perf tools: Correct SNOOPX field offset
    
    [ Upstream commit 39c0a53b114d0317e5c4e76b631f41d133af5cb0 ]
    
    perf_event.h has macros that define the field offsets in the data_src
    bitmask in perf records. The SNOOPX and REMOTE offsets were both 37.
    
    These are distinct fields, and the bitfield layout in perf_mem_data_src
    confirms that SNOOPX should be at offset 38.
    
    Committer notes:
    
    This was extracted from a larger patch that also contained kernel
    changes.
    
    Fixes: 52839e653b5629bd ("perf tools: Add support for printing new mem_info encodings")
    Signed-off-by: Al Grant <al.grant@arm.com>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/9974f2d0-bf7f-518e-d9f7-4520e5ff1bb0@foss.arm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dff6a2c2828bce13f32c62029def97195f8830f6
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Aug 21 09:58:19 2020 +0200

    nvmet-fc: Fix a missed _irqsave version of spin_lock in 'nvmet_fc_fod_op_done()'
    
    [ Upstream commit 70e37988db94aba607d5491a94f80ba08e399b6b ]
    
    The way 'spin_lock()' and 'spin_lock_irqsave()' are used is not consistent
    in this function.
    
    Use 'spin_lock_irqsave()' also here, as there is no guarantee that
    interruptions are disabled at that point, according to surrounding code.
    
    Fixes: a97ec51b37ef ("nvmet_fc: Rework target side abort handling")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ad2f018636c6741c41867f14d49d9441b50930d
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sun Aug 23 13:55:36 2020 +0200

    netfilter: nfnetlink: nfnetlink_unicast() reports EAGAIN instead of ENOBUFS
    
    [ Upstream commit ee921183557af39c1a0475f982d43b0fcac25e2e ]
    
    Frontend callback reports EAGAIN to nfnetlink to retry a command, this
    is used to signal that module autoloading is required. Unfortunately,
    nlmsg_unicast() reports EAGAIN in case the receiver socket buffer gets
    full, so it enters a busy-loop.
    
    This patch updates nfnetlink_unicast() to turn EAGAIN into ENOBUFS and
    to use nlmsg_unicast(). Remove the flags field in nfnetlink_unicast()
    since this is always MSG_DONTWAIT in the existing code which is exactly
    what nlmsg_unicast() passes to netlink_unicast() as parameter.
    
    Fixes: 96518518cc41 ("netfilter: add nftables")
    Reported-by: Phil Sutter <phil@nwl.cc>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0430561c8e0f4b497b29a169445e2477c607e27b
Author: Jesper Dangaard Brouer <brouer@redhat.com>
Date:   Wed Aug 26 10:17:36 2020 +0200

    selftests/bpf: Fix massive output from test_maps
    
    [ Upstream commit fa4505675e093e895b7ec49a76d44f6b5ad9602e ]
    
    When stdout output from the selftests tool 'test_maps' gets redirected
    into e.g file or pipe, then the output lines increase a lot (from 21
    to 33949 lines).  This is caused by the printf that happens before the
    fork() call, and there are user-space buffered printf data that seems
    to be duplicated into the forked process.
    
    To fix this fflush() stdout before the fork loop in __run_parallel().
    
    Fixes: 1a97cf1fe503 ("selftests/bpf: speedup test_maps")
    Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/159842985651.1050885.2154399297503372406.stgit@firesoul
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 05163210d6abcee771d3526fa78bf6b00b2c2041
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Wed Aug 26 12:40:07 2020 -0700

    bnxt: don't enable NAPI until rings are ready
    
    [ Upstream commit 96ecdcc992eb7f468b2cf829b0f5408a1fad4668 ]
    
    Netpoll can try to poll napi as soon as napi_enable() is called.
    It crashes trying to access a doorbell which is still NULL:
    
     BUG: kernel NULL pointer dereference, address: 0000000000000000
     CPU: 59 PID: 6039 Comm: ethtool Kdump: loaded Tainted: G S                5.9.0-rc1-00469-g5fd99b5d9950-dirty #26
     RIP: 0010:bnxt_poll+0x121/0x1c0
     Code: c4 20 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 41 8b 86 a0 01 00 00 41 23 85 18 01 00 00 49 8b 96 a8 01 00 00 0d 00 00 00 24 <89> 02
    41 f6 45 77 02 74 cb 49 8b ae d8 01 00 00 31 c0 c7 44 24 1a
      netpoll_poll_dev+0xbd/0x1a0
      __netpoll_send_skb+0x1b2/0x210
      netpoll_send_udp+0x2c9/0x406
      write_ext_msg+0x1d7/0x1f0
      console_unlock+0x23c/0x520
      vprintk_emit+0xe0/0x1d0
      printk+0x58/0x6f
      x86_vector_activate.cold+0xf/0x46
      __irq_domain_activate_irq+0x50/0x80
      __irq_domain_activate_irq+0x32/0x80
      __irq_domain_activate_irq+0x32/0x80
      irq_domain_activate_irq+0x25/0x40
      __setup_irq+0x2d2/0x700
      request_threaded_irq+0xfb/0x160
      __bnxt_open_nic+0x3b1/0x750
      bnxt_open_nic+0x19/0x30
      ethtool_set_channels+0x1ac/0x220
      dev_ethtool+0x11ba/0x2240
      dev_ioctl+0x1cf/0x390
      sock_do_ioctl+0x95/0x130
    
    Reported-by: Rob Sherwood <rsher@fb.com>
    Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 017265f1421529a473c25dc46a0cee98facbb1a3
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Wed Aug 26 14:11:58 2020 -0700

    xfs: fix boundary test in xfs_attr_shortform_verify
    
    [ Upstream commit f4020438fab05364018c91f7e02ebdd192085933 ]
    
    The boundary test for the fixed-offset parts of xfs_attr_sf_entry in
    xfs_attr_shortform_verify is off by one, because the variable array
    at the end is defined as nameval[1] not nameval[].
    Hence we need to subtract 1 from the calculation.
    
    This can be shown by:
    
    # touch file
    # setfattr -n root.a file
    
    and verifications will fail when it's written to disk.
    
    This only matters for a last attribute which has a single-byte name
    and no value, otherwise the combination of namelen & valuelen will
    push endp further out and this test won't fail.
    
    Fixes: 1e1bbd8e7ee06 ("xfs: create structure verifier function for shortform xattrs")
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd7b07382fff9ff6d090adfa0236d28b6b21402c
Author: Edwin Peer <edwin.peer@broadcom.com>
Date:   Wed Aug 26 01:08:37 2020 -0400

    bnxt_en: fix HWRM error when querying VF temperature
    
    [ Upstream commit 12cce90b934bf2b0ed9c339b4d5503e69954351a ]
    
    Firmware returns RESOURCE_ACCESS_DENIED for HWRM_TEMP_MONITORY_QUERY for
    VFs. This produces unpleasing error messages in the log when temp1_input
    is queried via the hwmon sysfs interface from a VF.
    
    The error is harmless and expected, so silence it and return unknown as
    the value. Since the device temperature is not particularly sensitive
    information, provide flexibility to change this policy in future by
    silencing the error rather than avoiding the HWRM call entirely for VFs.
    
    Fixes: cde49a42a9bb ("bnxt_en: Add hwmon sysfs support to read temperature")
    Cc: Marc Smith <msmith626@gmail.com>
    Reported-by: Marc Smith <msmith626@gmail.com>
    Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9895dfea9610ae54be8890b98eb17fd7f1496c75
Author: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Date:   Wed Aug 26 01:08:35 2020 -0400

    bnxt_en: Fix PCI AER error recovery flow
    
    [ Upstream commit df3875ec550396974b1d8a518bd120d034738236 ]
    
    When a PCI error is detected the PCI state could be corrupt, save
    the PCI state after initialization and restore it after the slot
    reset.
    
    Fixes: 6316ea6db93d ("bnxt_en: Enable AER support.")
    Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8674defc50ba2026203a99d2ce11d01ebffb03bc
Author: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Date:   Wed Aug 26 01:08:33 2020 -0400

    bnxt_en: Check for zero dir entries in NVRAM.
    
    [ Upstream commit dbbfa96ad920c50d58bcaefa57f5f33ceef9d00e ]
    
    If firmware goes into unstable state, HWRM_NVM_GET_DIR_INFO firmware
    command may return zero dir entries. Return error in such case to
    avoid zero length dma buffer request.
    
    Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
    Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 296802fe11fe2060fae691006172b2f7d937f184
Author: Pavan Chebbi <pavan.chebbi@broadcom.com>
Date:   Wed Aug 26 01:08:32 2020 -0400

    bnxt_en: Don't query FW when netif_running() is false.
    
    [ Upstream commit c1c2d77408022a398a1a7c51cf20488c922629de ]
    
    In rare conditions like two stage OS installation, the
    ethtool's get_channels function may be called when the
    device is in D3 state, leading to uncorrectable PCI error.
    Check netif_running() first before making any query to FW
    which involves writing to BAR.
    
    Fixes: db4723b3cd2d ("bnxt_en: Check max_tx_scheduler_inputs value from firmware.")
    Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da559d2ed21cb3c17d9b137773b2d29edd5fb385
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Tue Aug 25 14:59:40 2020 +0200

    gtp: add GTPA_LINK info to msg sent to userspace
    
    [ Upstream commit b274e47d9e3f4dcd4ad4028a316ec22dc4533ac7 ]
    
    During a dump, this attribute is essential, it enables the userspace to
    know on which interface the context is linked to.
    
    Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Tested-by: Gabriel Ganne <gabriel.ganne@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b36678b8da827585c457f22b41e6c93a1f502710
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Tue Aug 25 08:46:17 2020 +0200

    dmaengine: pl330: Fix burst length if burst size is smaller than bus width
    
    [ Upstream commit 0661cef675d37e2c4b66a996389ebeae8568e49e ]
    
    Move the burst len fixup after setting the generic value for it. This
    finally enables the fixup introduced by commit 137bd11090d8 ("dmaengine:
    pl330: Align DMA memcpy operations to MFIFO width"), which otherwise was
    overwritten by the generic value.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: 137bd11090d8 ("dmaengine: pl330: Align DMA memcpy operations to MFIFO width")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/20200825064617.16193-1-m.szyprowski@samsung.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9986cb065b9092fe99098acf410f14247f188b6e
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Sun Aug 23 16:56:47 2020 +0800

    net: arc_emac: Fix memleak in arc_mdio_probe
    
    [ Upstream commit e2d79cd8875fa8c3cc7defa98a8cc99a1ed0c62f ]
    
    When devm_gpiod_get_optional() fails, bus should be
    freed just like when of_mdiobus_register() fails.
    
    Fixes: 1bddd96cba03d ("net: arc_emac: support the phy reset for emac driver")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb3a780e7a76cf8efb055f8322ec039923cee41f
Author: Yuusuke Ashizuka <ashiduka@fujitsu.com>
Date:   Thu Aug 20 18:43:07 2020 +0900

    ravb: Fixed to be able to unload modules
    
    [ Upstream commit 1838d6c62f57836639bd3d83e7855e0ee4f6defc ]
    
    When this driver is built as a module, I cannot rmmod it after insmoding
    it.
    This is because that this driver calls ravb_mdio_init() at the time of
    probe, and module->refcnt is incremented by alloc_mdio_bitbang() called
    after that.
    Therefore, even if ifup is not performed, the driver is in use and rmmod
    cannot be performed.
    
    $ lsmod
    Module                  Size  Used by
    ravb                   40960  1
    $ rmmod ravb
    rmmod: ERROR: Module ravb is in use
    
    Call ravb_mdio_init() at open and free_mdio_bitbang() at close, thereby
    rmmod is possible in the ifdown state.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Yuusuke Ashizuka <ashiduka@fujitsu.com>
    Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7d1a655c7b4f0fde2c64ee43e293d2df676fdbe
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Mon Aug 24 13:58:31 2020 +0800

    net: systemport: Fix memleak in bcm_sysport_probe
    
    [ Upstream commit 7ef1fc57301f3cef7201497aa27e89ccb91737fe ]
    
    When devm_kcalloc() fails, dev should be freed just
    like what we've done in the subsequent error paths.
    
    Fixes: 7b78be48a8eb6 ("net: systemport: Dynamically allocate number of TX rings")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 743f4a03d469695f21a1e5bcd9ec857982ba8c7c
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Mon Aug 24 13:44:42 2020 +0800

    net: hns: Fix memleak in hns_nic_dev_probe
    
    [ Upstream commit 100e3345c6e719d2291e1efd5de311cc24bb9c0b ]
    
    hns_nic_dev_probe allocates ndev, but not free it on
    two error handling paths, which may lead to memleak.
    
    Fixes: 63434888aaf1b ("net: hns: net: hns: enet adds support of acpi")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86c459915577b0c87287b11f4dde44f908885461
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Aug 20 21:05:50 2020 +0200

    netfilter: nf_tables: fix destination register zeroing
    
    [ Upstream commit 1e105e6afa6c3d32bfb52c00ffa393894a525c27 ]
    
    Following bug was reported via irc:
    nft list ruleset
       set knock_candidates_ipv4 {
          type ipv4_addr . inet_service
          size 65535
          elements = { 127.0.0.1 . 123,
                       127.0.0.1 . 123 }
          }
     ..
       udp dport 123 add @knock_candidates_ipv4 { ip saddr . 123 }
       udp dport 123 add @knock_candidates_ipv4 { ip saddr . udp dport }
    
    It should not have been possible to add a duplicate set entry.
    
    After some debugging it turned out that the problem is the immediate
    value (123) in the second-to-last rule.
    
    Concatenations use 32bit registers, i.e. the elements are 8 bytes each,
    not 6 and it turns out the kernel inserted
    
    inet firewall @knock_candidates_ipv4
            element 0100007f ffff7b00  : 0 [end]
            element 0100007f 00007b00  : 0 [end]
    
    Note the non-zero upper bits of the first element.  It turns out that
    nft_immediate doesn't zero the destination register, but this is needed
    when the length isn't a multiple of 4.
    
    Furthermore, the zeroing in nft_payload is broken.  We can't use
    [len / 4] = 0 -- if len is a multiple of 4, index is off by one.
    
    Skip zeroing in this case and use a conditional instead of (len -1) / 4.
    
    Fixes: 49499c3e6e18 ("netfilter: nf_tables: switch registers to 32 bit addressing")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f21d1dd7cafb0230dc141e64ec5da622b3b1c46
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Aug 20 14:12:55 2020 +0200

    netfilter: nf_tables: incorrect enum nft_list_attributes definition
    
    [ Upstream commit da9125df854ea48a6240c66e8a67be06e2c12c03 ]
    
    This should be NFTA_LIST_UNSPEC instead of NFTA_LIST_UNPEC, all other
    similar attribute definitions are postfixed with _UNSPEC.
    
    Fixes: 96518518cc41 ("netfilter: add nftables")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88c161599f17249deed573befc5f85f4cd919e7b
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Aug 20 14:12:54 2020 +0200

    netfilter: nf_tables: add NFTA_SET_USERDATA if not null
    
    [ Upstream commit 6f03bf43ee05b31d3822def2a80f11b3591c55b3 ]
    
    Kernel sends an empty NFTA_SET_USERDATA attribute with no value if
    userspace adds a set with no NFTA_SET_USERDATA attribute.
    
    Fixes: e6d8ecac9e68 ("netfilter: nf_tables: Add new attributes into nft_set to store user data.")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e2dae2272915679d38440726011a37e980b6245
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Wed Aug 19 11:26:45 2020 -0700

    MIPS: BMIPS: Also call bmips_cpu_setup() for secondary cores
    
    [ Upstream commit e14f633b66902615cf7faa5d032b45ab8b6fb158 ]
    
    The initialization done by bmips_cpu_setup() typically affects both
    threads of a given core, on 7435 which supports 2 cores and 2 threads,
    logical CPU number 2 and 3 would not run this initialization.
    
    Fixes: 738a3f79027b ("MIPS: BMIPS: Add early CPU initialization code")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 04b3604008265fb84f8fc7d7646ee652b4546834
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Wed Aug 19 11:26:44 2020 -0700

    MIPS: mm: BMIPS5000 has inclusive physical caches
    
    [ Upstream commit dbfc95f98f0158958d1f1e6bf06d74be38dbd821 ]
    
    When the BMIPS generic cpu-feature-overrides.h file was introduced,
    cpu_has_inclusive_caches/MIPS_CPU_INCLUSIVE_CACHES was not set for
    BMIPS5000 CPUs. Correct this when we have initialized the MIPS secondary
    cache successfully.
    
    Fixes: f337967d6d87 ("MIPS: BMIPS: Add cpu-feature-overrides.h")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd8c3a766bf286a5e9f4a72ec69e611ae2c88ea6
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Mon Aug 17 19:57:26 2020 +0800

    dmaengine: at_hdmac: check return value of of_find_device_by_node() in at_dma_xlate()
    
    [ Upstream commit 0cef8e2c5a07d482ec907249dbd6687e8697677f ]
    
    The reurn value of of_find_device_by_node() is not checked, thus null
    pointer dereference will be triggered if of_find_device_by_node()
    failed.
    
    Fixes: bbe89c8e3d59 ("at_hdmac: move to generic DMA binding")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20200817115728.1706719-2-yukuai3@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3eabc73c4a3ce80559886c9386f132399f0ad8fe
Author: Jussi Kivilinna <jussi.kivilinna@haltian.com>
Date:   Tue Aug 18 17:46:10 2020 +0300

    batman-adv: bla: use netif_rx_ni when not in interrupt context
    
    [ Upstream commit 279e89b2281af3b1a9f04906e157992c19c9f163 ]
    
    batadv_bla_send_claim() gets called from worker thread context through
    batadv_bla_periodic_work(), thus netif_rx_ni needs to be used in that
    case. This fixes "NOHZ: local_softirq_pending 08" log messages seen
    when batman-adv is enabled.
    
    Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code")
    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@haltian.com>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6723a869abe3aa171cc2f6bc1686025447fce95
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Thu Jul 23 14:28:08 2020 +0200

    batman-adv: Fix own OGM check in aggregated OGMs
    
    [ Upstream commit d8bf0c01642275c7dca1e5d02c34e4199c200b1f ]
    
    The own OGM check is currently misplaced and can lead to the following
    issues:
    
    For one thing we might receive an aggregated OGM from a neighbor node
    which has our own OGM in the first place. We would then not only skip
    our own OGM but erroneously also any other, following OGM in the
    aggregate.
    
    For another, we might receive an OGM aggregate which has our own OGM in
    a place other then the first one. Then we would wrongly not skip this
    OGM, leading to populating the orginator and gateway table with ourself.
    
    Fixes: 9323158ef9f4 ("batman-adv: OGMv2 - implement originators logic")
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1046c9a3563e48eb086a8333a5ca6ab692f43638
Author: Sven Eckelmann <sven@narfation.org>
Date:   Wed Jul 22 20:36:43 2020 +0200

    batman-adv: Avoid uninitialized chaddr when handling DHCP
    
    [ Upstream commit 303216e76dcab6049c9d42390b1032f0649a8206 ]
    
    The gateway client code can try to optimize the delivery of DHCP packets to
    avoid broadcasting them through the whole mesh. But also transmissions to
    the client can be optimized by looking up the destination via the chaddr of
    the DHCP packet.
    
    But the chaddr is currently only done when chaddr is fully inside the
    non-paged area of the skbuff. Otherwise it will not be initialized and the
    unoptimized path should have been taken.
    
    But the implementation didn't handle this correctly. It didn't retrieve the
    correct chaddr but still tried to perform the TT lookup with this
    uninitialized memory.
    
    Reported-by: syzbot+ab16e463b903f5a37036@syzkaller.appspotmail.com
    Fixes: 6c413b1c22a2 ("batman-adv: send every DHCP packet as bat-unicast")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Acked-by: Antonio Quartulli <a@unstable.cc>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fcaafd72ad6408bd4d463f18b289c27c16cb331e
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Thu Aug 6 13:49:28 2020 +0300

    dmaengine: of-dma: Fix of_dma_router_xlate's of_dma_xlate handling
    
    [ Upstream commit 5b2aa9f918f6837ae943557f8cec02c34fcf80e7 ]
    
    of_dma_xlate callback can return ERR_PTR as well NULL in case of failure.
    
    If error code is returned (not NULL) then the route should be released and
    the router should not be registered for the channel.
    
    Fixes: 56f13c0d9524c ("dmaengine: of_dma: Support for DMA routers")
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Link: https://lore.kernel.org/r/20200806104928.25975-1-peter.ujfalusi@ti.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47eb291ba65bfade197e73ee13610d97809cb087
Author: Simon Leiner <simon@leiner.me>
Date:   Tue Aug 25 11:31:52 2020 +0200

    xen/xenbus: Fix granting of vmalloc'd memory
    
    [ Upstream commit d742db70033c745e410523e00522ee0cfe2aa416 ]
    
    On some architectures (like ARM), virt_to_gfn cannot be used for
    vmalloc'd memory because of its reliance on virt_to_phys. This patch
    introduces a check for vmalloc'd addresses and obtains the PFN using
    vmalloc_to_pfn in that case.
    
    Signed-off-by: Simon Leiner <simon@leiner.me>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Link: https://lore.kernel.org/r/20200825093153.35500-1-simon@leiner.me
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 228d5227dcdc74d9157a4f36cfa52ac6c1a088f9
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Thu Aug 20 09:48:23 2020 +0200

    s390: don't trace preemption in percpu macros
    
    [ Upstream commit 1196f12a2c960951d02262af25af0bb1775ebcc2 ]
    
    Since commit a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context}
    to per-cpu variables") the lockdep code itself uses percpu variables. This
    leads to recursions because the percpu macros are calling preempt_enable()
    which might call trace_preempt_on().
    
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c12a4e6ac32c6d5978fecc0501b7bb9c8ddd2bae
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Aug 20 16:47:24 2020 +0200

    cpuidle: Fixup IRQ state
    
    [ Upstream commit 49d9c5936314e44d314c605c39cce0fd947f9c3a ]
    
    Match the pattern elsewhere in this file.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Tested-by: Marco Elver <elver@google.com>
    Link: https://lkml.kernel.org/r/20200821085348.251340558@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e69973638f741a0c712bde6090b37d17e608b533
Author: Jeff Layton <jlayton@kernel.org>
Date:   Thu Aug 20 11:00:26 2020 -0400

    ceph: don't allow setlease on cephfs
    
    [ Upstream commit 496ceaf12432b3d136dcdec48424312e71359ea7 ]
    
    Leases don't currently work correctly on kcephfs, as they are not broken
    when caps are revoked. They could eventually be implemented similarly to
    how we did them in libcephfs, but for now don't allow them.
    
    [ idryomov: no need for simple_nosetlease() in ceph_dir_fops and
      ceph_snapdir_fops ]
    
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6cd351b7d0cfe963c30fe63ee8de05084d976b41
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu Aug 20 12:36:22 2020 +0300

    drm/msm/a6xx: fix gmu start on newer firmware
    
    [ Upstream commit f5749d6181fa7df5ae741788e5d96f593d3a60b6 ]
    
    New Qualcomm firmware has changed a way it reports back the 'started'
    event. Support new register values.
    
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 76abdb81893fd282c7844632e20275fffce2ec41
Author: Amit Engel <amit.engel@dell.com>
Date:   Wed Aug 19 11:31:11 2020 +0300

    nvmet: Disable keep-alive timer when kato is cleared to 0h
    
    [ Upstream commit 0d3b6a8d213a30387b5104b2fb25376d18636f23 ]
    
    Based on nvme spec, when keep alive timeout is set to zero
    the keep-alive timer should be disabled.
    
    Signed-off-by: Amit Engel <amit.engel@dell.com>
    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 bb0d61385e21d231322c9f78815c2b4f967b1e84
Author: Tom Rix <trix@redhat.com>
Date:   Thu Aug 20 06:19:32 2020 -0700

    hwmon: (applesmc) check status earlier.
    
    [ Upstream commit cecf7560f00a8419396a2ed0f6e5d245ccb4feac ]
    
    clang static analysis reports this representative problem
    
    applesmc.c:758:10: warning: 1st function call argument is an
      uninitialized value
            left = be16_to_cpu(*(__be16 *)(buffer + 6)) >> 2;
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    buffer is filled by the earlier call
    
            ret = applesmc_read_key(LIGHT_SENSOR_LEFT_KEY, ...
    
    This problem is reported because a goto skips the status check.
    Other similar problems use data from applesmc_read_key before checking
    the status.  So move the checks to before the use.
    
    Signed-off-by: Tom Rix <trix@redhat.com>
    Reviewed-by: Henrik Rydberg <rydberg@bitmath.org>
    Link: https://lore.kernel.org/r/20200820131932.10590-1-trix@redhat.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8bc5c9ba5a1d67aaf6957199b2ab8a24402741a9
Author: Krishna Manikandan <mkrishn@codeaurora.org>
Date:   Mon Jun 1 16:33:22 2020 +0530

    drm/msm: add shutdown support for display platform_driver
    
    [ Upstream commit 9d5cbf5fe46e350715389d89d0c350d83289a102 ]
    
    Define shutdown callback for display drm driver,
    so as to disable all the CRTCS when shutdown
    notification is received by the driver.
    
    This change will turn off the timing engine so
    that no display transactions are requested
    while mmu translations are getting disabled
    during reboot sequence.
    
    Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org>
    
    Changes in v2:
            - Remove NULL check from msm_pdev_shutdown (Stephen Boyd)
            - Change commit text to reflect when this issue
              was uncovered (Sai Prakash Ranjan)
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee385b41089d948987764f462adc246be028e32e
Author: John Stultz <john.stultz@linaro.org>
Date:   Tue Aug 11 02:50:44 2020 +0000

    tty: serial: qcom_geni_serial: Drop __init from qcom_geni_console_setup
    
    [ Upstream commit 975efc66d4e654207c17f939eb737ac591ac38fe ]
    
    When booting with heavily modularized config, the serial console
    may not be able to load until after init when modules that
    satisfy needed dependencies have time to load.
    
    Unfortunately, as qcom_geni_console_setup is marked as __init,
    the function may have been freed before we get to run it,
    causing boot time crashes such as:
    
    [    6.469057] Unable to handle kernel paging request at virtual address ffffffe645d4e6cc
    [    6.481623] Mem abort info:
    [    6.484466]   ESR = 0x86000007
    [    6.487557]   EC = 0x21: IABT (current EL), IL = 32 bits
    [    6.492929]   SET = 0, FnV = 0g
    [    6.496016]   EA = 0, S1PTW = 0
    [    6.499202] swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008151e000
    [    6.501286] ufshcd-qcom 1d84000.ufshc: ufshcd_print_pwr_info:[RX, TX]: gear=[3, 3], lane[2, 2], pwr[FAST MODE, FAST MODE], rate = 2
    [    6.505977] [ffffffe645d4e6cc] pgd=000000017df9f003, p4d=000000017df9f003, pud=000000017df9f003, pmd=000000017df9c003, pte=0000000000000000
    [    6.505990] Internal error: Oops: 86000007 [#1] PREEMPT SMP
    [    6.505995] Modules linked in: zl10353 zl10039 zl10036 zd1301_demod xc5000 xc4000 ves1x93 ves1820 tuner_xc2028 tuner_simple tuner_types tua9001 tua6100 1
    [    6.506152]  isl6405
    [    6.518104] ufshcd-qcom 1d84000.ufshc: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0
    [    6.530549]  horus3a helene fc2580 fc0013 fc0012 fc0011 ec100 e4000 dvb_pll ds3000 drxk drxd drx39xyj dib9000 dib8000 dib7000p dib7000m dib3000mc dibx003
    [    6.624271] CPU: 7 PID: 148 Comm: kworker/7:2 Tainted: G        W       5.8.0-mainline-12021-g6defd37ba1cd #3455
    [    6.624273] Hardware name: Thundercomm Dragonboard 845c (DT)
    [    6.624290] Workqueue: events deferred_probe_work_func
    [    6.624296] pstate: 40c00005 (nZcv daif +PAN +UAO BTYPE=--)
    [    6.624307] pc : qcom_geni_console_setup+0x0/0x110
    [    6.624316] lr : try_enable_new_console+0xa0/0x140
    [    6.624318] sp : ffffffc010843a30
    [    6.624320] x29: ffffffc010843a30 x28: ffffffe645c3e7d0
    [    6.624325] x27: ffffff80f8022180 x26: ffffffc010843b28
    [    6.637937] x25: 0000000000000000 x24: ffffffe6462a2000
    [    6.637941] x23: ffffffe646398000 x22: 0000000000000000
    [    6.637945] x21: 0000000000000000 x20: ffffffe6462a5ce8
    [    6.637952] x19: ffffffe646398e38 x18: ffffffffffffffff
    [    6.680296] x17: 0000000000000000 x16: ffffffe64492b900
    [    6.680300] x15: ffffffe6461e9d08 x14: 69202930203d2064
    [    6.680305] x13: 7561625f65736162 x12: 202c363331203d20
    [    6.696434] x11: 0000000000000030 x10: 0101010101010101
    [    6.696438] x9 : 4d4d20746120304d x8 : 7f7f7f7f7f7f7f7f
    [    6.707249] x7 : feff4c524c787373 x6 : 0000000000008080
    [    6.707253] x5 : 0000000000000000 x4 : 8080000000000000
    [    6.707257] x3 : 0000000000000000 x2 : ffffffe645d4e6cc
    [    6.744223] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 102400000 (-34)
    [    6.744966] x1 : fffffffefe74e174 x0 : ffffffe6462a5ce8
    [    6.753580] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 102400000 (-34)
    [    6.761634] Call trace:
    [    6.761639]  qcom_geni_console_setup+0x0/0x110
    [    6.761645]  register_console+0x29c/0x2f8
    [    6.767981] Bluetooth: hci0: Frame reassembly failed (-84)
    [    6.775252]  uart_add_one_port+0x438/0x500
    [    6.775258]  qcom_geni_serial_probe+0x2c4/0x4a8
    [    6.775266]  platform_drv_probe+0x58/0xa8
    [    6.855359]  really_probe+0xec/0x398
    [    6.855362]  driver_probe_device+0x5c/0xb8
    [    6.855367]  __device_attach_driver+0x98/0xb8
    [    7.184945]  bus_for_each_drv+0x74/0xd8
    [    7.188825]  __device_attach+0xec/0x148
    [    7.192705]  device_initial_probe+0x24/0x30
    [    7.196937]  bus_probe_device+0x9c/0xa8
    [    7.200816]  deferred_probe_work_func+0x7c/0xb8
    [    7.205398]  process_one_work+0x20c/0x4b0
    [    7.209456]  worker_thread+0x48/0x460
    [    7.213157]  kthread+0x14c/0x158
    [    7.216432]  ret_from_fork+0x10/0x18
    [    7.220049] Code: bad PC value
    [    7.223139] ---[ end trace 73f3b21e251d5a70 ]---
    
    Thus this patch removes the __init avoiding crash in such
    configs.
    
    Cc: Andy Gross <agross@kernel.org>
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Cc: Saravana Kannan <saravanak@google.com>
    Cc: Todd Kjos <tkjos@google.com>
    Cc: Amit Pundir <amit.pundir@linaro.org>
    Cc: linux-arm-msm@vger.kernel.org
    Cc: linux-serial@vger.kernel.org
    Suggested-by: Saravana Kannan <saravanak@google.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20200811025044.70626-1-john.stultz@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6309b813b79ce1dbb902465cb502f4ed9cb6aa9
Author: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Date:   Thu Jun 18 15:16:31 2020 +0200

    scsi: target: tcmu: Optimize use of flush_dcache_page
    
    commit 3c58f737231e2c8cbf543a09d84d8c8e80e05e43 upstream.
    
    (scatter|gather)_data_area() need to flush dcache after writing data to or
    before reading data from a page in uio data area.  The two routines are
    able to handle data transfer to/from such a page in fragments and flush the
    cache after each fragment was copied by calling the wrapper
    tcmu_flush_dcache_range().
    
    That means:
    
    1) flush_dcache_page() can be called multiple times for the same page.
    
    2) Calling flush_dcache_page() indirectly using the wrapper does not make
       sense, because each call of the wrapper is for one single page only and
       the calling routine already has the correct page pointer.
    
    Change (scatter|gather)_data_area() such that, instead of calling
    tcmu_flush_dcache_range() before/after each memcpy, it now calls
    flush_dcache_page() before unmapping a page (when writing is complete for
    that page) or after mapping a page (when starting to read the page).
    
    After this change only calls to tcmu_flush_dcache_range() for addresses in
    vmalloc'ed command ring are left over.
    
    The patch was tested on ARM with kernel 4.19.118 and 5.7.2
    
    Link: https://lore.kernel.org/r/20200618131632.32748-2-bstroesser@ts.fujitsu.com
    Tested-by: JiangYu <lnsyyj@hotmail.com>
    Tested-by: Daniel Meyerholt <dxm523@gmail.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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04414e46923f83b1c870d126eca18c000ff04ba7
Author: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Date:   Thu May 28 21:31:08 2020 +0200

    scsi: target: tcmu: Fix size in calls to tcmu_flush_dcache_range
    
    commit 8c4e0f212398cdd1eb4310a5981d06a723cdd24f upstream.
    
    1) If remaining ring space before the end of the ring is smaller then the
       next cmd to write, tcmu writes a padding entry which fills the remaining
       space at the end of the ring.
    
       Then tcmu calls tcmu_flush_dcache_range() with the size of struct
       tcmu_cmd_entry as data length to flush.  If the space filled by the
       padding was smaller then tcmu_cmd_entry, tcmu_flush_dcache_range() is
       called for an address range reaching behind the end of the vmalloc'ed
       ring.
    
       tcmu_flush_dcache_range() in a loop calls
       flush_dcache_page(virt_to_page(start)); for every page being part of the
       range. On x86 the line is optimized out by the compiler, as
       flush_dcache_page() is empty on x86.
    
       But I assume the above can cause trouble on other architectures that
       really have a flush_dcache_page().  For paddings only the header part of
       an entry is relevant due to alignment rules the header always fits in
       the remaining space, if padding is needed.  So tcmu_flush_dcache_range()
       can safely be called with sizeof(entry->hdr) as the length here.
    
    2) After it has written a command to cmd ring, tcmu calls
       tcmu_flush_dcache_range() using the size of a struct tcmu_cmd_entry as
       data length to flush.  But if a command needs many iovecs, the real size
       of the command may be bigger then tcmu_cmd_entry, so a part of the
       written command is not flushed then.
    
    Link: https://lore.kernel.org/r/20200528193108.9085-1-bstroesser@ts.fujitsu.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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92d0750a38b09b5aa65c8b240aaa08f6935b19e9
Author: Kim Phillips <kim.phillips@amd.com>
Date:   Tue Sep 1 16:58:53 2020 -0500

    perf record/stat: Explicitly call out event modifiers in the documentation
    
    commit e48a73a312ebf19cc3d72aa74985db25c30757c1 upstream.
    
    Event modifiers are not mentioned in the perf record or perf stat
    manpages.  Add them to orient new users more effectively by pointing
    them to the perf list manpage for details.
    
    Fixes: 2055fdaf8703 ("perf list: Document precise event sampling for AMD IBS")
    Signed-off-by: Kim Phillips <kim.phillips@amd.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jin Yao <yao.jin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Paul Clarke <pc@us.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Tony Jones <tonyj@suse.de>
    Cc: stable@vger.kernel.org
    Link: http://lore.kernel.org/lkml/20200901215853.276234-1-kim.phillips@amd.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a47b8511d90528c77346597e2012100dfc28cd8c
Author: Marc Zyngier <maz@kernel.org>
Date:   Tue Sep 1 10:52:33 2020 +0100

    HID: core: Sanitize event code and type when mapping input
    
    commit 35556bed836f8dc07ac55f69c8d17dce3e7f0e25 upstream.
    
    When calling into hid_map_usage(), the passed event code is
    blindly stored as is, even if it doesn't fit in the associated bitmap.
    
    This event code can come from a variety of sources, including devices
    masquerading as input devices, only a bit more "programmable".
    
    Instead of taking the event code at face value, check that it actually
    fits the corresponding bitmap, and if it doesn't:
    - spit out a warning so that we know which device is acting up
    - NULLify the bitmap pointer so that we catch unexpected uses
    
    Code paths that can make use of untrusted inputs can now check
    that the mapping was indeed correct and bail out if not.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abae259fdccc5e41ff302dd80a2b944ce385c970
Author: Marc Zyngier <maz@kernel.org>
Date:   Sat Aug 29 12:26:01 2020 +0100

    HID: core: Correctly handle ReportSize being zero
    
    commit bce1305c0ece3dc549663605e567655dd701752c upstream.
    
    It appears that a ReportSize value of zero is legal, even if a bit
    non-sensical. Most of the HID code seems to handle that gracefully,
    except when computing the total size in bytes. When fed as input to
    memset, this leads to some funky outcomes.
    
    Detect the corner case and correctly compute the size.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>