commit a2428a8dcb4f3eb80e7d38dba0bf71e4ff20cecd
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Dec 19 12:27:32 2022 +0100

    Linux 5.10.160
    
    Link: https://lore.kernel.org/r/20221215172906.638553794@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54c15f67cb72a5ab856d15d3a887a4d8474e44be
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Fri Nov 25 16:23:47 2022 +0000

    ASoC: ops: Correct bounds check for second channel on SX controls
    
    commit f33bcc506050f89433a52a3052054d4ebd37b1c1 upstream.
    
    Currently the check against the max value for the control is being
    applied after the value has had the minimum applied and been masked. But
    the max value simply indicates the number of volume levels on an SX
    control, and as such should just be applied on the raw value.
    
    Fixes: 97eea946b939 ("ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()")
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20221125162348.1288005-1-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74b139c63f0775cf79266e9d9546c62b73fb3385
Author: Lei Rao <lei.rao@intel.com>
Date:   Tue Nov 29 17:48:11 2022 +0800

    nvme-pci: clear the prp2 field when not used
    
    [ Upstream commit a56ea6147facce4ac1fc38675455f9733d96232b ]
    
    If the prp2 field is not filled in nvme_setup_prp_simple(), the prp2
    field is garbage data. According to nvme spec, the prp2 is reserved if
    the data transfer does not cross a memory page boundary, so clear it to
    zero if it is not used.
    
    Signed-off-by: Lei Rao <lei.rao@intel.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 77ebf88e003140f10625d998b572ad1dde76d0c1
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Fri Nov 25 16:23:48 2022 +0000

    ASoC: cs42l51: Correct PGA Volume minimum value
    
    [ Upstream commit 3d1bb6cc1a654c8693a85b1d262e610196edec8b ]
    
    The table in the datasheet actually shows the volume values in the wrong
    order, with the two -3dB values being reversed. This appears to have
    caused the lower of the two values to be used in the driver when the
    higher should have been, correct this mixup.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20221125162348.1288005-2-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4db1d19b74e013ba26dae0e9e6025d670afc8759
Author: Yasushi SHOJI <yasushi.shoji@gmail.com>
Date:   Fri Nov 25 00:25:03 2022 +0900

    can: mcba_usb: Fix termination command argument
    
    [ Upstream commit 1a8e3bd25f1e789c8154e11ea24dc3ec5a4c1da0 ]
    
    Microchip USB Analyzer can activate the internal termination resistors
    by setting the "termination" option ON, or OFF to to deactivate them.
    As I've observed, both with my oscilloscope and captured USB packets
    below, you must send "0" to turn it ON, and "1" to turn it OFF.
    
    From the schematics in the user's guide, I can confirm that you must
    drive the CAN_RES signal LOW "0" to activate the resistors.
    
    Reverse the argument value of usb_msg.termination to fix this.
    
    These are the two commands sequence, ON then OFF.
    
    > No.     Time           Source                Destination           Protocol Length Info
    >       1 0.000000       host                  1.3.1                 USB      46     URB_BULK out
    >
    > Frame 1: 46 bytes on wire (368 bits), 46 bytes captured (368 bits)
    > USB URB
    > Leftover Capture Data: a80000000000000000000000000000000000a8
    >
    > No.     Time           Source                Destination           Protocol Length Info
    >       2 4.372547       host                  1.3.1                 USB      46     URB_BULK out
    >
    > Frame 2: 46 bytes on wire (368 bits), 46 bytes captured (368 bits)
    > USB URB
    > Leftover Capture Data: a80100000000000000000000000000000000a9
    
    Signed-off-by: Yasushi SHOJI <yashi@spacecubics.com>
    Link: https://lore.kernel.org/all/20221124152504.125994-1-yashi@spacecubics.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 683837f2f69d5ebd5e770d5096e3f65c237db4f9
Author: Heiko Schocher <hs@denx.de>
Date:   Wed Nov 23 08:16:36 2022 +0100

    can: sja1000: fix size of OCR_MODE_MASK define
    
    [ Upstream commit 26e8f6a75248247982458e8237b98c9fb2ffcf9d ]
    
    bitfield mode in ocr register has only 2 bits not 3, so correct
    the OCR_MODE_MASK define.
    
    Signed-off-by: Heiko Schocher <hs@denx.de>
    Link: https://lore.kernel.org/all/20221123071636.2407823-1-hs@denx.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 434b5236710f40f09c52f7073dc269d2904ce232
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Tue Nov 22 00:38:55 2022 +0100

    pinctrl: meditatek: Startup with the IRQs disabled
    
    [ Upstream commit 11780e37565db4dd064d3243ca68f755c13f65b4 ]
    
    If the system is restarted via kexec(), the peripherals do not start
    with a known state.
    
    If the previous system had enabled an IRQs we will receive unexected
    IRQs that can lock the system.
    
    [   28.109251] watchdog: BUG: soft lockup - CPU#0 stuck for 26s!
    [swapper/0:0]
    [   28.109263] Modules linked in:
    [   28.109273] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
    5.15.79-14458-g4b9edf7b1ac6 #1 9f2e76613148af94acccd64c609a552fb4b4354b
    [   28.109284] Hardware name: Google Elm (DT)
    [   28.109290] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS
                    BTYPE=--)
    [   28.109298] pc : __do_softirq+0xa0/0x388
    [   28.109309] lr : __do_softirq+0x70/0x388
    [   28.109316] sp : ffffffc008003ee0
    [   28.109321] x29: ffffffc008003f00 x28: 000000000000000a x27:
    0000000000000080
    [   28.109334] x26: 0000000000000001 x25: ffffffefa7b350c0 x24:
    ffffffefa7b47480
    [   28.109346] x23: ffffffefa7b3d000 x22: 0000000000000000 x21:
    ffffffefa7b0fa40
    [   28.109358] x20: ffffffefa7b005b0 x19: ffffffefa7b47480 x18:
    0000000000065b6b
    [   28.109370] x17: ffffffefa749c8b0 x16: 000000000000018c x15:
    00000000000001b8
    [   28.109382] x14: 00000000000d3b6b x13: 0000000000000006 x12:
    0000000000057e91
    [   28.109394] x11: 0000000000000000 x10: 0000000000000000 x9 :
    ffffffefa7b47480
    [   28.109406] x8 : 00000000000000e0 x7 : 000000000f424000 x6 :
    0000000000000000
    [   28.109418] x5 : ffffffefa7dfaca0 x4 : ffffffefa7dfadf0 x3 :
    000000000000000f
    [   28.109429] x2 : 0000000000000000 x1 : 0000000000000100 x0 :
    0000000001ac65c5
    [   28.109441] Call trace:
    [   28.109447]  __do_softirq+0xa0/0x388
    [   28.109454]  irq_exit+0xc0/0xe0
    [   28.109464]  handle_domain_irq+0x68/0x90
    [   28.109473]  gic_handle_irq+0xac/0xf0
    [   28.109480]  call_on_irq_stack+0x28/0x50
    [   28.109488]  do_interrupt_handler+0x44/0x58
    [   28.109496]  el1_interrupt+0x30/0x58
    [   28.109506]  el1h_64_irq_handler+0x18/0x24
    [   28.109512]  el1h_64_irq+0x7c/0x80
    [   28.109519]  arch_local_irq_enable+0xc/0x18
    [   28.109529]  default_idle_call+0x40/0x140
    [   28.109539]  do_idle+0x108/0x290
    [   28.109547]  cpu_startup_entry+0x2c/0x30
    [   28.109554]  rest_init+0xe8/0xf8
    [   28.109562]  arch_call_rest_init+0x18/0x24
    [   28.109571]  start_kernel+0x338/0x42c
    [   28.109578]  __primary_switched+0xbc/0xc4
    [   28.109588] Kernel panic - not syncing: softlockup: hung tasks
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Link: https://lore.kernel.org/r/20221122-mtk-pinctrl-v1-1-bedf5655a3d2@chromium.org
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5cb4abb0caa586859e56c71a6c44882e451a980a
Author: Hou Tao <houtao1@huawei.com>
Date:   Wed Nov 16 15:23:48 2022 +0800

    libbpf: Use page size as max_entries when probing ring buffer map
    
    [ Upstream commit 689eb2f1ba46b4b02195ac2a71c55b96d619ebf8 ]
    
    Using page size as max_entries when probing ring buffer map, else the
    probe may fail on host with 64KB page size (e.g., an ARM64 host).
    
    After the fix, the output of "bpftool feature" on above host will be
    correct.
    
    Before :
        eBPF map_type ringbuf is NOT available
        eBPF map_type user_ringbuf is NOT available
    
    After :
        eBPF map_type ringbuf is available
        eBPF map_type user_ringbuf is available
    
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20221116072351.1168938-2-houtao@huaweicloud.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50b5f6d4d9d2d69a7498c44fd8b26e13d73d3d98
Author: Mark Brown <broonie@kernel.org>
Date:   Wed May 11 14:41:37 2022 +0100

    ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
    
    [ Upstream commit 97eea946b93961fffd29448dcda7398d0d51c4b2 ]
    
    The bounds checks in snd_soc_put_volsw_sx() are only being applied to the
    first channel, meaning it is possible to write out of bounds values to the
    second channel in stereo controls. Add appropriate checks.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20220511134137.169575-2-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 344739dc56f1b3e33e6a3170b89731d450455df6
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Sat May 7 20:14:14 2022 +0800

    ASoC: fsl_micfil: explicitly clear CHnF flags
    
    [ Upstream commit b776c4a4618ec1b5219d494c423dc142f23c4e8f ]
    
    There may be failure when start 1 channel recording after
    8 channels recording. The reason is that the CHnF
    flags are not cleared successfully by software reset.
    
    This issue is triggerred by the change of clearing
    software reset bit.
    
    CHnF flags are write 1 clear bits. Clear them by force
    write.
    
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1651925654-32060-2-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a49c1a7307752ed5e371373f4db6a426857d4eed
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Sat May 7 20:14:13 2022 +0800

    ASoC: fsl_micfil: explicitly clear software reset bit
    
    [ Upstream commit 292709b9cf3ba470af94b62c9bb60284cc581b79 ]
    
    SRES is self-cleared bit, but REG_MICFIL_CTRL1 is defined as
    non volatile register, it still remain in regmap cache after set,
    then every update of REG_MICFIL_CTRL1, software reset happens.
    to avoid this, clear it explicitly.
    
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1651925654-32060-1-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75454b4bbfc7e6a4dd8338556f36ea9107ddf61a
Author: Bing-Jhong Billy Jheng <billy@starlabs.sg>
Date:   Thu Dec 15 06:43:56 2022 -0800

    io_uring: add missing item types for splice request
    
    Splice is like read/write and should grab current->nsproxy, denoted by
    IO_WQ_WORK_FILES as it refers to current->files as well
    
    Signed-off-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17f386e6b7695afdb10474431dfd754c92feaedd
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Wed Nov 11 17:22:32 2020 +0100

    fuse: always revalidate if exclusive create
    
    commit df8629af293493757beccac2d3168fe5a315636e upstream.
    
    Failure to do so may result in EEXIST even if the file only exists in the
    cache and not in the filesystem.
    
    The atomic nature of O_EXCL mandates that the cached state should be
    ignored and existence verified anew.
    
    Reported-by: Ken Schalk <kschalk@nvidia.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Wu Bo <bo.wu@vivo.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb6313c12955c58c3d3d40f086c22e44ca1c9a1b
Author: Jialiang Wang <wangjialiang0806@163.com>
Date:   Wed Aug 10 15:30:57 2022 +0800

    nfp: fix use-after-free in area_cache_get()
    
    commit 02e1a114fdb71e59ee6770294166c30d437bf86a upstream.
    
    area_cache_get() is used to distribute cache->area and set cache->id,
     and if cache->id is not 0 and cache->area->kref refcount is 0, it will
     release the cache->area by nfp_cpp_area_release(). area_cache_get()
     set cache->id before cpp->op->area_init() and nfp_cpp_area_acquire().
    
    But if area_init() or nfp_cpp_area_acquire() fails, the cache->id is
     is already set but the refcount is not increased as expected. At this
     time, calling the nfp_cpp_area_release() will cause use-after-free.
    
    To avoid the use-after-free, set cache->id after area_init() and
     nfp_cpp_area_acquire() complete successfully.
    
    Note: This vulnerability is triggerable by providing emulated device
     equipped with specified configuration.
    
     BUG: KASAN: use-after-free in nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760)
      Write of size 4 at addr ffff888005b7f4a0 by task swapper/0/1
    
     Call Trace:
      <TASK>
     nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760)
     area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:884)
    
     Allocated by task 1:
     nfp_cpp_area_alloc_with_name (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:303)
     nfp_cpp_area_cache_add (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:802)
     nfp6000_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:1230)
     nfp_cpp_from_operations (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:1215)
     nfp_pci_probe (drivers/net/ethernet/netronome/nfp/nfp_main.c:744)
    
     Freed by task 1:
     kfree (mm/slub.c:4562)
     area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:873)
     nfp_cpp_read (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:924 drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:973)
     nfp_cpp_readl (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpplib.c:48)
    
    Signed-off-by: Jialiang Wang <wangjialiang0806@163.com>
    Reviewed-by: Yinjun Zhang <yinjun.zhang@corigine.com>
    Acked-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20220810073057.4032-1-wangjialiang0806@163.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 965d93fb39b99348d6c327853afd4708b610e132
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Tue Dec 13 15:13:41 2022 +0200

    vfs: fix copy_file_range() averts filesystem freeze protection
    
    commit 10bc8e4af65946b727728d7479c028742321b60a upstream.
    
    [backport comments for pre v5.15:
    - ksmbd mentions are irrelevant - ksmbd hunks were dropped
    - sb_write_started() is missing - assert was dropped
    ]
    
    Commit 868f9f2f8e00 ("vfs: fix copy_file_range() regression in cross-fs
    copies") removed fallback to generic_copy_file_range() for cross-fs
    cases inside vfs_copy_file_range().
    
    To preserve behavior of nfsd and ksmbd server-side-copy, the fallback to
    generic_copy_file_range() was added in nfsd and ksmbd code, but that
    call is missing sb_start_write(), fsnotify hooks and more.
    
    Ideally, nfsd and ksmbd would pass a flag to vfs_copy_file_range() that
    will take care of the fallback, but that code would be subtle and we got
    vfs_copy_file_range() logic wrong too many times already.
    
    Instead, add a flag to explicitly request vfs_copy_file_range() to
    perform only generic_copy_file_range() and let nfsd and ksmbd use this
    flag only in the fallback path.
    
    This choise keeps the logic changes to minimum in the non-nfsd/ksmbd code
    paths to reduce the risk of further regressions.
    
    Fixes: 868f9f2f8e00 ("vfs: fix copy_file_range() regression in cross-fs copies")
    Tested-by: Namjae Jeon <linkinjeon@kernel.org>
    Tested-by: Luis Henriques <lhenriques@suse.de>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed9673394979b7a5dff10ba878178054625beda9
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Tue Dec 13 15:13:40 2022 +0200

    vfs: fix copy_file_range() regression in cross-fs copies
    
    commit 868f9f2f8e004bfe0d3935b1976f625b2924893b upstream.
    
    [backport comments for pre v5.15:
    - This commit has a bug fixed by commit 10bc8e4af659 ("vfs: fix
      copy_file_range() averts filesystem freeze protection")
    - ksmbd mentions are irrelevant - ksmbd hunks were dropped
    ]
    
    A regression has been reported by Nicolas Boichat, found while using the
    copy_file_range syscall to copy a tracefs file.
    
    Before commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
    devices") the kernel would return -EXDEV to userspace when trying to
    copy a file across different filesystems.  After this commit, the
    syscall doesn't fail anymore and instead returns zero (zero bytes
    copied), as this file's content is generated on-the-fly and thus reports
    a size of zero.
    
    Another regression has been reported by He Zhe - the assertion of
    WARN_ON_ONCE(ret == -EOPNOTSUPP) can be triggered from userspace when
    copying from a sysfs file whose read operation may return -EOPNOTSUPP.
    
    Since we do not have test coverage for copy_file_range() between any two
    types of filesystems, the best way to avoid these sort of issues in the
    future is for the kernel to be more picky about filesystems that are
    allowed to do copy_file_range().
    
    This patch restores some cross-filesystem copy restrictions that existed
    prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
    devices"), namely, cross-sb copy is not allowed for filesystems that do
    not implement ->copy_file_range().
    
    Filesystems that do implement ->copy_file_range() have full control of
    the result - if this method returns an error, the error is returned to
    the user.  Before this change this was only true for fs that did not
    implement the ->remap_file_range() operation (i.e.  nfsv3).
    
    Filesystems that do not implement ->copy_file_range() still fall-back to
    the generic_copy_file_range() implementation when the copy is within the
    same sb.  This helps the kernel can maintain a more consistent story
    about which filesystems support copy_file_range().
    
    nfsd and ksmbd servers are modified to fall-back to the
    generic_copy_file_range() implementation in case vfs_copy_file_range()
    fails with -EOPNOTSUPP or -EXDEV, which preserves behavior of
    server-side-copy.
    
    fall-back to generic_copy_file_range() is not implemented for the smb
    operation FSCTL_DUPLICATE_EXTENTS_TO_FILE, which is arguably a correct
    change of behavior.
    
    Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
    Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
    Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
    Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
    Link: https://lore.kernel.org/linux-fsdevel/20210630161320.29006-1-lhenriques@suse.de/
    Reported-by: Nicolas Boichat <drinkcat@chromium.org>
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Signed-off-by: Luis Henriques <lhenriques@suse.de>
    Fixes: 64bf5ff58dff ("vfs: no fallback for ->copy_file_range")
    Link: https://lore.kernel.org/linux-fsdevel/20f17f64-88cb-4e80-07c1-85cb96c83619@windriver.com/
    Reported-by: He Zhe <zhe.he@windriver.com>
    Tested-by: Namjae Jeon <linkinjeon@kernel.org>
    Tested-by: Luis Henriques <lhenriques@suse.de>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216800
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 970862a96c0d157cbad044406e0062674857d1a8
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Tue Oct 20 21:13:55 2020 -0700

    x86/smpboot: Move rcu_cpu_starting() earlier
    
    commit 29368e09392123800e5e2bf0f3eda91f16972e52 upstream.
    
    The call to rcu_cpu_starting() in mtrr_ap_init() is not early enough
    in the CPU-hotplug onlining process, which results in lockdep splats
    as follows:
    
    =============================
    WARNING: suspicious RCU usage
    5.9.0+ #268 Not tainted
    -----------------------------
    kernel/kprobes.c:300 RCU-list traversed in non-reader section!!
    
    other info that might help us debug this:
    
    RCU used illegally from offline CPU!
    rcu_scheduler_active = 1, debug_locks = 1
    no locks held by swapper/1/0.
    
    stack backtrace:
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.9.0+ #268
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1ubuntu1 04/01/2014
    Call Trace:
     dump_stack+0x77/0x97
     __is_insn_slot_addr+0x15d/0x170
     kernel_text_address+0xba/0xe0
     ? get_stack_info+0x22/0xa0
     __kernel_text_address+0x9/0x30
     show_trace_log_lvl+0x17d/0x380
     ? dump_stack+0x77/0x97
     dump_stack+0x77/0x97
     __lock_acquire+0xdf7/0x1bf0
     lock_acquire+0x258/0x3d0
     ? vprintk_emit+0x6d/0x2c0
     _raw_spin_lock+0x27/0x40
     ? vprintk_emit+0x6d/0x2c0
     vprintk_emit+0x6d/0x2c0
     printk+0x4d/0x69
     start_secondary+0x1c/0x100
     secondary_startup_64_no_verify+0xb8/0xbb
    
    This is avoided by moving the call to rcu_cpu_starting up near
    the beginning of the start_secondary() function.  Note that the
    raw_smp_processor_id() is required in order to avoid calling into lockdep
    before RCU has declared the CPU to be watched for readers.
    
    Link: https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/
    Reported-by: Qian Cai <cai@redhat.com>
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Cc: Joel Fernandes <joel@joelfernandes.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>