commit a0f68fb55ebc85e5ed3c6582ffc70379340c4a72
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Sep 12 08:56:42 2021 +0200

    Linux 5.4.145
    
    Link: https://lore.kernel.org/r/20210910122917.149278545@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d83f0b39e72e78d6ecde4ed2da7822673e625799
Author: Marek Behún <kabel@kernel.org>
Date:   Thu Jun 24 19:14:17 2021 +0200

    PCI: Call Max Payload Size-related fixup quirks early
    
    commit b8da302e2955fe4d41eb9d48199242674d77dbe0 upstream.
    
    pci_device_add() calls HEADER fixups after pci_configure_device(), which
    configures Max Payload Size.
    
    Convert MPS-related fixups to EARLY fixups so pci_configure_mps() takes
    them into account.
    
    Fixes: 27d868b5e6cfa ("PCI: Set MPS to match upstream bridge")
    Link: https://lore.kernel.org/r/20210624171418.27194-1-kabel@kernel.org
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c8277e334da85f5dcd52cea1adafd8f8c31b13e
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Sun May 30 12:24:47 2021 -0400

    x86/reboot: Limit Dell Optiplex 990 quirk to early BIOS versions
    
    commit a729691b541f6e63043beae72e635635abe5dc09 upstream.
    
    When this platform was relatively new in November 2011, with early BIOS
    revisions, a reboot quirk was added in commit 6be30bb7d750 ("x86/reboot:
    Blacklist Dell OptiPlex 990 known to require PCI reboot")
    
    However, this quirk (and several others) are open-ended to all BIOS
    versions and left no automatic expiry if/when the system BIOS fixed the
    issue, meaning that nobody is likely to come along and re-test.
    
    What is really problematic with using PCI reboot as this quirk does, is
    that it causes this platform to do a full power down, wait one second,
    and then power back on.  This is less than ideal if one is using it for
    boot testing and/or bisecting kernels when legacy rotating hard disks
    are installed.
    
    It was only by chance that the quirk was noticed in dmesg - and when
    disabled it turned out that it wasn't required anymore (BIOS A24), and a
    default reboot would work fine without the "harshness" of power cycling the
    machine (and disks) down and up like the PCI reboot does.
    
    Doing a bit more research, it seems that the "newest" BIOS for which the
    issue was reported[1] was version A06, however Dell[2] seemed to suggest
    only up to and including version A05, with the A06 having a large number of
    fixes[3] listed.
    
    As is typical with a new platform, the initial BIOS updates come frequently
    and then taper off (and in this case, with a revival for CPU CVEs); a
    search for O990-A<ver>.exe reveals the following dates:
    
            A02     16 Mar 2011
            A03     11 May 2011
            A06     14 Sep 2011
            A07     24 Oct 2011
            A10     08 Dec 2011
            A14     06 Sep 2012
            A16     15 Oct 2012
            A18     30 Sep 2013
            A19     23 Sep 2015
            A20     02 Jun 2017
            A23     07 Mar 2018
            A24     21 Aug 2018
    
    While it's overkill to flash and test each of the above, it would seem
    likely that the issue was contained within A0x BIOS versions, given the
    dates above and the dates of issue reports[4] from distros.  So rather than
    just throw out the quirk entirely, limit the scope to just those early BIOS
    versions, in case people are still running systems from 2011 with the
    original as-shipped early A0x BIOS versions.
    
    [1] https://lore.kernel.org/lkml/1320373471-3942-1-git-send-email-trenn@suse.de/
    [2] https://www.dell.com/support/kbdoc/en-ca/000131908/linux-based-operating-systems-stall-upon-reboot-on-optiplex-390-790-990-systems
    [3] https://www.dell.com/support/home/en-ca/drivers/driversdetails?driverid=85j10
    [4] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/768039
    
    Fixes: 6be30bb7d750 ("x86/reboot: Blacklist Dell OptiPlex 990 known to require PCI reboot")
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210530162447.996461-4-paul.gortmaker@windriver.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d31a4c35b92575eaa4aa0c222fac704844d66e06
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Aug 20 15:34:58 2021 +0300

    xhci: fix unsafe memory usage in xhci tracing
    
    commit cbf286e8ef8337308c259ff5b9ce2e74d403be5a upstream.
    
    Removes static char buffer usage in the following decode functions:
            xhci_decode_trb()
            xhci_decode_ptortsc()
    
    Caller must provide a buffer to use.
    In tracing use __get_str() as recommended to pass buffer.
    
    Minor chanes are needed in xhci debugfs code as these functions are also
    used there. Changes include moving XHCI_MSG_MAX definititon from
    xhci-trace.h to xhci.h
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210820123503.2605901-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e00d39ca92bbcfd10da652580af33a4873a75567
Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date:   Fri Aug 13 14:30:49 2021 +0800

    usb: mtu3: fix the wrong HS mult value
    
    commit 44e4439d8f9f8d0e9da767d1f31e7c211081feca upstream.
    
    usb_endpoint_maxp() returns actual max packet size, @mult will
    always be zero, fix it by using usb_endpoint_maxp_mult() instead
    to get mult.
    
    Fixes: 4d79e042ed8b ("usb: mtu3: add support for usb3.1 IP")
    Cc: stable@vger.kernel.org
    Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Link: https://lore.kernel.org/r/1628836253-7432-3-git-send-email-chunfeng.yun@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3ffd35014708a94acddd97b27847e76c2a250f3
Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date:   Fri Aug 13 14:30:48 2021 +0800

    usb: mtu3: use @mult for HS isoc or intr
    
    commit fd7cb394ec7efccc3985feb0978cee4d352e1817 upstream.
    
    For HS isoc or intr, should use @mult but not @burst
    to save mult value.
    
    Fixes: 4d79e042ed8b ("usb: mtu3: add support for usb3.1 IP")
    Cc: stable@vger.kernel.org
    Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Link: https://lore.kernel.org/r/1628836253-7432-2-git-send-email-chunfeng.yun@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00b6325590a4b838730deaaf71fa654548c3d466
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Fri Aug 27 15:32:27 2021 +0900

    usb: host: xhci-rcar: Don't reload firmware after the completion
    
    commit 57f3ffdc11143f56f1314972fe86fe17a0dcde85 upstream.
    
    According to the datasheet, "Upon the completion of FW Download,
    there is no need to write or reload FW.". Otherwise, it's possible
    to cause unexpected behaviors. So, adds such a condition.
    
    Fixes: 4ac8918f3a73 ("usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers")
    Cc: stable@vger.kernel.org # v3.17+
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Link: https://lore.kernel.org/r/20210827063227.81990-1-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a74ae301c2c4c7cc7d4bf41d6ab7a653f10b80a
Author: Alexander Tsoy <alexander@tsoy.me>
Date:   Tue Aug 31 03:25:31 2021 +0300

    ALSA: usb-audio: Add registration quirk for JBL Quantum 800
    
    commit c8b177b6e3a005bd8fb0395a4bc5db3470301c28 upstream.
    
    Add another device ID for JBL Quantum 800. It requires the same quirk as
    other JBL Quantum devices.
    
    Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210831002531.116957-1-alexander@tsoy.me
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1ea74f642097d11095180bbb17cc952d7196b39
Author: Qu Wenruo <wqu@suse.com>
Date:   Wed Aug 25 13:41:42 2021 +0800

    Revert "btrfs: compression: don't try to compress if we don't have enough pages"
    
    commit 4e9655763b82a91e4c341835bb504a2b1590f984 upstream.
    
    This reverts commit f2165627319ffd33a6217275e5690b1ab5c45763.
    
    [BUG]
    It's no longer possible to create compressed inline extent after commit
    f2165627319f ("btrfs: compression: don't try to compress if we don't
    have enough pages").
    
    [CAUSE]
    For compression code, there are several possible reasons we have a range
    that needs to be compressed while it's no more than one page.
    
    - Compressed inline write
      The data is always smaller than one sector and the test lacks the
      condition to properly recognize a non-inline extent.
    
    - Compressed subpage write
      For the incoming subpage compressed write support, we require page
      alignment of the delalloc range.
      And for 64K page size, we can compress just one page into smaller
      sectors.
    
    For those reasons, the requirement for the data to be more than one page
    is not correct, and is already causing regression for compressed inline
    data writeback.  The idea of skipping one page to avoid wasting CPU time
    could be revisited in the future.
    
    [FIX]
    Fix it by reverting the offending commit.
    
    Reported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
    Link: https://lore.kernel.org/linux-btrfs/afa2742.c084f5d6.17b6b08dffc@tnonline.net
    Fixes: f2165627319f ("btrfs: compression: don't try to compress if we don't have enough pages")
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f05c74e10463bfe272e3ce293d3dd69708259091
Author: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Date:   Tue May 4 01:52:36 2021 -0500

    x86/events/amd/iommu: Fix invalid Perf result due to IOMMU PMC power-gating
    
    commit e10de314287c2c14b0e6f0e3e961975ce2f4a83d upstream.
    
    On certain AMD platforms, when the IOMMU performance counter source
    (csource) field is zero, power-gating for the counter is enabled, which
    prevents write access and returns zero for read access.
    
    This can cause invalid perf result especially when event multiplexing
    is needed (i.e. more number of events than available counters) since
    the current logic keeps track of the previously read counter value,
    and subsequently re-program the counter to continue counting the event.
    With power-gating enabled, we cannot gurantee successful re-programming
    of the counter.
    
    Workaround this issue by :
    
    1. Modifying the ordering of setting/reading counters and enabing/
       disabling csources to only access the counter when the csource
       is set to non-zero.
    
    2. Since AMD IOMMU PMU does not support interrupt mode, the logic
       can be simplified to always start counting with value zero,
       and accumulate the counter value when stopping without the need
       to keep track and reprogram the counter with the previously read
       counter value.
    
    This has been tested on systems with and without power-gating.
    
    Fixes: 994d6608efe4 ("iommu/amd: Remove performance counter pre-initialization test")
    Suggested-by: Alexander Monakov <amonakov@ispras.ru>
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20210504065236.4415-1-suravee.suthikulpanit@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1ca1665e6742b0710078bf9c7e9f7a75c334a31
Author: Hayes Wang <hayeswang@realtek.com>
Date:   Fri Aug 6 17:15:55 2021 +0800

    Revert "r8169: avoid link-up interrupt issue on RTL8106e if user enables ASPM"
    
    commit 2115d3d482656ea702f7cf308c0ded3500282903 upstream.
    
    This reverts commit 1ee8856de82faec9bc8bd0f2308a7f27e30ba207.
    
    This is used to re-enable ASPM on RTL8106e, if it is possible.
    
    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf1222b877b026128a22f2a315bcd30f60934fbd
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Mon Dec 14 19:11:25 2020 -0800

    mm/page_alloc: speed up the iteration of max_order
    
    commit 7ad69832f37e3cea8557db6df7c793905f1135e8 upstream.
    
    When we free a page whose order is very close to MAX_ORDER and greater
    than pageblock_order, it wastes some CPU cycles to increase max_order to
    MAX_ORDER one by one and check the pageblock migratetype of that page
    repeatedly especially when MAX_ORDER is much larger than pageblock_order.
    
    We also should not be checking migratetype of buddy when "order ==
    MAX_ORDER - 1" as the buddy pfn may be invalid, so adjust the condition.
    With the new check, we don't need the max_order check anymore, so we
    replace it.
    
    Also adjust max_order initialization so that it's lower by one than
    previously, which makes the code hopefully more clear.
    
    Link: https://lkml.kernel.org/r/20201204155109.55451-1-songmuchun@bytedance.com
    Fixes: d9dddbf55667 ("mm/page_alloc: prevent merging between isolated and other pageblocks")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17d409c83e7689f13bacabf6eb4b895be3341eb0
Author: Esben Haabendal <esben@geanix.com>
Date:   Mon Jun 21 10:20:08 2021 +0200

    net: ll_temac: Remove left-over debug message
    
    commit ce03b94ba682a67e8233c9ee3066071656ded58f upstream.
    
    Fixes: f63963411942 ("net: ll_temac: Avoid ndo_start_xmit returning NETDEV_TX_BUSY")
    Signed-off-by: Esben Haabendal <esben@geanix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ccadb9143796621c3ec870a4b465c3c45bb01e36
Author: Fangrui Song <maskray@google.com>
Date:   Wed Mar 25 09:42:57 2020 -0700

    powerpc/boot: Delete unneeded .globl _zimage_start
    
    commit 968339fad422a58312f67718691b717dac45c399 upstream.
    
    .globl sets the symbol binding to STB_GLOBAL while .weak sets the
    binding to STB_WEAK. GNU as let .weak override .globl since
    binutils-gdb 5ca547dc2399a0a5d9f20626d4bf5547c3ccfddd (1996). Clang
    integrated assembler let the last win but it may error in the future.
    
    Since it is a convention that only one binding directive is used, just
    delete .globl.
    
    Fixes: ee9d21b3b358 ("powerpc/boot: Ensure _zimage_start is a weak symbol")
    Signed-off-by: Fangrui Song <maskray@google.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200325164257.170229-1-maskray@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 295501c77c4cf0a89cecf6b0301640935c75c949
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Mon Oct 12 10:50:14 2020 -0400

    ipv4/icmp: l3mdev: Perform icmp error route lookup on source device routing table (v2)
    
    commit e1e84eb58eb494b77c8389fc6308b5042dcce791 upstream.
    
    As per RFC792, ICMP errors should be sent to the source host.
    
    However, in configurations with Virtual Routing and Forwarding tables,
    looking up which routing table to use is currently done by using the
    destination net_device.
    
    commit 9d1a6c4ea43e ("net: icmp_route_lookup should use rt dev to
    determine L3 domain") changes the interface passed to
    l3mdev_master_ifindex() and inet_addr_type_dev_table() from skb_in->dev
    to skb_dst(skb_in)->dev. This effectively uses the destination device
    rather than the source device for choosing which routing table should be
    used to lookup where to send the ICMP error.
    
    Therefore, if the source and destination interfaces are within separate
    VRFs, or one in the global routing table and the other in a VRF, looking
    up the source host in the destination interface's routing table will
    fail if the destination interface's routing table contains no route to
    the source host.
    
    One observable effect of this issue is that traceroute does not work in
    the following cases:
    
    - Route leaking between global routing table and VRF
    - Route leaking between VRFs
    
    Preferably use the source device routing table when sending ICMP error
    messages. If no source device is set, fall-back on the destination
    device routing table. Else, use the main routing table (index 0).
    
    [ It has been pointed out that a similar issue may exist with ICMP
      errors triggered when forwarding between network namespaces. It would
      be worthwhile to investigate, but is outside of the scope of this
      investigation. ]
    
    [ It has also been pointed out that a similar issue exists with
      unreachable / fragmentation needed messages, which can be triggered by
      changing the MTU of eth1 in r1 to 1400 and running:
    
      ip netns exec h1 ping -s 1450 -Mdo -c1 172.16.2.2
    
      Some investigation points to raw_icmp_error() and raw_err() as being
      involved in this last scenario. The focus of this patch is TTL expired
      ICMP messages, which go through icmp_route_lookup.
      Investigation of failure modes related to raw_icmp_error() is beyond
      this investigation's scope. ]
    
    Fixes: 9d1a6c4ea43e ("net: icmp_route_lookup should use rt dev to determine L3 domain")
    Link: https://tools.ietf.org/html/rfc792
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Reviewed-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6dec8e17b8dbe109b702cc35f145204d6c6780dd
Author: Tom Rix <trix@redhat.com>
Date:   Mon Jan 11 14:09:04 2021 -0800

    USB: serial: mos7720: improve OOM-handling in read_mos_reg()
    
    commit 161a582bd1d8681095f158d11bc679a58f1d026b upstream.
    
    clang static analysis reports this problem
    
    mos7720.c:352:2: warning: Undefined or garbage value returned to caller
            return d;
            ^~~~~~~~
    
    In the parport_mos7715_read_data()'s call to read_mos_reg(), 'd' is
    only set after the alloc block.
    
            buf = kmalloc(1, GFP_KERNEL);
            if (!buf)
                    return -ENOMEM;
    
    Although the problem is reported in parport_most7715_read_data(),
    none of the callee's of read_mos_reg() check the return status.
    
    Make sure to clear the return-value buffer also on allocation failures.
    
    Fixes: 0d130367abf5 ("USB: serial: mos7720: fix control-message error handling")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Link: https://lore.kernel.org/r/20210111220904.1035957-1-trix@redhat.com
    [ johan: only clear the buffer on errors, amend commit message ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d84708451d9041dff8a81e3718f821f12d2eb6c5
Author: Liu Jian <liujian56@huawei.com>
Date:   Fri Jul 16 12:06:17 2021 +0800

    igmp: Add ip_mc_list lock in ip_check_mc_rcu
    
    commit 23d2b94043ca8835bd1e67749020e839f396a1c2 upstream.
    
    I got below panic when doing fuzz test:
    
    Kernel panic - not syncing: panic_on_warn set ...
    CPU: 0 PID: 4056 Comm: syz-executor.3 Tainted: G    B             5.14.0-rc1-00195-gcff5c4254439-dirty #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    Call Trace:
    dump_stack_lvl+0x7a/0x9b
    panic+0x2cd/0x5af
    end_report.cold+0x5a/0x5a
    kasan_report+0xec/0x110
    ip_check_mc_rcu+0x556/0x5d0
    __mkroute_output+0x895/0x1740
    ip_route_output_key_hash_rcu+0x2d0/0x1050
    ip_route_output_key_hash+0x182/0x2e0
    ip_route_output_flow+0x28/0x130
    udp_sendmsg+0x165d/0x2280
    udpv6_sendmsg+0x121e/0x24f0
    inet6_sendmsg+0xf7/0x140
    sock_sendmsg+0xe9/0x180
    ____sys_sendmsg+0x2b8/0x7a0
    ___sys_sendmsg+0xf0/0x160
    __sys_sendmmsg+0x17e/0x3c0
    __x64_sys_sendmmsg+0x9e/0x100
    do_syscall_64+0x3b/0x90
    entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x462eb9
    Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8
     48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48>
     3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f3df5af1c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
    RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462eb9
    RDX: 0000000000000312 RSI: 0000000020001700 RDI: 0000000000000007
    RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3df5af26bc
    R13: 00000000004c372d R14: 0000000000700b10 R15: 00000000ffffffff
    
    It is one use-after-free in ip_check_mc_rcu.
    In ip_mc_del_src, the ip_sf_list of pmc has been freed under pmc->lock protection.
    But access to ip_sf_list in ip_check_mc_rcu is not protected by the lock.
    
    Signed-off-by: Liu Jian <liujian56@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd8ad6ed9ae58a5fbf02e087487d4fcc0b4ebc47
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Wed Jul 7 19:54:30 2021 +0200

    media: stkwebcam: fix memory leak in stk_camera_probe
    
    commit 514e97674400462cc09c459a1ddfb9bf39017223 upstream.
    
    My local syzbot instance hit memory leak in usb_set_configuration().
    The problem was in unputted usb interface. In case of errors after
    usb_get_intf() the reference should be putted to correclty free memory
    allocated for this interface.
    
    Fixes: ec16dae5453e ("V4L/DVB (7019): V4L: add support for Syntek DC1125 webcams")
    Cc: stable@vger.kernel.org
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9febc9153fdb3f7637fb578bc75d9b27930efdb8
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Wed Jan 15 16:08:12 2020 -0800

    ARC: wireup clone3 syscall
    
    commit bd71c453db91ecb464405411f2821d040f2a0d44 upstream.
    
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 417b11d3255c58cc2c33a74cf588d42a8cefbf95
Author: Zubin Mithra <zsm@chromium.org>
Date:   Fri Aug 27 08:37:35 2021 -0700

    ALSA: pcm: fix divide error in snd_pcm_lib_ioctl
    
    commit f3eef46f0518a2b32ca1244015820c35a22cfe4a upstream.
    
    Syzkaller reported a divide error in snd_pcm_lib_ioctl. fifo_size
    is of type snd_pcm_uframes_t(unsigned long). If frame_size
    is 0x100000000, the error occurs.
    
    Fixes: a9960e6a293e ("ALSA: pcm: fix fifo_size frame calculation")
    Signed-off-by: Zubin Mithra <zsm@chromium.org>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210827153735.789452-1-zsm@chromium.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf28619cd9c60ee72a65ec4d4452aa9fe703b760
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Aug 20 16:32:14 2021 +0200

    ALSA: hda/realtek: Workaround for conflicting SSID on ASUS ROG Strix G17
    
    commit 13d9c6b998aaa76fd098133277a28a21f2cc2264 upstream.
    
    ASUS ROG Strix G17 has the very same PCI and codec SSID (1043:103f) as
    ASUS TX300, and unfortunately, the existing quirk for TX300 is broken
    on ASUS ROG.  Actually the device works without the quirk, so we'll
    need to clear the quirk before applying for this device.
    Since ASUS ROG has a different codec (ALC294 - while TX300 has
    ALC282), this patch adds a workaround for the device, just clearing
    the codec->fixup_id by checking the codec vendor_id.
    
    It's a bit ugly to add such a workaround there, but it seems to be the
    simplest way.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214101
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210820143214.3654-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8146f149028e4588c9e9e60dbc59fd546f58581
Author: Ben Dooks <ben-linux@fluff.org>
Date:   Mon Nov 4 18:15:15 2019 +0100

    ARM: 8918/2: only build return_address() if needed
    
    commit fb033c95c94ca1ee3d16e04ebdb85d65fb55fff8 upstream.
    
    The system currently warns if the config conditions for
    building return_address in arch/arm/kernel/return_address.c
    are not met, leaving just an EXPORT_SYMBOL_GPL(return_address)
    of a function defined to be 'static linline'.
    This is a result of aeea3592a13b ("ARM: 8158/1: LLVMLinux: use static inline in ARM ftrace.h").
    
    Since we're not going to build anything other than an exported
    symbol for something that is already being defined to be an
    inline-able return of NULL, just avoid building the code to
    remove the following warning:
    
    Fixes: aeea3592a13b ("ARM: 8158/1: LLVMLinux: use static inline in ARM ftrace.h")
    Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebad44b6432e63e7fddd2dbdae6adcaf75e34d02
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Aug 27 18:32:50 2021 +0200

    cryptoloop: add a deprecation warning
    
    [ Upstream commit 222013f9ac30b9cec44301daa8dbd0aae38abffb ]
    
    Support for cryptoloop has been officially marked broken and deprecated
    in favor of dm-crypt (which supports the same broken algorithms if
    needed) in Linux 2.6.4 (released in March 2004), and support for it has
    been entirely removed from losetup in util-linux 2.23 (released in April
    2013).  Add a warning and a deprecation schedule.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20210827163250.255325-1-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d12526ddf5e3dc00a4e951684449fd6ff361daa6
Author: Kim Phillips <kim.phillips@amd.com>
Date:   Tue Aug 17 17:10:43 2021 -0500

    perf/x86/amd/power: Assign pmu.module
    
    [ Upstream commit ccf26483416a339c114409f6e7cd02abdeaf8052 ]
    
    Assign pmu.module so the driver can't be unloaded whilst in use.
    
    Signed-off-by: Kim Phillips <kim.phillips@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20210817221048.88063-4-kim.phillips@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be1f76fceec4fac78f5548d6cb27d4cf3d7bdcef
Author: Kim Phillips <kim.phillips@amd.com>
Date:   Tue Aug 17 17:10:42 2021 -0500

    perf/x86/amd/ibs: Work around erratum #1197
    
    [ Upstream commit 26db2e0c51fe83e1dd852c1321407835b481806e ]
    
    Erratum #1197 "IBS (Instruction Based Sampling) Register State May be
    Incorrect After Restore From CC6" is published in a document:
    
      "Revision Guide for AMD Family 19h Models 00h-0Fh Processors" 56683 Rev. 1.04 July 2021
    
      https://bugzilla.kernel.org/show_bug.cgi?id=206537
    
    Implement the erratum's suggested workaround and ignore IBS samples if
    MSRC001_1031 == 0.
    
    Signed-off-by: Kim Phillips <kim.phillips@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20210817221048.88063-3-kim.phillips@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 861118d64e50b909e4008d3000d79edabc0d04f0
Author: Xiaoyao Li <xiaoyao.li@intel.com>
Date:   Tue Aug 24 12:06:22 2021 +0800

    perf/x86/intel/pt: Fix mask of num_address_ranges
    
    [ Upstream commit c53c6b7409f4cd9e542991b53d597fbe2751d7db ]
    
    Per SDM, bit 2:0 of CPUID(0x14,1).EAX[2:0] reports the number of
    configurable address ranges for filtering, not bit 1:0.
    
    Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Link: https://lkml.kernel.org/r/20210824040622.4081502-1-xiaoyao.li@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40d23de514cda88168d2d4bf6ff460c1f60c836e
Author: Shai Malin <smalin@marvell.com>
Date:   Tue Aug 24 19:52:49 2021 +0300

    qede: Fix memset corruption
    
    [ Upstream commit e543468869e2532f5d7926e8f417782b48eca3dc ]
    
    Thanks to Kees Cook who detected the problem of memset that starting
    from not the first member, but sized for the whole struct.
    The better change will be to remove the redundant memset and to clear
    only the msix_cnt member.
    
    Signed-off-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
    Signed-off-by: Ariel Elior <aelior@marvell.com>
    Signed-off-by: Shai Malin <smalin@marvell.com>
    Reported-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 468623f69683f3c379e16fb513d3b90ce37d6d9a
Author: Harini Katakam <harini.katakam@xilinx.com>
Date:   Tue Aug 24 15:32:09 2021 +0530

    net: macb: Add a NULL check on desc_ptp
    
    [ Upstream commit 85520079afce885b80647fbd0d13d8f03d057167 ]
    
    macb_ptp_desc will not return NULL under most circumstances with correct
    Kconfig and IP design config register. But for the sake of the extreme
    corner case, check for NULL when using the helper. In case of rx_tstamp,
    no action is necessary except to return (similar to timestamp disabled)
    and warn. In case of TX, return -EINVAL to let the skb be free. Perform
    this check before marking skb in progress.
    Fixes coverity warning:
    (4) Event dereference:
    Dereferencing a null pointer "desc_ptp"
    
    Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
    Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50f73f31ae632061d5567a8c79a77a3d7884dc4f
Author: Shai Malin <smalin@marvell.com>
Date:   Sun Aug 22 22:21:14 2021 +0300

    qed: Fix the VF msix vectors flow
    
    [ Upstream commit b0cd08537db8d2fbb227cdb2e5835209db295a24 ]
    
    For VFs we should return with an error in case we didn't get the exact
    number of msix vectors as we requested.
    Not doing that will lead to a crash when starting queues for this VF.
    
    Signed-off-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
    Signed-off-by: Ariel Elior <aelior@marvell.com>
    Signed-off-by: Shai Malin <smalin@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92abb09f7ab704a5e391c4cd57d69aec1d161cea
Author: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
Date:   Wed Jun 23 13:46:20 2021 +0200

    reset: reset-zynqmp: Fixed the argument data type
    
    [ Upstream commit ed104ca4bd9c405b41e968ad4ece51f6462e90b6 ]
    
    This patch changes the data type of the variable 'val' from
    int to u32.
    
    Addresses-Coverity: argument of type "int *" is incompatible with parameter of type "u32 *"
    Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Link: https://lore.kernel.org/r/925cebbe4eb73c7d0a536da204748d33c7100d8c.1624448778.git.michal.simek@xilinx.com
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b820c4c651ea1604445b8b5e087e39565a91fd95
Author: Krzysztof Hałasa <khalasa@piap.pl>
Date:   Mon Jun 7 12:49:07 2021 +0200

    gpu: ipu-v3: Fix i.MX IPU-v3 offset calculations for (semi)planar U/V formats
    
    [ Upstream commit 7cca7c8096e2c8a4149405438329b5035d0744f0 ]
    
    Video captured in 1400x1050 resolution (bytesperline aka stride = 1408
    bytes) is invalid. Fix it.
    
    Signed-off-by: Krzysztof Halasa <khalasa@piap.pl>
    Link: https://lore.kernel.org/r/m3y2bmq7a4.fsf@t19.piap.pl
    [p.zabel@pengutronix.de: added "gpu: ipu-v3:" prefix to commit description]
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48051387fa80aba75a08bdf65c95e32902637e1d
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Wed May 26 00:03:37 2021 -0700

    xtensa: fix kconfig unmet dependency warning for HAVE_FUTEX_CMPXCHG
    
    commit ed5aacc81cd41efc4d561e14af408d1003f7b855 upstream.
    
    XTENSA should only select HAVE_FUTEX_CMPXCHG when FUTEX is
    set/enabled. This prevents a kconfig warning.
    
    WARNING: unmet direct dependencies detected for HAVE_FUTEX_CMPXCHG
      Depends on [n]: FUTEX [=n]
      Selected by [y]:
      - XTENSA [=y] && !MMU [=n]
    
    Fixes: d951ba21b959 ("xtensa: nommu: select HAVE_FUTEX_CMPXCHG")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Max Filippov <jcmvbkbc@gmail.com>
    Cc: Chris Zankel <chris@zankel.net>
    Cc: linux-xtensa@linux-xtensa.org
    Message-Id: <20210526070337.28130-1-rdunlap@infradead.org>
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56c77c1b522928d86738e0d22d1adba44dc9c64b
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Apr 20 10:18:17 2021 +0200

    kthread: Fix PF_KTHREAD vs to_kthread() race
    
    commit 3a7956e25e1d7b3c148569e78895e1f3178122a9 upstream.
    
    The kthread_is_per_cpu() construct relies on only being called on
    PF_KTHREAD tasks (per the WARN in to_kthread). This gives rise to the
    following usage pattern:
    
            if ((p->flags & PF_KTHREAD) && kthread_is_per_cpu(p))
    
    However, as reported by syzcaller, this is broken. The scenario is:
    
            CPU0                            CPU1 (running p)
    
            (p->flags & PF_KTHREAD) // true
    
                                            begin_new_exec()
                                              me->flags &= ~(PF_KTHREAD|...);
            kthread_is_per_cpu(p)
              to_kthread(p)
                WARN(!(p->flags & PF_KTHREAD) <-- *SPLAT*
    
    Introduce __to_kthread() that omits the WARN and is sure to check both
    values.
    
    Use this to remove the problematic pattern for kthread_is_per_cpu()
    and fix a number of other kthread_*() functions that have similar
    issues but are currently not used in ways that would expose the
    problem.
    
    Notably kthread_func() is only ever called on 'current', while
    kthread_probe_data() is only used for PF_WQ_WORKER, which implies the
    task is from kthread_create*().
    
    Fixes: ac687e6e8c26 ("kthread: Extract KTHREAD_IS_PER_CPU")
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Valentin Schneider <Valentin.Schneider@arm.com>
    Link: https://lkml.kernel.org/r/YH6WJc825C4P0FCK@hirez.programming.kicks-ass.net
    Signed-off-by: Patrick Schaaf <bof@bof.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af3cf928b9989877487f7ec6b34e9f31d9d89a09
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Sep 1 09:40:41 2021 -0700

    ubifs: report correct st_size for encrypted symlinks
    
    commit 064c734986011390b4d111f1a99372b7f26c3850 upstream.
    
    The stat() family of syscalls report the wrong size for encrypted
    symlinks, which has caused breakage in several userspace programs.
    
    Fix this by calling fscrypt_symlink_getattr() after ubifs_getattr() for
    encrypted symlinks.  This function computes the correct size by reading
    and decrypting the symlink target (if it's not already cached).
    
    For more details, see the commit which added fscrypt_symlink_getattr().
    
    Fixes: ca7f85be8d6c ("ubifs: Add support for encrypted symlinks")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210702065350.209646-5-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa4e216156e8142cc4a0ff496632b49972464432
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Sep 1 09:40:40 2021 -0700

    f2fs: report correct st_size for encrypted symlinks
    
    commit 461b43a8f92e68e96c4424b31e15f2b35f1bbfa9 upstream.
    
    The stat() family of syscalls report the wrong size for encrypted
    symlinks, which has caused breakage in several userspace programs.
    
    Fix this by calling fscrypt_symlink_getattr() after f2fs_getattr() for
    encrypted symlinks.  This function computes the correct size by reading
    and decrypting the symlink target (if it's not already cached).
    
    For more details, see the commit which added fscrypt_symlink_getattr().
    
    Fixes: cbaf042a3cc6 ("f2fs crypto: add symlink encryption")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210702065350.209646-4-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52d8e5b0abb94c81dddb1f82f238c6cda483c2b3
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Sep 1 09:40:39 2021 -0700

    ext4: report correct st_size for encrypted symlinks
    
    commit 8c4bca10ceafc43b1ca0a9fab5fa27e13cbce99e upstream.
    
    The stat() family of syscalls report the wrong size for encrypted
    symlinks, which has caused breakage in several userspace programs.
    
    Fix this by calling fscrypt_symlink_getattr() after ext4_getattr() for
    encrypted symlinks.  This function computes the correct size by reading
    and decrypting the symlink target (if it's not already cached).
    
    For more details, see the commit which added fscrypt_symlink_getattr().
    
    Fixes: f348c252320b ("ext4 crypto: add symlink encryption")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210702065350.209646-3-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 228a4203d8b675b4bb58a5418a3898372f300c33
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Sep 1 09:40:38 2021 -0700

    fscrypt: add fscrypt_symlink_getattr() for computing st_size
    
    commit d18760560593e5af921f51a8c9b64b6109d634c2 upstream.
    
    Add a helper function fscrypt_symlink_getattr() which will be called
    from the various filesystems' ->getattr() methods to read and decrypt
    the target of encrypted symlinks in order to report the correct st_size.
    
    Detailed explanation:
    
    As required by POSIX and as documented in various man pages, st_size for
    a symlink is supposed to be the length of the symlink target.
    Unfortunately, st_size has always been wrong for encrypted symlinks
    because st_size is populated from i_size from disk, which intentionally
    contains the length of the encrypted symlink target.  That's slightly
    greater than the length of the decrypted symlink target (which is the
    symlink target that userspace usually sees), and usually won't match the
    length of the no-key encoded symlink target either.
    
    This hadn't been fixed yet because reporting the correct st_size would
    require reading the symlink target from disk and decrypting or encoding
    it, which historically has been considered too heavyweight to do in
    ->getattr().  Also historically, the wrong st_size had only broken a
    test (LTP lstat03) and there were no known complaints from real users.
    (This is probably because the st_size of symlinks isn't used too often,
    and when it is, typically it's for a hint for what buffer size to pass
    to readlink() -- which a slightly-too-large size still works for.)
    
    However, a couple things have changed now.  First, there have recently
    been complaints about the current behavior from real users:
    
    - Breakage in rpmbuild:
      https://github.com/rpm-software-management/rpm/issues/1682
      https://github.com/google/fscrypt/issues/305
    
    - Breakage in toybox cpio:
      https://www.mail-archive.com/toybox@lists.landley.net/msg07193.html
    
    - Breakage in libgit2: https://issuetracker.google.com/issues/189629152
      (on Android public issue tracker, requires login)
    
    Second, we now cache decrypted symlink targets in ->i_link.  Therefore,
    taking the performance hit of reading and decrypting the symlink target
    in ->getattr() wouldn't be as big a deal as it used to be, since usually
    it will just save having to do the same thing later.
    
    Also note that eCryptfs ended up having to read and decrypt symlink
    targets in ->getattr() as well, to fix this same issue; see
    commit 3a60a1686f0d ("eCryptfs: Decrypt symlink target for stat size").
    
    So, let's just bite the bullet, and read and decrypt the symlink target
    in ->getattr() in order to report the correct st_size.  Add a function
    fscrypt_symlink_getattr() which the filesystems will call to do this.
    
    (Alternatively, we could store the decrypted size of symlinks on-disk.
    But there isn't a great place to do so, and encryption is meant to hide
    the original size to some extent; that property would be lost.)
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210702065350.209646-2-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b3849ba667af99ee99a7853a021a7786851b9fd
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri Aug 20 23:44:17 2021 -0400

    ext4: fix race writing to an inline_data file while its xattrs are changing
    
    commit a54c4613dac1500b40e4ab55199f7c51f028e848 upstream.
    
    The location of the system.data extended attribute can change whenever
    xattr_sem is not taken.  So we need to recalculate the i_inline_off
    field since it mgiht have changed between ext4_write_begin() and
    ext4_write_end().
    
    This means that caching i_inline_off is probably not helpful, so in
    the long run we should probably get rid of it and shrink the in-memory
    ext4 inode slightly, but let's fix the race the simple way for now.
    
    Cc: stable@kernel.org
    Fixes: f19d5870cbf72 ("ext4: add normal write support for inline data")
    Reported-by: syzbot+13146364637c7363a7de@syzkaller.appspotmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>