Linux 5.15.112

 
af_packet: Don't send zero-byte data in packet_sendmsg_spkt(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Mon May 1 13:28:57 2023 -0700

    af_packet: Don't send zero-byte data in packet_sendmsg_spkt().
    
    [ Upstream commit 6a341729fb31b4c5df9f74f24b4b1c98410c9b87 ]
    
    syzkaller reported a warning below [0].
    
    We can reproduce it by sending 0-byte data from the (AF_PACKET,
    SOCK_PACKET) socket via some devices whose dev->hard_header_len
    is 0.
    
        struct sockaddr_pkt addr = {
            .spkt_family = AF_PACKET,
            .spkt_device = "tun0",
        };
        int fd;
    
        fd = socket(AF_PACKET, SOCK_PACKET, 0);
        sendto(fd, NULL, 0, 0, (struct sockaddr *)&addr, sizeof(addr));
    
    We have a similar fix for the (AF_PACKET, SOCK_RAW) socket as
    commit dc633700f00f ("net/af_packet: check len when min_header_len
    equals to 0").
    
    Let's add the same test for the SOCK_PACKET socket.
    
    [0]:
    skb_assert_len
    WARNING: CPU: 1 PID: 19945 at include/linux/skbuff.h:2552 skb_assert_len include/linux/skbuff.h:2552 [inline]
    WARNING: CPU: 1 PID: 19945 at include/linux/skbuff.h:2552 __dev_queue_xmit+0x1f26/0x31d0 net/core/dev.c:4159
    Modules linked in:
    CPU: 1 PID: 19945 Comm: syz-executor.0 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:skb_assert_len include/linux/skbuff.h:2552 [inline]
    RIP: 0010:__dev_queue_xmit+0x1f26/0x31d0 net/core/dev.c:4159
    Code: 89 de e8 1d a2 85 fd 84 db 75 21 e8 64 a9 85 fd 48 c7 c6 80 2a 1f 86 48 c7 c7 c0 06 1f 86 c6 05 23 cf 27 04 01 e8 fa ee 56 fd <0f> 0b e8 43 a9 85 fd 0f b6 1d 0f cf 27 04 31 ff 89 de e8 e3 a1 85
    RSP: 0018:ffff8880217af6e0 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc90001133000
    RDX: 0000000000040000 RSI: ffffffff81186922 RDI: 0000000000000001
    RBP: ffff8880217af8b0 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000001 R12: ffff888030045640
    R13: ffff8880300456b0 R14: ffff888030045650 R15: ffff888030045718
    FS:  00007fc5864da640(0000) GS:ffff88806cd00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020005740 CR3: 000000003f856003 CR4: 0000000000770ee0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <TASK>
     dev_queue_xmit include/linux/netdevice.h:3085 [inline]
     packet_sendmsg_spkt+0xc4b/0x1230 net/packet/af_packet.c:2066
     sock_sendmsg_nosec net/socket.c:724 [inline]
     sock_sendmsg+0x1b4/0x200 net/socket.c:747
     ____sys_sendmsg+0x331/0x970 net/socket.c:2503
     ___sys_sendmsg+0x11d/0x1c0 net/socket.c:2557
     __sys_sendmmsg+0x18c/0x430 net/socket.c:2643
     __do_sys_sendmmsg net/socket.c:2672 [inline]
     __se_sys_sendmmsg net/socket.c:2669 [inline]
     __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2669
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    RIP: 0033:0x7fc58791de5d
    Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
    RSP: 002b:00007fc5864d9cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
    RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007fc58791de5d
    RDX: 0000000000000001 RSI: 0000000020005740 RDI: 0000000000000004
    RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000000000b R14: 00007fc58797e530 R15: 0000000000000000
     </TASK>
    ---[ end trace 0000000000000000 ]---
    skb len=0 headroom=16 headlen=0 tailroom=304
    mac=(16,0) net=(16,-1) trans=-1
    shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
    csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
    hash(0x0 sw=0 l4=0) proto=0x0000 pkttype=0 iif=0
    dev name=sit0 feat=0x00000006401d7869
    sk family=17 type=10 proto=0
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: caiaq: input: Add error handling for unsupported input methods in `snd_usb_caiaq_input_init` [+ + +]
Author: Ruliang Lin <u202112092@hust.edu.cn>
Date:   Thu May 4 14:50:53 2023 +0800

    ALSA: caiaq: input: Add error handling for unsupported input methods in `snd_usb_caiaq_input_init`
    
    [ Upstream commit 0d727e1856ef22dd9337199430258cb64cbbc658 ]
    
    Smatch complains that:
    snd_usb_caiaq_input_init() warn: missing error code 'ret'
    
    This patch adds a new case to handle the situation where the
    device does not support any input methods in the
    `snd_usb_caiaq_input_init` function. It returns an `-EINVAL` error code
    to indicate that no input methods are supported on the device.
    
    Fixes: 523f1dce3743 ("[ALSA] Add Native Instrument usb audio device support")
    Signed-off-by: Ruliang Lin <u202112092@hust.edu.cn>
    Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
    Acked-by: Daniel Mack <daniel@zonque.org>
    Link: https://lore.kernel.org/r/20230504065054.3309-1-u202112092@hust.edu.cn
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: dts: exynos: fix WM8960 clock name in Itop Elite [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Feb 17 16:06:27 2023 +0100

    ARM: dts: exynos: fix WM8960 clock name in Itop Elite
    
    commit 6c950c20da38debf1ed531e0b972bd8b53d1c11f upstream.
    
    The WM8960 Linux driver expects the clock to be named "mclk".  Otherwise
    the clock will be ignored and not prepared/enabled by the driver.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 339b2fb36a67 ("ARM: dts: exynos: Add TOPEET itop elite based board")
    Link: https://lore.kernel.org/r/20230217150627.779764-3-krzysztof.kozlowski@linaro.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: dts: s5pv210: correct MIPI CSIS clock name [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun Feb 12 19:58:18 2023 +0100

    ARM: dts: s5pv210: correct MIPI CSIS clock name
    
    commit 665b9459bb53b8f19bd1541567e1fe9782c83c4b upstream.
    
    The Samsung S5P/Exynos MIPI CSIS bindings and Linux driver expect first
    clock name to be "csis".  Otherwise the driver fails to probe.
    
    Fixes: 94ad0f6d9278 ("ARM: dts: Add Device tree for s5pv210 SoC")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230212185818.43503-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ASoC: DPCM: Don't pick up BE without substream [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Aug 1 19:05:10 2022 +0200

    ASoC: DPCM: Don't pick up BE without substream
    
    commit 754590651ccbbcc74a7c20907be4bb15d642bde3 upstream.
    
    When DPCM tries to add valid BE connections at dpcm_add_paths(), it
    doesn't check whether the picked BE actually supports for the given
    stream direction.  Due to that, when an asymmetric BE stream is
    present, it picks up wrongly and this may result in a NULL dereference
    at a later point where the code assumes the existence of a
    corresponding BE substream.
    
    This patch adds the check for the presence of the substream for the
    target BE for avoiding the problem above.
    
    Note that we have already some fix for non-existing BE substream at
    commit 6246f283d5e0 ("ASoC: dpcm: skip missing substream while
    applying symmetry").  But the code path we've hit recently is rather
    happening before the previous fix.  So this patch tries to fix at
    picking up a BE instead of parsing BE lists.
    
    Fixes: bbf7d3b1c4f4 ("ASoC: soc-pcm: align BE 'atomicity' with that of the FE")
    Reported-by: Alex Natalsson <harmoniesworlds@gmail.com>
    Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Cc: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/CADs9LoPZH_D+eJ9qjTxSLE5jGyhKsjMN7g2NighZ16biVxsyKw@mail.gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20220801170510.26582-1-tiwai@suse.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: soc-compress: Inherit atomicity from DAI link for Compress FE [+ + +]
Author: Daniel Baluta <daniel.baluta@nxp.com>
Date:   Fri Mar 24 14:40:19 2023 +0200

    ASoC: soc-compress: Inherit atomicity from DAI link for Compress FE
    
    commit 37b58becc1cee4d591024f2056d7ffa99c6089e0 upstream.
    
    After commit bbf7d3b1c4f40 ("ASoC: soc-pcm: align BE 'atomicity' with
    that of the FE") BE and FE atomicity must match.
    
    In the case of Compress PCM there is a mismatch in atomicity between FE
    and BE and we get errors like this:
    
    [   36.434566]  sai1-wm8960-hifi: dpcm_be_connect: FE is atomic but BE
    is nonatomic, invalid configuration
    [   36.444278]  PCM Deep Buffer: ASoC: can't connect SAI1.OUT
    
    In order to fix this we must inherit the atomicity from DAI link
    associated with current PCM Compress FE.
    
    Fixes: bbf7d3b1c4f4 ("ASoC: soc-pcm: align BE 'atomicity' with that of the FE")
    Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20230324124019.30826-1-daniel.baluta@oss.nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: soc-pcm.c: call __soc_pcm_close() in soc_pcm_close() [+ + +]
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Mon Aug 22 02:35:32 2022 +0000

    ASoC: soc-pcm.c: call __soc_pcm_close() in soc_pcm_close()
    
    commit 6bbabd28805f36baf6d0f3eb082db032a638f612 upstream.
    
    commit b7898396f4bbe16 ("ASoC: soc-pcm: Fix and cleanup DPCM locking")
    added __soc_pcm_close() for non-lock version of soc_pcm_close().
    But soc_pcm_close() is not using it. It is no problem, but confusable.
    
            static int __soc_pcm_close(...)
            {
    =>              return soc_pcm_clean(rtd, substream, 0);
            }
    
            static int soc_pcm_close(...)
            {
                    ...
                    snd_soc_dpcm_mutex_lock(rtd);
    =>              soc_pcm_clean(rtd, substream, 0);
                    snd_soc_dpcm_mutex_unlock(rtd);
                    return 0;
            }
    
    This patch use it.
    
    Fixes: b7898396f4bbe16 ("ASoC: soc-pcm: Fix and cleanup DPCM locking")
    Cc: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Link: https://lore.kernel.org/r/87czctgg3w.wl-kuninori.morimoto.gx@renesas.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: soc-pcm: align BE 'atomicity' with that of the FE [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Tue Dec 7 11:37:41 2021 -0600

    ASoC: soc-pcm: align BE 'atomicity' with that of the FE
    
    [ Upstream commit bbf7d3b1c4f40eb02dd1dffb500ba00b0bff0303 ]
    
    Since the flow for DPCM is based on taking a lock for the FE first, we
    need to make sure during the connection between a BE and an FE that
    they both use the same 'atomicity', otherwise we may sleep in atomic
    context.
    
    If the FE is nonatomic, this patch forces the BE to be nonatomic as
    well. That should have no negative impact since the BE 'inherits' the
    FE properties.
    
    However, if the FE is atomic and the BE is not, then the configuration
    is flagged as invalid.
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    [ removed FE stream lock by tiwai ]
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Link: https://lore.kernel.org/r/20211207173745.15850-3-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: soc-pcm: Fix and cleanup DPCM locking [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Dec 7 11:37:42 2021 -0600

    ASoC: soc-pcm: Fix and cleanup DPCM locking
    
    [ Upstream commit b7898396f4bbe160f546d0c5e9fa17cca9a7d153 ]
    
    The existing locking for DPCM has several issues
    a) a confusing mix of card->mutex and card->pcm_mutex.
    b) a dpcm_lock spinlock added inconsistently and on paths that could
    be recursively taken. The use of irqsave/irqrestore was also overkill.
    
    The suggested model is:
    
    1) The pcm_mutex is the top-most protection of BE links in the FE. The
    pcm_mutex is applied always on either the top PCM callbacks or the
    external call from DAPM, not taken in the internal functions.
    
    2) the FE stream lock is taken in higher levels before invoking
    dpcm_be_dai_trigger()
    
    3) when adding and deleting a BE, both the pcm_mutex and FE stream
    lock are taken.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [clarification of commit message by plbossart]
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Link: https://lore.kernel.org/r/20211207173745.15850-4-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: soc-pcm: fix BE handling of PAUSE_RELEASE [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Tue Dec 7 11:37:45 2021 -0600

    ASoC: soc-pcm: fix BE handling of PAUSE_RELEASE
    
    [ Upstream commit 3aa1e96a2b95e2ece198f8dd01e96818971b84df ]
    
    A BE connected to more than one FE, e.g. in a mixer case, can go
    through the following transitions.
    
    play FE1    -> BE state is START
    pause FE1   -> BE state is PAUSED
    play FE2    -> BE state is START
    stop FE2    -> BE state is STOP (see note [1] below)
    release FE1 -> BE state is START
    stop FE1    -> BE state is STOP
    
    play FE1    -> BE state is START
    pause FE1   -> BE state is PAUSED
    play FE2    -> BE state is START
    release FE1 -> BE state is START
    stop FE2    -> BE state is START
    stop FE1    -> BE state is STOP
    
    play FE1    -> BE state is START
    play FE2    -> BE state is START (no change)
    pause FE1   -> BE state is START (no change)
    pause FE2   -> BE state is PAUSED
    release FE1 -> BE state is START
    release FE2 -> BE state is START (no change)
    stop FE1    -> BE state is START (no change)
    stop FE2    -> BE state is STOP
    
    The existing code for PAUSE_RELEASE only allows for the case where the
    BE is paused, which clearly would not work in the sequences above.
    
    Extend the allowed states to restart the BE when PAUSE_RELEASE is
    received, and increase the refcount if the BE is already in START.
    
    [1] the existing logic does not move the BE state back to PAUSED when
    the FE2 is stopped. This patch does not change the logic; it would be
    painful to keep a history of changes on the FE side, the state machine
    is already rather complicated with transitions based on the last BE
    state and the trigger type.
    
    Reported-by: Bard Liao <bard.liao@intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Link: https://lore.kernel.org/r/20211207173745.15850-7-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: soc-pcm: Fix DPCM lockdep warning due to nested stream locks [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 19 16:52:48 2022 +0100

    ASoC: soc-pcm: Fix DPCM lockdep warning due to nested stream locks
    
    commit 3c75c0ea5da749bd1efebd1387f2e5011b8c7d78 upstream.
    
    The recent change for DPCM locking caused spurious lockdep warnings.
    Actually the warnings are false-positive, as those are triggered due
    to the nested stream locks for FE and BE.  Since both locks belong to
    the same lock class, lockdep sees it as if a deadlock.
    
    For fixing this, we need to take PCM stream locks for BE with the
    nested lock primitives.  Since currently snd_pcm_stream_lock*() helper
    assumes only the top-level single locking, a new helper function
    snd_pcm_stream_lock_irqsave_nested() is defined for a single-depth
    nested lock, which is now used in the BE DAI trigger that is always
    performed inside a FE stream lock.
    
    Fixes: b2ae80663008 ("ASoC: soc-pcm: serialize BE triggers")
    Reported-and-tested-by: Hans de Goede <hdegoede@redhat.com>
    Reported-and-tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/73018f3c-9769-72ea-0325-b3f8e2381e30@redhat.com
    Link: https://lore.kernel.org/alsa-devel/9a0abddd-49e9-872d-2f00-a1697340f786@samsung.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20220119155249.26754-2-tiwai@suse.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: soc-pcm: Move debugfs removal out of spinlock [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 19 16:52:49 2022 +0100

    ASoC: soc-pcm: Move debugfs removal out of spinlock
    
    commit 9f620684c1ef5a002b6622ecc7b5818e81252f48 upstream.
    
    The recent fix for DPCM locking also covered the loop in
    dpcm_be_disconnect() with the FE stream lock.  This caused an
    unexpected side effect, thought: calling debugfs_remove_recursive() in
    the spinlock may lead to lockdep splats as the code there assumes the
    SOFTIRQ-safe context.
    
    For avoiding the problem, this patch changes the disconnection
    procedure to two phases: at first, the matching entries are removed
    from the linked list, then the resources are freed outside the lock.
    
    Fixes: b7898396f4bb ("ASoC: soc-pcm: Fix and cleanup DPCM locking")
    Reported-and-tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20220119155249.26754-3-tiwai@suse.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: soc-pcm: serialize BE triggers [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Dec 7 11:37:43 2021 -0600

    ASoC: soc-pcm: serialize BE triggers
    
    [ Upstream commit b2ae80663008a7662febe7d13f14ea1b2eb0cd51 ]
    
    When more than one FE is connected to a BE, e.g. in a mixing use case,
    the BE can be triggered multiple times when the FE are opened/started
    concurrently. This race condition is problematic in the case of
    SoundWire BE dailinks, and this is not desirable in a general
    case.
    
    This patch relies on the existing BE PCM lock, which takes atomicity into
    account. The locking model assumes that all interactions start with
    the FE, so that there is no deadlock between FE and BE locks.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [test, checkpatch fix and clarification of commit message by plbossart]
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Link: https://lore.kernel.org/r/20211207173745.15850-5-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: soc-pcm: test refcount before triggering [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Tue Dec 7 11:37:44 2021 -0600

    ASoC: soc-pcm: test refcount before triggering
    
    [ Upstream commit 848aedfdc6ba25ad5652797db9266007773e44dd ]
    
    On start/pause_release/resume, when more than one FE is connected to
    the same BE, it's possible that the trigger is sent more than
    once. This is not desirable, we only want to trigger a BE once, which
    is straightforward to implement with a refcount.
    
    For stop/pause/suspend, the problem is more complicated: the check
    implemented in snd_soc_dpcm_can_be_free_stop() may fail due to a
    conceptual deadlock when we trigger the BE before the FE. In this
    case, the FE states have not yet changed, so there are corner cases
    where the TRIGGER_STOP is never sent - the dual case of start where
    multiple triggers might be sent.
    
    This patch suggests an unconditional trigger in all cases, without
    checking the FE states, using a refcount protected by the BE PCM
    stream lock.
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Link: https://lore.kernel.org/r/20211207173745.15850-6-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: soc-pcm: use GFP_ATOMIC for dpcm structure [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Tue Dec 7 11:37:40 2021 -0600

    ASoC: soc-pcm: use GFP_ATOMIC for dpcm structure
    
    [ Upstream commit d8a9c6e1f6766a16cf02b4e99a629f3c5512c183 ]
    
    We allocate a structure in dpcm_be_connect(), which may be called in
    atomic context. Using GFP_KERNEL is not quite right, we have to use
    GFP_ATOMIC to prevent the allocator from sleeping.
    
    Suggested-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Link: https://lore.kernel.org/r/20211207173745.15850-2-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: don't free qgroup space unless specified [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Tue May 2 16:00:06 2023 -0400

    btrfs: don't free qgroup space unless specified
    
    commit d246331b78cbef86237f9c22389205bc9b4e1cc1 upstream.
    
    Boris noticed in his simple quotas testing that he was getting a leak
    with Sweet Tea's change to subvol create that stopped doing a
    transaction commit.  This was just a side effect of that change.
    
    In the delayed inode code we have an optimization that will free extra
    reservations if we think we can pack a dir item into an already modified
    leaf.  Previously this wouldn't be triggered in the subvolume create
    case because we'd commit the transaction, it was still possible but
    much harder to trigger.  It could actually be triggered if we did a
    mkdir && subvol create with qgroups enabled.
    
    This occurs because in btrfs_insert_delayed_dir_index(), which gets
    called when we're adding the dir item, we do the following:
    
      btrfs_block_rsv_release(fs_info, trans->block_rsv, bytes, NULL);
    
    if we're able to skip reserving space.
    
    The problem here is that trans->block_rsv points at the temporary block
    rsv for the subvolume create, which has qgroup reservations in the block
    rsv.
    
    This is a problem because btrfs_block_rsv_release() will do the
    following:
    
      if (block_rsv->qgroup_rsv_reserved >= block_rsv->qgroup_rsv_size) {
              qgroup_to_release = block_rsv->qgroup_rsv_reserved -
                      block_rsv->qgroup_rsv_size;
              block_rsv->qgroup_rsv_reserved = block_rsv->qgroup_rsv_size;
      }
    
    The temporary block rsv just has ->qgroup_rsv_reserved set,
    ->qgroup_rsv_size == 0.  The optimization in
    btrfs_insert_delayed_dir_index() sets ->qgroup_rsv_reserved = 0.  Then
    later on when we call btrfs_subvolume_release_metadata() which has
    
      btrfs_block_rsv_release(fs_info, rsv, (u64)-1, &qgroup_to_release);
      btrfs_qgroup_convert_reserved_meta(root, qgroup_to_release);
    
    qgroup_to_release is set to 0, and we do not convert the reserved
    metadata space.
    
    The problem here is that the block rsv code has been unconditionally
    messing with ->qgroup_rsv_reserved, because the main place this is used
    is delalloc, and any time we call btrfs_block_rsv_release() we do it
    with qgroup_to_release set, and thus do the proper accounting.
    
    The subvolume code is the only other code that uses the qgroup
    reservation stuff, but it's intermingled with the above optimization,
    and thus was getting its reservation freed out from underneath it and
    thus leaking the reserved space.
    
    The solution is to simply not mess with the qgroup reservations if we
    don't have qgroup_to_release set.  This works with the existing code as
    anything that messes with the delalloc reservations always have
    qgroup_to_release set.  This fixes the leak that Boris was observing.
    
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    CC: stable@vger.kernel.org # 5.4+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix btrfs_prev_leaf() to not return the same key twice [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Apr 12 11:33:09 2023 +0100

    btrfs: fix btrfs_prev_leaf() to not return the same key twice
    
    commit 6f932d4ef007d6a4ae03badcb749fbb8f49196f6 upstream.
    
    A call to btrfs_prev_leaf() may end up returning a path that points to the
    same item (key) again. This happens if while btrfs_prev_leaf(), after we
    release the path, a concurrent insertion happens, which moves items off
    from a sibling into the front of the previous leaf, and an item with the
    computed previous key does not exists.
    
    For example, suppose we have the two following leaves:
    
      Leaf A
    
      -------------------------------------------------------------
      | ...   key (300 96 10)   key (300 96 15)   key (300 96 16) |
      -------------------------------------------------------------
                  slot 20             slot 21             slot 22
    
      Leaf B
    
      -------------------------------------------------------------
      | key (300 96 20)   key (300 96 21)   key (300 96 22)   ... |
      -------------------------------------------------------------
          slot 0             slot 1             slot 2
    
    If we call btrfs_prev_leaf(), from btrfs_previous_item() for example, with
    a path pointing to leaf B and slot 0 and the following happens:
    
    1) At btrfs_prev_leaf() we compute the previous key to search as:
       (300 96 19), which is a key that does not exists in the tree;
    
    2) Then we call btrfs_release_path() at btrfs_prev_leaf();
    
    3) Some other task inserts a key at leaf A, that sorts before the key at
       slot 20, for example it has an objectid of 299. In order to make room
       for the new key, the key at slot 22 is moved to the front of leaf B.
       This happens at push_leaf_right(), called from split_leaf().
    
       After this leaf B now looks like:
    
      --------------------------------------------------------------------------------
      | key (300 96 16)    key (300 96 20)   key (300 96 21)   key (300 96 22)   ... |
      --------------------------------------------------------------------------------
           slot 0              slot 1             slot 2             slot 3
    
    4) At btrfs_prev_leaf() we call btrfs_search_slot() for the computed
       previous key: (300 96 19). Since the key does not exists,
       btrfs_search_slot() returns 1 and with a path pointing to leaf B
       and slot 1, the item with key (300 96 20);
    
    5) This makes btrfs_prev_leaf() return a path that points to slot 1 of
       leaf B, the same key as before it was called, since the key at slot 0
       of leaf B (300 96 16) is less than the computed previous key, which is
       (300 96 19);
    
    6) As a consequence btrfs_previous_item() returns a path that points again
       to the item with key (300 96 20).
    
    For some users of btrfs_prev_leaf() or btrfs_previous_item() this may not
    be functional a problem, despite not making sense to return a new path
    pointing again to the same item/key. However for a caller such as
    tree-log.c:log_dir_items(), this has a bad consequence, as it can result
    in not logging some dir index deletions in case the directory is being
    logged without holding the inode's VFS lock (logging triggered while
    logging a child inode for example) - for the example scenario above, in
    case the dir index keys 17, 18 and 19 were deleted in the current
    transaction.
    
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix encoded write i_size corruption with no-holes [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Fri Apr 28 14:02:11 2023 -0700

    btrfs: fix encoded write i_size corruption with no-holes
    
    commit e7db9e5c6b9615b287d01f0231904fbc1fbde9c5 upstream.
    
    We have observed a btrfs filesystem corruption on workloads using
    no-holes and encoded writes via send stream v2. The symptom is that a
    file appears to be truncated to the end of its last aligned extent, even
    though the final unaligned extent and even the file extent and otherwise
    correctly updated inode item have been written.
    
    So if we were writing out a 1MiB+X file via 8 128K extents and one
    extent of length X, i_size would be set to 1MiB, but the ninth extent,
    nbyte, etc. would all appear correct otherwise.
    
    The source of the race is a narrow (one line of code) window in which a
    no-holes fs has read in an updated i_size, but has not yet set a shared
    disk_i_size variable to write. Therefore, if two ordered extents run in
    parallel (par for the course for receive workloads), the following
    sequence can play out: (following "threads" a bit loosely, since there
    are callbacks involved for endio but extra threads aren't needed to
    cause the issue)
    
      ENC-WR1 (second to last)                                         ENC-WR2 (last)
      -------                                                          -------
      btrfs_do_encoded_write
        set i_size = 1M
        submit bio B1 ending at 1M
      endio B1
      btrfs_inode_safe_disk_i_size_write
        local i_size = 1M
        falls off a cliff for some reason
                                                                  btrfs_do_encoded_write
                                                                    set i_size = 1M+X
                                                                    submit bio B2 ending at 1M+X
                                                                  endio B2
                                                                  btrfs_inode_safe_disk_i_size_write
                                                                    local i_size = 1M+X
                                                                    disk_i_size = 1M+X
        disk_i_size = 1M
                                                                  btrfs_delayed_update_inode
        btrfs_delayed_update_inode
    
    And the delayed inode ends up filled with nbytes=1M+X and isize=1M, and
    writes respect i_size and present a corrupted file missing its last
    extents.
    
    Fix this by holding the inode lock in the no-holes case so that a thread
    can't sneak in a write to disk_i_size that gets overwritten with an out
    of date i_size.
    
    Fixes: 41a2ee75aab0 ("btrfs: introduce per-inode file extent tree")
    CC: stable@vger.kernel.org # 5.10+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix space cache inconsistency after error loading it from disk [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu May 4 12:04:18 2023 +0100

    btrfs: fix space cache inconsistency after error loading it from disk
    
    commit 0004ff15ea26015a0a3a6182dca3b9d1df32e2b7 upstream.
    
    When loading a free space cache from disk, at __load_free_space_cache(),
    if we fail to insert a bitmap entry, we still increment the number of
    total bitmaps in the btrfs_free_space_ctl structure, which is incorrect
    since we failed to add the bitmap entry. On error we then empty the
    cache by calling __btrfs_remove_free_space_cache(), which will result
    in getting the total bitmaps counter set to 1.
    
    A failure to load a free space cache is not critical, so if a failure
    happens we just rebuild the cache by scanning the extent tree, which
    happens at block-group.c:caching_thread(). Yet the failure will result
    in having the total bitmaps of the btrfs_free_space_ctl always bigger
    by 1 then the number of bitmap entries we have. So fix this by having
    the total bitmaps counter be incremented only if we successfully added
    the bitmap entry.
    
    Fixes: a67509c30079 ("Btrfs: add a io_ctl struct and helpers for dealing with the space cache")
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Filipe Manana <fdmanana@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>

btrfs: print-tree: parent bytenr must be aligned to sector size [+ + +]
Author: Anastasia Belova <abelova@astralinux.ru>
Date:   Wed Apr 26 14:53:23 2023 +0300

    btrfs: print-tree: parent bytenr must be aligned to sector size
    
    commit c87f318e6f47696b4040b58f460d5c17ea0280e6 upstream.
    
    Check nodesize to sectorsize in alignment check in print_extent_item.
    The comment states that and this is correct, similar check is done
    elsewhere in the functions.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: ea57788eb76d ("btrfs: require only sector size alignment for parent eb bytenr")
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: zero the buffer before marking it dirty in btrfs_redirty_list_add [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon May 8 07:58:37 2023 -0700

    btrfs: zero the buffer before marking it dirty in btrfs_redirty_list_add
    
    commit c83b56d1dd87cf67492bb770c26d6f87aee70ed6 upstream.
    
    btrfs_redirty_list_add zeroes the buffer data and sets the
    EXTENT_BUFFER_NO_CHECK to make sure writeback is fine with a bogus
    header.  But it does that after already marking the buffer dirty, which
    means that writeback could already be looking at the buffer.
    
    Switch the order of operations around so that the buffer is only marked
    dirty when we're ready to write it.
    
    Fixes: d3575156f662 ("btrfs: zoned: redirty released extent buffers")
    CC: stable@vger.kernel.org # 5.15+
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: zoned: fix wrong use of bitops API in btrfs_ensure_empty_zones [+ + +]
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Apr 18 17:45:24 2023 +0900

    btrfs: zoned: fix wrong use of bitops API in btrfs_ensure_empty_zones
    
    commit 631003e2333c12cc1b52df06a707365b7363a159 upstream.
    
    find_next_bit and find_next_zero_bit take @size as the second parameter and
    @offset as the third parameter. They are specified opposite in
    btrfs_ensure_empty_zones(). Thanks to the later loop, it never failed to
    detect the empty zones. Fix them and (maybe) return the result a bit
    faster.
    
    Note: the naming is a bit confusing, size has two meanings here, bitmap
    and our range size.
    
    Fixes: 1cd6121f2a38 ("btrfs: zoned: implement zoned chunk allocator")
    CC: stable@vger.kernel.org # 5.15+
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bus: mhi: host: Range check CHDBOFF and ERDBOFF [+ + +]
Author: Jeffrey Hugo <quic_jhugo@quicinc.com>
Date:   Fri Mar 24 10:13:04 2023 -0600

    bus: mhi: host: Range check CHDBOFF and ERDBOFF
    
    [ Upstream commit 6a0c637bfee69a74c104468544d9f2a6579626d0 ]
    
    If the value read from the CHDBOFF and ERDBOFF registers is outside the
    range of the MHI register space then an invalid address might be computed
    which later causes a kernel panic.  Range check the read value to prevent
    a crash due to bad data from the device.
    
    Fixes: 6cd330ae76ff ("bus: mhi: core: Add support for ringing channel/event ring doorbells")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
    Link: https://lore.kernel.org/r/1679674384-27209-1-git-send-email-quic_jhugo@quicinc.com
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bus: mhi: host: Remove duplicate ee check for syserr [+ + +]
Author: Jeffrey Hugo <quic_jhugo@quicinc.com>
Date:   Mon Apr 10 09:58:11 2023 -0600

    bus: mhi: host: Remove duplicate ee check for syserr
    
    [ Upstream commit d469d9448a0f1a33c175d3280b1542fa0158ad7a ]
    
    If we detect a system error via intvec, we only process the syserr if the
    current ee is different than the last observed ee.  The reason for this
    check is to prevent bhie from running multiple times, but with the single
    queue handling syserr, that is not possible.
    
    The check can cause an issue with device recovery.  If PBL loads a bad SBL
    via BHI, but that SBL hangs before notifying the host of an ee change,
    then issuing soc_reset to crash the device and retry (after supplying a
    fixed SBL) will not recover the device as the host will observe a PBL->PBL
    transition and not process the syserr.  The device will be stuck until
    either the driver is reloaded, or the host is rebooted.  Instead, remove
    the check so that we can attempt to recover the device.
    
    Fixes: ef2126c4e2ea ("bus: mhi: core: Process execution environment changes serially")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
    Link: https://lore.kernel.org/r/1681142292-27571-2-git-send-email-quic_jhugo@quicinc.com
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bus: mhi: host: Use mhi_tryset_pm_state() for setting fw error state [+ + +]
Author: Jeffrey Hugo <quic_jhugo@quicinc.com>
Date:   Mon Apr 10 09:58:12 2023 -0600

    bus: mhi: host: Use mhi_tryset_pm_state() for setting fw error state
    
    [ Upstream commit 1d1493bdc25f498468a606a4ece947d155cfa3a9 ]
    
    If firmware loading fails, the controller's pm_state is updated to
    MHI_PM_FW_DL_ERR unconditionally.  This can corrupt the pm_state as the
    update is not done under the proper lock, and also does not validate
    the state transition.  The firmware loading can fail due to a detected
    syserr, but if MHI_PM_FW_DL_ERR is unconditionally set as the pm_state,
    the handling of the syserr can break when it attempts to transition from
    syserr detect, to syserr process.
    
    By grabbing the lock, we ensure we don't race with some other pm_state
    update.  By using mhi_try_set_pm_state(), we check that the transition
    to MHI_PM_FW_DL_ERR is valid via the state machine logic.  If it is not
    valid, then some other transition is occurring like syserr processing, and
    we assume that will resolve the firmware loading error.
    
    Fixes: 12e050c77be0 ("bus: mhi: core: Move to an error state on any firmware load failure")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
    Link: https://lore.kernel.org/r/1681142292-27571-3-git-send-email-quic_jhugo@quicinc.com
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bus: mhi: Move host MHI code to "host" directory [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Tue Mar 1 21:33:02 2022 +0530

    bus: mhi: Move host MHI code to "host" directory
    
    [ Upstream commit a0f5a630668cb8b2ebf5204f08e957875e991780 ]
    
    In preparation of the endpoint MHI support, let's move the host MHI code
    to its own "host" directory and adjust the toplevel MHI Kconfig & Makefile.
    
    While at it, let's also move the "pci_generic" driver to "host" directory
    as it is a host MHI controller driver.
    
    Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20220301160308.107452-5-manivannan.sadhasivam@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: d469d9448a0f ("bus: mhi: host: Remove duplicate ee check for syserr")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: fix pcchunk length type in smb2_copychunk_range [+ + +]
Author: Pawel Witek <pawel.ireneusz.witek@gmail.com>
Date:   Fri May 5 17:14:59 2023 +0200

    cifs: fix pcchunk length type in smb2_copychunk_range
    
    commit d66cde50c3c868af7abddafce701bb86e4a93039 upstream.
    
    Change type of pcchunk->Length from u32 to u64 to match
    smb2_copychunk_range arguments type. Fixes the problem where performing
    server-side copy with CIFS_IOC_COPYCHUNK_FILE ioctl resulted in incomplete
    copy of large files while returning -EINVAL.
    
    Fixes: 9bf0c9cd4314 ("CIFS: Fix SMB2/SMB3 Copy offload support (refcopy) for large files")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Pawel Witek <pawel.ireneusz.witek@gmail.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cifs: release leases for deferred close handles when freezing [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Wed May 10 17:42:21 2023 -0500

    cifs: release leases for deferred close handles when freezing
    
    commit d39fc592ef8ae9a89c5e85c8d9f760937a57d5ba upstream.
    
    We should not be caching closed files when freeze is invoked on an fs
    (so we can release resources more gracefully).
    
    Fixes xfstests generic/068 generic/390 generic/491
    
    Reviewed-by: David Howells <dhowells@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
crypto: api - Add scaffolding to change completion function signature [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Jan 31 16:01:45 2023 +0800

    crypto: api - Add scaffolding to change completion function signature
    
    [ Upstream commit c35e03eaece71101ff6cbf776b86403860ac8cc3 ]
    
    The crypto completion function currently takes a pointer to a
    struct crypto_async_request object.  However, in reality the API
    does not allow the use of any part of the object apart from the
    data field.  For example, ahash/shash will create a fake object
    on the stack to pass along a different data field.
    
    This leads to potential bugs where the user may try to dereference
    or otherwise use the crypto_async_request object.
    
    This patch adds some temporary scaffolding so that the completion
    function can take a void * instead.  Once affected users have been
    converted this can be removed.
    
    The helper crypto_request_complete will remain even after the
    conversion is complete.  It should be used instead of calling
    the completion function directly.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: 4140aafcff16 ("crypto: engine - fix crypto_queue backlog handling")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: ccp - Clear PSP interrupt status register before calling handler [+ + +]
Author: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
Date:   Tue Mar 28 15:16:36 2023 +0000

    crypto: ccp - Clear PSP interrupt status register before calling handler
    
    [ Upstream commit 45121ad4a1750ca47ce3f32bd434bdb0cdbf0043 ]
    
    The PSP IRQ is edge-triggered (MSI or MSI-X) in all cases supported by
    the psp module so clear the interrupt status register early in the
    handler to prevent missed interrupts. sev_irq_handler() calls wake_up()
    on a wait queue, which can result in a new command being submitted from
    a different CPU. This then races with the clearing of isr and can result
    in missed interrupts. A missed interrupt results in a command waiting
    until it times out, which results in the psp being declared dead.
    
    This is unlikely on bare metal, but has been observed when running
    virtualized. In the cases where this is observed, sev->cmdresp_reg has
    PSP_CMDRESP_RESP set which indicates that the command was processed
    correctly but no interrupt was asserted.
    
    The full sequence of events looks like this:
    
    CPU 1: submits SEV cmd #1
    CPU 1: calls wait_event_timeout()
    CPU 0: enters psp_irq_handler()
    CPU 0: calls sev_handler()->wake_up()
    CPU 1: wakes up; finishes processing cmd #1
    CPU 1: submits SEV cmd #2
    CPU 1: calls wait_event_timeout()
    PSP:   finishes processing cmd #2; interrupt status is still set; no interrupt
    CPU 0: clears intsts
    CPU 0: exits psp_irq_handler()
    CPU 1: wait_event_timeout() times out; psp_dead=true
    
    Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
    Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: engine - check if BH is disabled during completion [+ + +]
Author: Corentin Labbe <clabbe@baylibre.com>
Date:   Mon Feb 21 12:08:33 2022 +0000

    crypto: engine - check if BH is disabled during completion
    
    [ Upstream commit 4058cf08945c18a6de193f4118fd05d83d3d4285 ]
    
    When doing iperf over ipsec with crypto hardware sun8i-ce, I hit some
    spinlock recursion bug.
    
    This is due to completion function called with enabled BH.
    
    Add check a to detect this.
    
    Fixes: 735d37b5424b ("crypto: engine - Introduce the block request crypto engine framework")
    Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: 4140aafcff16 ("crypto: engine - fix crypto_queue backlog handling")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: engine - fix crypto_queue backlog handling [+ + +]
Author: Olivier Bacon <olivierb89@gmail.com>
Date:   Thu Apr 20 11:00:35 2023 -0400

    crypto: engine - fix crypto_queue backlog handling
    
    [ Upstream commit 4140aafcff167b5b9e8dae6a1709a6de7cac6f74 ]
    
    CRYPTO_TFM_REQ_MAY_BACKLOG tells the crypto driver that it should
    internally backlog requests until the crypto hw's queue becomes
    full. At that point, crypto_engine backlogs the request and returns
    -EBUSY. Calling driver such as dm-crypt then waits until the
    complete() function is called with a status of -EINPROGRESS before
    sending a new request.
    
    The problem lies in the call to complete() with a value of -EINPROGRESS
    that is made when a backlog item is present on the queue. The call is
    done before the successful execution of the crypto request. In the case
    that do_one_request() returns < 0 and the retry support is available,
    the request is put back in the queue. This leads upper drivers to send
    a new request even if the queue is still full.
    
    The problem can be reproduced by doing a large dd into a crypto
    dm-crypt device. This is pretty easy to see when using
    Freescale CAAM crypto driver and SWIOTLB dma. Since the actual amount
    of requests that can be hold in the queue is unlimited we get IOs error
    and dma allocation.
    
    The fix is to call complete with a value of -EINPROGRESS only if
    the request is not enqueued back in crypto_queue. This is done
    by calling complete() later in the code. In order to delay the decision,
    crypto_queue is modified to correctly set the backlog pointer
    when a request is enqueued back.
    
    Fixes: 6a89f492f8e5 ("crypto: engine - support for parallel requests based on retry mechanism")
    Co-developed-by: Sylvain Ouellet <souellet@genetec.com>
    Signed-off-by: Sylvain Ouellet <souellet@genetec.com>
    Signed-off-by: Olivier Bacon <obacon@genetec.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: engine - Use crypto_request_complete [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Jan 31 16:02:02 2023 +0800

    crypto: engine - Use crypto_request_complete
    
    [ Upstream commit 6909823d47c17cba84e9244d04050b5db8d53789 ]
    
    Use the crypto_request_complete helper instead of calling the
    completion function directly.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: 4140aafcff16 ("crypto: engine - fix crypto_queue backlog handling")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sun8i-ss - Fix a test in sun8i_ss_setup_ivs() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Apr 17 22:25:09 2023 +0200

    crypto: sun8i-ss - Fix a test in sun8i_ss_setup_ivs()
    
    [ Upstream commit 8fd91151ebcb21b3f2f2bf158ac6092192550b2b ]
    
    SS_ENCRYPTION is (0 << 7 = 0), so the test can never be true.
    Use a direct comparison to SS_ENCRYPTION instead.
    
    The same king of test is already done the same way in sun8i_ss_run_task().
    
    Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drbd: correctly submit flush bio on barrier [+ + +]
Author: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
Date:   Wed May 3 14:19:37 2023 +0200

    drbd: correctly submit flush bio on barrier
    
    commit 3899d94e3831ee07ea6821c032dc297aec80586a upstream.
    
    When we receive a flush command (or "barrier" in DRBD), we currently use
    a REQ_OP_FLUSH with the REQ_PREFLUSH flag set.
    
    The correct way to submit a flush bio is by using a REQ_OP_WRITE without
    any data, and set the REQ_PREFLUSH flag.
    
    Since commit b4a6bb3a67aa ("block: add a sanity check for non-write
    flush/fua bios"), this triggers a warning in the block layer, but this
    has been broken for quite some time before that.
    
    So use the correct set of flags to actually make the flush happen.
    
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: stable@vger.kernel.org
    Fixes: f9ff0da56437 ("drbd: allow parallel flushes for multi-volume resources")
    Reported-by: Thomas Voegtle <tv@lio96.de>
    Signed-off-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20230503121937.17232-1-christoph.boehmwalder@linbit.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Add NULL plane_state check for cursor disable logic [+ + +]
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date:   Sat Mar 11 09:11:29 2023 -0500

    drm/amd/display: Add NULL plane_state check for cursor disable logic
    
    [ Upstream commit d29fb7baab09b6a1dc484c9c67933253883e770a ]
    
    [Why]
    While scanning the top_pipe connections we can run into a case where
    the bottom pipe is still connected to a top_pipe but with a NULL
    plane_state.
    
    [How]
    Treat a NULL plane_state the same as the plane being invisible for
    pipe cursor disable logic.
    
    Cc: stable@vger.kernel.org
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
    Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
    Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: fix flickering caused by S/G mode [+ + +]
Author: Hamza Mahfooz <hamza.mahfooz@amd.com>
Date:   Fri Apr 14 14:26:27 2023 -0400

    drm/amd/display: fix flickering caused by S/G mode
    
    commit 08da182175db4c7f80850354849d95f2670e8cd9 upstream.
    
    Currently, on a handful of ASICs. We allow the framebuffer for a given
    plane to exist in either VRAM or GTT. However, if the plane's new
    framebuffer is in a different memory domain than it's previous
    framebuffer, flipping between them can cause the screen to flicker. So,
    to fix this, don't perform an immediate flip in the aforementioned case.
    
    Cc: stable@vger.kernel.org
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2354
    Reviewed-by: Roman Li <Roman.Li@amd.com>
    Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)")
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Fix hang when skipping modeset [+ + +]
Author: Aurabindo Pillai <aurabindo.pillai@amd.com>
Date:   Fri Mar 24 10:42:37 2023 -0400

    drm/amd/display: Fix hang when skipping modeset
    
    commit da5e14909776edea4462672fb4a3007802d262e7 upstream.
    
    [Why&How]
    
    When skipping full modeset since the only state change was a front porch
    change, the DC commit sequence requires extra checks to handle non
    existant plane states being asked to be removed from context.
    
    Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com>
    Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
    Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Refine condition of cursor visibility for pipe-split [+ + +]
Author: Dale Zhao <dale.zhao@amd.com>
Date:   Mon Aug 23 16:44:37 2021 +0800

    drm/amd/display: Refine condition of cursor visibility for pipe-split
    
    [ Upstream commit 63f8bee439c0e3f94cff90d0f9c7b719be693265 ]
    
    [Why]
    In some scenarios like fullscreen game, major plane is scaled. Then
    if a upper layer owns the cursor, cursor is invisiable in the
    majority of the screen.
    
    [How]
    Instead assuming upper plane handles cursor, summing up upper
    split planes on the same layer. If whole upper plane covers current
    half/whole pipe plane, disable cursor.
    
    Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
    Acked-by: Mikita Lipski <mikita.lipski@amd.com>
    Signed-off-by: Dale Zhao <dale.zhao@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: d29fb7baab09 ("drm/amd/display: Add NULL plane_state check for cursor disable logic")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras [+ + +]
Author: Guchun Chen <guchun.chen@amd.com>
Date:   Sat May 6 20:06:45 2023 +0800

    drm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras
    
    commit 4a76680311330aefe5074bed8f06afa354b85c48 upstream.
    
    gfx9 cp_ecc_error_irq is only enabled when legacy gfx ras is assert.
    So in gfx_v9_0_hw_fini, interrupt disablement for cp_ecc_error_irq
    should be executed under such condition, otherwise, an amdgpu_irq_put
    calltrace will occur.
    
    [ 7283.170322] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]
    [ 7283.170964] RSP: 0018:ffff9a5fc3967d00 EFLAGS: 00010246
    [ 7283.170967] RAX: ffff98d88afd3040 RBX: ffff98d89da20000 RCX: 0000000000000000
    [ 7283.170969] RDX: 0000000000000000 RSI: ffff98d89da2bef8 RDI: ffff98d89da20000
    [ 7283.170971] RBP: ffff98d89da20000 R08: ffff98d89da2ca18 R09: 0000000000000006
    [ 7283.170973] R10: ffffd5764243c008 R11: 0000000000000000 R12: 0000000000001050
    [ 7283.170975] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105
    [ 7283.170978] FS:  0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000
    [ 7283.170981] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 7283.170983] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0
    [ 7283.170986] Call Trace:
    [ 7283.170988]  <TASK>
    [ 7283.170989]  gfx_v9_0_hw_fini+0x1c/0x6d0 [amdgpu]
    [ 7283.171655]  amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]
    [ 7283.172245]  amdgpu_device_suspend+0x103/0x180 [amdgpu]
    [ 7283.172823]  amdgpu_pmops_freeze+0x21/0x60 [amdgpu]
    [ 7283.173412]  pci_pm_freeze+0x54/0xc0
    [ 7283.173419]  ? __pfx_pci_pm_freeze+0x10/0x10
    [ 7283.173425]  dpm_run_callback+0x98/0x200
    [ 7283.173430]  __device_suspend+0x164/0x5f0
    
    v2: drop gfx11 as it's fixed in a different solution by retiring cp_ecc_irq funcs(Hawking)
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2522
    Signed-off-by: Guchun Chen <guchun.chen@amd.com>
    Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: add a missing lock for AMDGPU_SCHED [+ + +]
Author: Chia-I Wu <olvaffe@gmail.com>
Date:   Wed Apr 26 15:54:55 2023 -0700

    drm/amdgpu: add a missing lock for AMDGPU_SCHED
    
    [ Upstream commit 2397e3d8d2e120355201a8310b61929f5a8bd2c0 ]
    
    mgr->ctx_handles should be protected by mgr->lock.
    
    v2: improve commit message
    v3: add a Fixes tag
    
    Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Fixes: 52c6a62c64fa ("drm/amdgpu: add interface for editing a foreign process's priority v3")
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend [+ + +]
Author: Guchun Chen <guchun.chen@amd.com>
Date:   Sat May 6 16:52:59 2023 +0800

    drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend
    
    commit 8b229ada2669b74fdae06c83fbfda5a5a99fc253 upstream.
    
    sdma_v4_0_ip is shared on a few asics, but in sdma_v4_0_hw_fini,
    driver unconditionally disables ecc_irq which is only enabled on
    those asics enabling sdma ecc. This will introduce a warning in
    suspend cycle on those chips with sdma ip v4.0, while without
    sdma ecc. So this patch correct this.
    
    [ 7283.166354] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]
    [ 7283.167001] RSP: 0018:ffff9a5fc3967d08 EFLAGS: 00010246
    [ 7283.167019] RAX: ffff98d88afd3770 RBX: 0000000000000001 RCX: 0000000000000000
    [ 7283.167023] RDX: 0000000000000000 RSI: ffff98d89da30390 RDI: ffff98d89da20000
    [ 7283.167025] RBP: ffff98d89da20000 R08: 0000000000036838 R09: 0000000000000006
    [ 7283.167028] R10: ffffd5764243c008 R11: 0000000000000000 R12: ffff98d89da30390
    [ 7283.167030] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105
    [ 7283.167032] FS:  0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000
    [ 7283.167036] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 7283.167039] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0
    [ 7283.167041] Call Trace:
    [ 7283.167046]  <TASK>
    [ 7283.167048]  sdma_v4_0_hw_fini+0x38/0xa0 [amdgpu]
    [ 7283.167704]  amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]
    [ 7283.168296]  amdgpu_device_suspend+0x103/0x180 [amdgpu]
    [ 7283.168875]  amdgpu_pmops_freeze+0x21/0x60 [amdgpu]
    [ 7283.169464]  pci_pm_freeze+0x54/0xc0
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2522
    Signed-off-by: Guchun Chen <guchun.chen@amd.com>
    Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: fix an amdgpu_irq_put() issue in gmc_v9_0_hw_fini() [+ + +]
Author: Hamza Mahfooz <hamza.mahfooz@amd.com>
Date:   Tue May 2 11:59:08 2023 -0400

    drm/amdgpu: fix an amdgpu_irq_put() issue in gmc_v9_0_hw_fini()
    
    commit 922a76ba31adf84e72bc947267385be420c689ee upstream.
    
    As made mention of in commit 08c677cb0b43 ("drm/amdgpu: fix
    amdgpu_irq_put call trace in gmc_v10_0_hw_fini") and commit 13af556104fa
    ("drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini"). It
    is meaningless to call amdgpu_irq_put() for gmc.ecc_irq. So, remove it
    from gmc_v9_0_hw_fini().
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2522
    Fixes: 3029c855d79f ("drm/amdgpu: Fix desktop freezed after gpu-reset")
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: Fix vram recover doesn't work after whole GPU reset (v2) [+ + +]
Author: Lin.Cao <lincao12@amd.com>
Date:   Mon May 8 17:28:41 2023 +0800

    drm/amdgpu: Fix vram recover doesn't work after whole GPU reset (v2)
    
    commit 6c032c37ac3ef3b7df30937c785ecc4da428edc0 upstream.
    
    v1: Vmbo->shadow is used to back vram bo up when vram lost. So that we
    should set shadow as vmbo->shadow to recover vmbo->bo
    v2: Modify if(vmbo->shadow) shadow = vmbo->shadow as if(!vmbo->shadow)
    continue;
    
    Fixes: e18aaea733da ("drm/amdgpu: move shadow_list to amdgpu_bo_vm")
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Lin.Cao <lincao12@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/bridge: lt8912b: Fix DSI Video Mode [+ + +]
Author: Francesco Dolcini <francesco.dolcini@toradex.com>
Date:   Thu Mar 30 11:31:31 2023 +0200

    drm/bridge: lt8912b: Fix DSI Video Mode
    
    commit f435b7ef3b360d689df2ffa8326352cd07940d92 upstream.
    
    LT8912 DSI port supports only Non-Burst mode video operation with Sync
    Events and continuous clock on clock lane, correct dsi mode flags
    according to that removing MIPI_DSI_MODE_VIDEO_BURST flag.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230330093131.424828-1-francesco@dolcini.it
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/hyperv: Don't overwrite dirt_needed value set by host [+ + +]
Author: Saurabh Sengar <ssengar@linux.microsoft.com>
Date:   Fri Sep 23 10:09:50 2022 +0000

    drm/hyperv: Don't overwrite dirt_needed value set by host
    
    [ Upstream commit 19b5e6659eaf537ebeac90ae30c7df0296fe5ab9 ]
    
    Existing code is causing a race condition where dirt_needed value is
    already set by the host and gets overwritten with default value. Remove
    this default setting of dirt_needed, to avoid overwriting the value
    received in the channel callback set by vmbus_open. Removing this
    setting also means the default value for dirt_needed is changed to false
    as it's allocated by kzalloc which is similar to legacy hyperv_fb driver.
    
    Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Reviewed-by: Michael Kelley <mikelley@microsoft.com>
    Link: https://lore.kernel.org/r/1662996766-19304-1-git-send-email-ssengar@linux.microsoft.com
    Signed-off-by: Wei Liu <wei.liu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/dg2: Add additional HDMI pixel clock frequencies [+ + +]
Author: Taylor, Clinton A <clinton.a.taylor@intel.com>
Date:   Mon Aug 1 16:48:56 2022 -0700

    drm/i915/dg2: Add additional HDMI pixel clock frequencies
    
    [ Upstream commit 11c7faa61d136cef92506e4e77d0e6c6e01428bc ]
    
    Using the BSPEC algorithm add addition HDMI pixel clocks to the existing
    table.
    
    v2: remove 297000 unused entry
    
    Cc: Matt Roper <matthew.d.roper@intel.com>
    Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
    Signed-off-by: Taylor, Clinton A <clinton.a.taylor@intel.com>
    Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
    [mattrope: Fixed minor whitepsace issue flagged by checkpatch]
    Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220801234856.2832317-1-clinton.a.taylor@intel.com
    Stable-dep-of: d46746b8b13c ("drm/i915/dg2: Add HDMI pixel clock frequencies 267.30 and 319.89 MHz")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/i915/dg2: Add HDMI pixel clock frequencies 267.30 and 319.89 MHz [+ + +]
Author: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Date:   Thu Feb 23 10:06:19 2023 +0530

    drm/i915/dg2: Add HDMI pixel clock frequencies 267.30 and 319.89 MHz
    
    [ Upstream commit d46746b8b13cbd377ffc733e465d25800459a31b ]
    
    Add snps phy table values for HDMI pixel clocks 267.30 MHz and
    319.89 MHz. Values are based on the Bspec algorithm for
    PLL programming for HDMI.
    
    Cc: stable@vger.kernel.org
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8008
    Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
    Reviewed-by: Uma Shankar <uma.shankar@intel.com>
    Signed-off-by: Uma Shankar <uma.shankar@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230223043619.3941382-1-ankit.k.nautiyal@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/i915/dg2: Support 4k@30 on HDMI [+ + +]
Author: Vandita Kulkarni <vandita.kulkarni@intel.com>
Date:   Wed May 25 13:34:01 2022 +0530

    drm/i915/dg2: Support 4k@30 on HDMI
    
    [ Upstream commit edd34368c4c3b45b1386b15f78b2229420f8c6d4 ]
    
    This patch adds a fix to support 297MHz of dot clock by calculating
    the pll values using synopsis algorithm.
    This will help to support 4k@30 mode for HDMI monitors on DG2.
    
    v2: As per the algorithm, set MPLLB VCO range control bits to 3,
    in register SNPS_PHY_MPLLB_DIV for 297Mhz. (Matt)
    
    v3: Fix typo. (Ankit)
    
    Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
    Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
    Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
    Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220525080401.1253511-1-ankit.k.nautiyal@intel.com
    Stable-dep-of: d46746b8b13c ("drm/i915/dg2: Add HDMI pixel clock frequencies 267.30 and 319.89 MHz")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/adreno: adreno_gpu: Use suspend() instead of idle() on load error [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Mar 31 01:15:16 2023 +0200

    drm/msm/adreno: adreno_gpu: Use suspend() instead of idle() on load error
    
    commit 3eeca5e5f3100435b06a5b5d86daa3d135a8a4bd upstream.
    
    The adreno_load_gpu() path is guarded by an error check on
    adreno_load_fw(). This function is responsible for loading
    Qualcomm-only-signed binaries (e.g. SQE and GMU FW for A6XX), but it
    does not take the vendor-signed ZAP blob into account.
    
    By embedding the SQE (and GMU, if necessary) firmware into the
    initrd/kernel, we can trigger and unfortunate path that would not bail
    out early and proceed with gpu->hw_init(). That will fail, as the ZAP
    loader path will not find the firmware and return back to
    adreno_load_gpu().
    
    This error path involves pm_runtime_put_sync() which then calls idle()
    instead of suspend(). This is suboptimal, as it means that we're not
    going through the clean shutdown sequence. With at least A619_holi, this
    makes the GPU not wake up until it goes through at least one more
    start-fail-stop cycle. The pm_runtime_put_sync that appears in the error
    path actually does not guarantee that because of the earlier enabling of
    runtime autosuspend.
    
    Fix that by using pm_runtime_put_sync_suspend to force a clean shutdown.
    
    Test cases:
    1. All firmware baked into kernel
    2. error loading ZAP fw in initrd -> load from rootfs at DE start
    
    Both succeed on A619_holi (SM6375) and A630 (SDM845).
    
    Fixes: 0d997f95b70f ("drm/msm/adreno: fix runtime PM imbalance at gpu load")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Patchwork: https://patchwork.freedesktop.org/patch/530001/
    Link: https://lore.kernel.org/r/20230330231517.2747024-1-konrad.dybcio@linaro.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/msm/adreno: fix runtime PM imbalance at gpu load [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Mar 3 17:48:05 2023 +0100

    drm/msm/adreno: fix runtime PM imbalance at gpu load
    
    [ Upstream commit 0d997f95b70f98987ae031a89677c13e0e223670 ]
    
    A recent commit moved enabling of runtime PM to GPU load time (first
    open()) but failed to update the error paths so that runtime PM is
    disabled if initialisation of the GPU fails. This would trigger a
    warning about the unbalanced disable count on the next open() attempt.
    
    Note that pm_runtime_put_noidle() is sufficient to balance the usage
    count when pm_runtime_put_sync() fails (and is chosen over
    pm_runtime_resume_and_get() for consistency reasons).
    
    Fixes: 4b18299b3365 ("drm/msm/adreno: Defer enabling runpm until hw_init()")
    Cc: stable@vger.kernel.org      # 6.0
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Patchwork: https://patchwork.freedesktop.org/patch/524971/
    Link: https://lore.kernel.org/r/20230303164807.13124-3-johan+linaro@kernel.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm: fix NULL-deref on irq uninstall [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 11:07:16 2023 +0100

    drm/msm: fix NULL-deref on irq uninstall
    
    commit cd459c005de3e2b855a8cc7768e633ce9d018e9f upstream.
    
    In case of early initialisation errors and on platforms that do not use
    the DPU controller, the deinitilisation code can be called with the kms
    pointer set to NULL.
    
    Fixes: f026e431cf86 ("drm/msm: Convert to Linux IRQ interfaces")
    Cc: stable@vger.kernel.org      # 5.14
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/525104/
    Link: https://lore.kernel.org/r/20230306100722.28485-5-johan+linaro@kernel.org
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/msm: fix NULL-deref on snapshot tear down [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Mar 6 11:07:15 2023 +0100

    drm/msm: fix NULL-deref on snapshot tear down
    
    commit a465353b9250802f87b97123e33a17f51277f0b1 upstream.
    
    In case of early initialisation errors and on platforms that do not use
    the DPU controller, the deinitilisation code can be called with the kms
    pointer set to NULL.
    
    Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot")
    Cc: stable@vger.kernel.org      # 5.14
    Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/525099/
    Link: https://lore.kernel.org/r/20230306100722.28485-4-johan+linaro@kernel.org
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/msm: Remove struct_mutex usage [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Tue Nov 9 10:11:03 2021 -0800

    drm/msm: Remove struct_mutex usage
    
    [ Upstream commit c28e2f2b417ed747bfbc5f900c87f3ec9cc6b25e ]
    
    The remaining struct_mutex usage is just to serialize various gpu
    related things (submit/retire/recover/fault/etc), so replace
    struct_mutex with gpu->lock.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Link: https://lore.kernel.org/r/20211109181117.591148-4-robdclark@gmail.com
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Stable-dep-of: 0d997f95b70f ("drm/msm/adreno: fix runtime PM imbalance at gpu load")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/panel: otm8009a: Set backlight parent to panel device [+ + +]
Author: James Cowgill <james.cowgill@blaize.com>
Date:   Wed Apr 12 17:35:07 2023 +0000

    drm/panel: otm8009a: Set backlight parent to panel device
    
    commit ab4f869fba6119997f7630d600049762a2b014fa upstream.
    
    This is the logical place to put the backlight device, and it also
    fixes a kernel crash if the MIPI host is removed. Previously the
    backlight device would be unregistered twice when this happened - once
    as a child of the MIPI host through `mipi_dsi_host_unregister`, and
    once when the panel device is destroyed.
    
    Fixes: 12a6cbd4f3f1 ("drm/panel: otm8009a: Use new backlight API")
    Signed-off-by: James Cowgill <james.cowgill@blaize.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230412173450.199592-1-james.cowgill@blaize.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ethtool: Fix uninitialized number of lanes [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Tue May 2 15:20:50 2023 +0300

    ethtool: Fix uninitialized number of lanes
    
    [ Upstream commit 9ad685dbfe7e856bbf17a7177b64676d324d6ed7 ]
    
    It is not possible to set the number of lanes when setting link modes
    using the legacy IOCTL ethtool interface. Since 'struct
    ethtool_link_ksettings' is not initialized in this path, drivers receive
    an uninitialized number of lanes in 'struct
    ethtool_link_ksettings::lanes'.
    
    When this information is later queried from drivers, it results in the
    ethtool code making decisions based on uninitialized memory, leading to
    the following KMSAN splat [1]. In practice, this most likely only
    happens with the tun driver that simply returns whatever it got in the
    set operation.
    
    As far as I can tell, this uninitialized memory is not leaked to user
    space thanks to the 'ethtool_ops->cap_link_lanes_supported' check in
    linkmodes_prepare_data().
    
    Fix by initializing the structure in the IOCTL path. Did not find any
    more call sites that pass an uninitialized structure when calling
    'ethtool_ops::set_link_ksettings()'.
    
    [1]
    BUG: KMSAN: uninit-value in ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline]
    BUG: KMSAN: uninit-value in ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333
     ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline]
     ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333
     ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640
     genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]
     genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
     genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065
     netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577
     genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076
     netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
     netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365
     netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942
     sock_sendmsg_nosec net/socket.c:724 [inline]
     sock_sendmsg net/socket.c:747 [inline]
     ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501
     ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555
     __sys_sendmsg net/socket.c:2584 [inline]
     __do_sys_sendmsg net/socket.c:2593 [inline]
     __se_sys_sendmsg net/socket.c:2591 [inline]
     __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Uninit was stored to memory at:
     tun_get_link_ksettings+0x37/0x60 drivers/net/tun.c:3544
     __ethtool_get_link_ksettings+0x17b/0x260 net/ethtool/ioctl.c:441
     ethnl_set_linkmodes+0xee/0x19d0 net/ethtool/linkmodes.c:327
     ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640
     genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]
     genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
     genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065
     netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577
     genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076
     netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
     netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365
     netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942
     sock_sendmsg_nosec net/socket.c:724 [inline]
     sock_sendmsg net/socket.c:747 [inline]
     ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501
     ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555
     __sys_sendmsg net/socket.c:2584 [inline]
     __do_sys_sendmsg net/socket.c:2593 [inline]
     __se_sys_sendmsg net/socket.c:2591 [inline]
     __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Uninit was stored to memory at:
     tun_set_link_ksettings+0x37/0x60 drivers/net/tun.c:3553
     ethtool_set_link_ksettings+0x600/0x690 net/ethtool/ioctl.c:609
     __dev_ethtool net/ethtool/ioctl.c:3024 [inline]
     dev_ethtool+0x1db9/0x2a70 net/ethtool/ioctl.c:3078
     dev_ioctl+0xb07/0x1270 net/core/dev_ioctl.c:524
     sock_do_ioctl+0x295/0x540 net/socket.c:1213
     sock_ioctl+0x729/0xd90 net/socket.c:1316
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:870 [inline]
     __se_sys_ioctl+0x222/0x400 fs/ioctl.c:856
     __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:856
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Local variable link_ksettings created at:
     ethtool_set_link_ksettings+0x54/0x690 net/ethtool/ioctl.c:577
     __dev_ethtool net/ethtool/ioctl.c:3024 [inline]
     dev_ethtool+0x1db9/0x2a70 net/ethtool/ioctl.c:3078
    
    Fixes: 012ce4dd3102 ("ethtool: Extend link modes settings uAPI with lanes")
    Reported-and-tested-by: syzbot+ef6edd9f1baaa54d6235@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/netdev/0000000000004bb41105fa70f361@google.com/
    Reviewed-by: Danielle Ratson <danieller@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: add bounds checking in get_max_inline_xattr_value_size() [+ + +]
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri May 12 15:11:02 2023 -0400

    ext4: add bounds checking in get_max_inline_xattr_value_size()
    
    commit 2220eaf90992c11d888fe771055d4de330385f01 upstream.
    
    Normally the extended attributes in the inode body would have been
    checked when the inode is first opened, but if someone is writing to
    the block device while the file system is mounted, it's possible for
    the inode table to get corrupted.  Add bounds checking to avoid
    reading beyond the end of allocated memory if this happens.
    
    Reported-by: syzbot+1966db24521e5f6e23f7@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?extid=1966db24521e5f6e23f7
    Cc: stable@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: avoid a potential slab-out-of-bounds in ext4_group_desc_csum [+ + +]
Author: Tudor Ambarus <tudor.ambarus@linaro.org>
Date:   Thu May 4 12:15:25 2023 +0000

    ext4: avoid a potential slab-out-of-bounds in ext4_group_desc_csum
    
    commit 4f04351888a83e595571de672e0a4a8b74f4fb31 upstream.
    
    When modifying the block device while it is mounted by the filesystem,
    syzbot reported the following:
    
    BUG: KASAN: slab-out-of-bounds in crc16+0x206/0x280 lib/crc16.c:58
    Read of size 1 at addr ffff888075f5c0a8 by task syz-executor.2/15586
    
    CPU: 1 PID: 15586 Comm: syz-executor.2 Not tainted 6.2.0-rc5-syzkaller-00205-gc96618275234 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106
     print_address_description+0x74/0x340 mm/kasan/report.c:306
     print_report+0x107/0x1f0 mm/kasan/report.c:417
     kasan_report+0xcd/0x100 mm/kasan/report.c:517
     crc16+0x206/0x280 lib/crc16.c:58
     ext4_group_desc_csum+0x81b/0xb20 fs/ext4/super.c:3187
     ext4_group_desc_csum_set+0x195/0x230 fs/ext4/super.c:3210
     ext4_mb_clear_bb fs/ext4/mballoc.c:6027 [inline]
     ext4_free_blocks+0x191a/0x2810 fs/ext4/mballoc.c:6173
     ext4_remove_blocks fs/ext4/extents.c:2527 [inline]
     ext4_ext_rm_leaf fs/ext4/extents.c:2710 [inline]
     ext4_ext_remove_space+0x24ef/0x46a0 fs/ext4/extents.c:2958
     ext4_ext_truncate+0x177/0x220 fs/ext4/extents.c:4416
     ext4_truncate+0xa6a/0xea0 fs/ext4/inode.c:4342
     ext4_setattr+0x10c8/0x1930 fs/ext4/inode.c:5622
     notify_change+0xe50/0x1100 fs/attr.c:482
     do_truncate+0x200/0x2f0 fs/open.c:65
     handle_truncate fs/namei.c:3216 [inline]
     do_open fs/namei.c:3561 [inline]
     path_openat+0x272b/0x2dd0 fs/namei.c:3714
     do_filp_open+0x264/0x4f0 fs/namei.c:3741
     do_sys_openat2+0x124/0x4e0 fs/open.c:1310
     do_sys_open fs/open.c:1326 [inline]
     __do_sys_creat fs/open.c:1402 [inline]
     __se_sys_creat fs/open.c:1396 [inline]
     __x64_sys_creat+0x11f/0x160 fs/open.c:1396
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7f72f8a8c0c9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f72f97e3168 EFLAGS: 00000246 ORIG_RAX: 0000000000000055
    RAX: ffffffffffffffda RBX: 00007f72f8bac050 RCX: 00007f72f8a8c0c9
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000280
    RBP: 00007f72f8ae7ae9 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007ffd165348bf R14: 00007f72f97e3300 R15: 0000000000022000
    
    Replace
            le16_to_cpu(sbi->s_es->s_desc_size)
    with
            sbi->s_desc_size
    
    It reduces ext4's compiled text size, and makes the code more efficient
    (we remove an extra indirect reference and a potential byte
    swap on big endian systems), and there is no downside. It also avoids the
    potential KASAN / syzkaller failure, as a bonus.
    
    Reported-by: syzbot+fc51227e7100c9294894@syzkaller.appspotmail.com
    Reported-by: syzbot+8785e41224a3afd04321@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=70d28d11ab14bd7938f3e088365252aa923cff42
    Link: https://syzkaller.appspot.com/bug?id=b85721b38583ecc6b5e72ff524c67302abbc30f3
    Link: https://lore.kernel.org/all/000000000000ece18705f3b20934@google.com/
    Fixes: 717d50e4971b ("Ext4: Uninitialized Block Groups")
    Cc: stable@vger.kernel.org
    Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
    Link: https://lore.kernel.org/r/20230504121525.3275886-1-tudor.ambarus@linaro.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: bail out of ext4_xattr_ibody_get() fails for any reason [+ + +]
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri May 12 15:16:27 2023 -0400

    ext4: bail out of ext4_xattr_ibody_get() fails for any reason
    
    commit 2a534e1d0d1591e951f9ece2fb460b2ff92edabd upstream.
    
    In ext4_update_inline_data(), if ext4_xattr_ibody_get() fails for any
    reason, it's best if we just fail as opposed to stumbling on,
    especially if the failure is EFSCORRUPTED.
    
    Cc: stable@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: check iomap type only if ext4_iomap_begin() does not fail [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Fri May 5 21:24:29 2023 +0800

    ext4: check iomap type only if ext4_iomap_begin() does not fail
    
    commit fa83c34e3e56b3c672af38059e066242655271b1 upstream.
    
    When ext4_iomap_overwrite_begin() calls ext4_iomap_begin() map blocks may
    fail for some reason (e.g. memory allocation failure, bare disk write), and
    later because "iomap->type ! = IOMAP_MAPPED" triggers WARN_ON(). When ext4
    iomap_begin() returns an error, it is normal that the type of iomap->type
    may not match the expectation. Therefore, we only determine if iomap->type
    is as expected when ext4_iomap_begin() is executed successfully.
    
    Cc: stable@kernel.org
    Reported-by: syzbot+08106c4b7d60702dbc14@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/all/00000000000015760b05f9b4eee9@google.com
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230505132429.714648-1-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix data races when using cached status extents [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Thu May 4 14:55:24 2023 +0200

    ext4: fix data races when using cached status extents
    
    commit 492888df0c7b42fc0843631168b0021bc4caee84 upstream.
    
    When using cached extent stored in extent status tree in tree->cache_es
    another process holding ei->i_es_lock for reading can be racing with us
    setting new value of tree->cache_es. If the compiler would decide to
    refetch tree->cache_es at an unfortunate moment, it could result in a
    bogus in_range() check. Fix the possible race by using READ_ONCE() when
    using tree->cache_es only under ei->i_es_lock for reading.
    
    Cc: stable@kernel.org
    Reported-by: syzbot+4a03518df1e31b537066@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/all/000000000000d3b33905fa0fd4a6@google.com
    Suggested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230504125524.10802-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix deadlock when converting an inline directory in nojournal mode [+ + +]
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat May 6 21:04:01 2023 -0400

    ext4: fix deadlock when converting an inline directory in nojournal mode
    
    commit f4ce24f54d9cca4f09a395f3eecce20d6bec4663 upstream.
    
    In no journal mode, ext4_finish_convert_inline_dir() can self-deadlock
    by calling ext4_handle_dirty_dirblock() when it already has taken the
    directory lock.  There is a similar self-deadlock in
    ext4_incvert_inline_data_nolock() for data files which we'll fix at
    the same time.
    
    A simple reproducer demonstrating the problem:
    
        mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64
        mount -t ext4 -o dirsync /dev/vdc /vdc
        cd /vdc
        mkdir file0
        cd file0
        touch file0
        touch file1
        attr -s BurnSpaceInEA -V abcde .
        touch supercalifragilisticexpialidocious
    
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20230507021608.1290720-1-tytso@mit.edu
    Reported-by: syzbot+91dccab7c64e2850a4e5@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=ba84cc80a9491d65416bc7877e1650c87530fe8a
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix invalid free tracking in ext4_xattr_move_to_block() [+ + +]
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Apr 30 03:04:13 2023 -0400

    ext4: fix invalid free tracking in ext4_xattr_move_to_block()
    
    commit b87c7cdf2bed4928b899e1ce91ef0d147017ba45 upstream.
    
    In ext4_xattr_move_to_block(), the value of the extended attribute
    which we need to move to an external block may be allocated by
    kvmalloc() if the value is stored in an external inode.  So at the end
    of the function the code tried to check if this was the case by
    testing entry->e_value_inum.
    
    However, at this point, the pointer to the xattr entry is no longer
    valid, because it was removed from the original location where it had
    been stored.  So we could end up calling kvfree() on a pointer which
    was not allocated by kvmalloc(); or we could also potentially leak
    memory by not freeing the buffer when it should be freed.  Fix this by
    storing whether it should be freed in a separate variable.
    
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20230430160426.581366-1-tytso@mit.edu
    Link: https://syzkaller.appspot.com/bug?id=5c2aee8256e30b55ccf57312c16d88417adbd5e1
    Link: https://syzkaller.appspot.com/bug?id=41a6b5d4917c0412eb3b3c3c604965bed7d7420b
    Reported-by: syzbot+64b645917ce07d89bde5@syzkaller.appspotmail.com
    Reported-by: syzbot+0d042627c4f2ad332195@syzkaller.appspotmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix WARNING in mb_find_extent [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Mon Jan 16 10:00:15 2023 +0800

    ext4: fix WARNING in mb_find_extent
    
    commit fa08a7b61dff8a4df11ff1e84abfc214b487caf7 upstream.
    
    Syzbot found the following issue:
    
    EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!
    EXT4-fs (loop0): orphan cleanup on readonly fs
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30
    Modules linked in:
    CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    RIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869
    RSP: 0018:ffffc90003c9e098 EFLAGS: 00010293
    RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0
    RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040
    RBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402
    R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000
    R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc
    FS:  0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     ext4_mb_complex_scan_group+0x353/0x1100 fs/ext4/mballoc.c:2307
     ext4_mb_regular_allocator+0x1533/0x3860 fs/ext4/mballoc.c:2735
     ext4_mb_new_blocks+0xddf/0x3db0 fs/ext4/mballoc.c:5605
     ext4_ext_map_blocks+0x1868/0x6880 fs/ext4/extents.c:4286
     ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651
     ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864
     ext4_bread+0x2a/0x170 fs/ext4/inode.c:920
     ext4_quota_write+0x225/0x570 fs/ext4/super.c:7105
     write_blk fs/quota/quota_tree.c:64 [inline]
     get_free_dqblk+0x34a/0x6d0 fs/quota/quota_tree.c:130
     do_insert_tree+0x26b/0x1aa0 fs/quota/quota_tree.c:340
     do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
     do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
     do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
     dq_insert_tree fs/quota/quota_tree.c:401 [inline]
     qtree_write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420
     v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358
     dquot_acquire+0x348/0x670 fs/quota/dquot.c:444
     ext4_acquire_dquot+0x2dc/0x400 fs/ext4/super.c:6740
     dqget+0x999/0xdc0 fs/quota/dquot.c:914
     __dquot_initialize+0x3d0/0xcf0 fs/quota/dquot.c:1492
     ext4_process_orphan+0x57/0x2d0 fs/ext4/orphan.c:329
     ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474
     __ext4_fill_super fs/ext4/super.c:5516 [inline]
     ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644
     get_tree_bdev+0x400/0x620 fs/super.c:1282
     vfs_get_tree+0x88/0x270 fs/super.c:1489
     do_new_mount+0x289/0xad0 fs/namespace.c:3145
     do_mount fs/namespace.c:3488 [inline]
     __do_sys_mount fs/namespace.c:3697 [inline]
     __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Add some debug information:
    mb_find_extent: mb_find_extent block=41, order=0 needed=64 next=0 ex=0/41/1@3735929054 64 64 7
    block_bitmap: ff 3f 0c 00 fc 01 00 00 d2 3d 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    
    Acctually, blocks per group is 64, but block bitmap indicate at least has
    128 blocks. Now, ext4_validate_block_bitmap() didn't check invalid block's
    bitmap if set.
    To resolve above issue, add check like fsck "Padding at end of block bitmap is
    not set".
    
    Cc: stable@kernel.org
    Reported-by: syzbot+68223fe9f6c95ad43bed@syzkaller.appspotmail.com
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230116020015.1506120-1-yebin@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: improve error handling from ext4_dirhash() [+ + +]
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat May 6 11:59:13 2023 -0400

    ext4: improve error handling from ext4_dirhash()
    
    commit 4b3cb1d108bfc2aebb0d7c8a52261a53cf7f5786 upstream.
    
    The ext4_dirhash() will *almost* never fail, especially when the hash
    tree feature was first introduced.  However, with the addition of
    support of encrypted, casefolded file names, that function can most
    certainly fail today.
    
    So make sure the callers of ext4_dirhash() properly check for
    failures, and reflect the errors back up to their callers.
    
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20230506142419.984260-1-tytso@mit.edu
    Reported-by: syzbot+394aa8a792cb99dbc837@syzkaller.appspotmail.com
    Reported-by: syzbot+344aaa8697ebd232bfc8@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=db56459ea4ac4a676ae4b4678f633e55da005a9b
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: improve error recovery code paths in __ext4_remount() [+ + +]
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri May 5 22:20:29 2023 -0400

    ext4: improve error recovery code paths in __ext4_remount()
    
    commit 4c0b4818b1f636bc96359f7817a2d8bab6370162 upstream.
    
    If there are failures while changing the mount options in
    __ext4_remount(), we need to restore the old mount options.
    
    This commit fixes two problem.  The first is there is a chance that we
    will free the old quota file names before a potential failure leading
    to a use-after-free.  The second problem addressed in this commit is
    if there is a failed read/write to read-only transition, if the quota
    has already been suspended, we need to renable quota handling.
    
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20230506142419.984260-2-tytso@mit.edu
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: remove a BUG_ON in ext4_mb_release_group_pa() [+ + +]
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Apr 29 16:14:46 2023 -0400

    ext4: remove a BUG_ON in ext4_mb_release_group_pa()
    
    commit 463808f237cf73e98a1a45ff7460c2406a150a0b upstream.
    
    If a malicious fuzzer overwrites the ext4 superblock while it is
    mounted such that the s_first_data_block is set to a very large
    number, the calculation of the block group can underflow, and trigger
    a BUG_ON check.  Change this to be an ext4_warning so that we don't
    crash the kernel.
    
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20230430154311.579720-3-tytso@mit.edu
    Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
f2fs: fix potential corruption when moving a directory [+ + +]
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Thu Apr 6 11:18:48 2023 -0700

    f2fs: fix potential corruption when moving a directory
    
    commit d94772154e524b329a168678836745d2773a6e02 upstream.
    
    F2FS has the same issue in ext4_rename causing crash revealed by
    xfstests/generic/707.
    
    See also commit 0813299c586b ("ext4: Fix possible corruption when moving a directory")
    
    CC: stable@vger.kernel.org
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fs/ntfs3: Fix null-ptr-deref on inode->i_op in ntfs_lookup() [+ + +]
Author: ZhangPeng <zhangpeng362@huawei.com>
Date:   Fri Nov 25 10:21:59 2022 +0000

    fs/ntfs3: Fix null-ptr-deref on inode->i_op in ntfs_lookup()
    
    [ Upstream commit 254e69f284d7270e0abdc023ee53b71401c3ba0c ]
    
    Syzbot reported a null-ptr-deref bug:
    
    ntfs3: loop0: Different NTFS' sector size (1024) and media sector size
    (512)
    ntfs3: loop0: Mark volume as dirty due to NTFS errors
    general protection fault, probably for non-canonical address
    0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
    RIP: 0010:d_flags_for_inode fs/dcache.c:1980 [inline]
    RIP: 0010:__d_add+0x5ce/0x800 fs/dcache.c:2796
    Call Trace:
     <TASK>
     d_splice_alias+0x122/0x3b0 fs/dcache.c:3191
     lookup_open fs/namei.c:3391 [inline]
     open_last_lookups fs/namei.c:3481 [inline]
     path_openat+0x10e6/0x2df0 fs/namei.c:3688
     do_filp_open+0x264/0x4f0 fs/namei.c:3718
     do_sys_openat2+0x124/0x4e0 fs/open.c:1310
     do_sys_open fs/open.c:1326 [inline]
     __do_sys_open fs/open.c:1334 [inline]
     __se_sys_open fs/open.c:1330 [inline]
     __x64_sys_open+0x221/0x270 fs/open.c:1330
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    If the MFT record of ntfs inode is not a base record, inode->i_op can be
    NULL. And a null-ptr-deref may happen:
    
    ntfs_lookup()
        dir_search_u() # inode->i_op is set to NULL
        d_splice_alias()
            __d_add()
                d_flags_for_inode() # inode->i_op->get_link null-ptr-deref
    
    Fix this by adding a Check on inode->i_op before calling the
    d_splice_alias() function.
    
    Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation")
    Reported-by: syzbot+a8f26a403c169b7593fe@syzkaller.appspotmail.com
    Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Refactoring of various minor issues [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Dec 30 14:58:25 2022 +0400

    fs/ntfs3: Refactoring of various minor issues
    
    commit 6827d50b2c430c329af442b64c9176d174f56521 upstream.
    
    Removed unused macro.
    Changed null pointer checking.
    Fixed inconsistent indenting.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Cc: Rudi Heitbaum <rudi@heitbaum.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
HID: wacom: insert timestamp to packed Bluetooth (BT) events [+ + +]
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Fri Feb 24 08:26:43 2023 -0800

    HID: wacom: insert timestamp to packed Bluetooth (BT) events
    
    commit 17d793f3ed53080dab6bbeabfc82de890c901001 upstream.
    
    To fully utilize the BT polling/refresh rate, a few input events
    are sent together to reduce event delay. This causes issue to the
    timestamp generated by input_sync since all the events in the same
    packet would pretty much have the same timestamp. This patch inserts
    time interval to the events by averaging the total time used for
    sending the packet.
    
    This decision was mainly based on observing the actual time interval
    between each BT polling. The interval doesn't seem to be constant,
    due to the network and system environment. So, using solutions other
    than averaging doesn't end up with valid timestamps.
    
    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
    Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: wacom: Set a default resolution for older tablets [+ + +]
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Sun Apr 9 09:42:29 2023 -0700

    HID: wacom: Set a default resolution for older tablets
    
    commit 08a46b4190d345544d04ce4fe2e1844b772b8535 upstream.
    
    Some older tablets may not report physical maximum for X/Y
    coordinates. Set a default to prevent undefined resolution.
    
    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
    Link: https://lore.kernel.org/r/20230409164229.29777-1-ping.cheng@wacom.com
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
inotify: Avoid reporting event with invalid wd [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Mon Apr 24 18:32:19 2023 +0200

    inotify: Avoid reporting event with invalid wd
    
    commit c915d8f5918bea7c3962b09b8884ca128bfd9b0c upstream.
    
    When inotify_freeing_mark() races with inotify_handle_inode_event() it
    can happen that inotify_handle_inode_event() sees that i_mark->wd got
    already reset to -1 and reports this value to userspace which can
    confuse the inotify listener. Avoid the problem by validating that wd is
    sensible (and pretend the mark got removed before the event got
    generated otherwise).
    
    CC: stable@vger.kernel.org
    Fixes: 7e790dd5fc93 ("inotify: fix error paths in inotify_update_watch")
    Message-Id: <20230424163219.9250-1-jack@suse.cz>
    Reported-by: syzbot+4a06d4373fd52f0b2f9c@syzkaller.appspotmail.com
    Reviewed-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ionic: catch failure from devlink_alloc [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Tue May 2 11:35:36 2023 -0700

    ionic: catch failure from devlink_alloc
    
    [ Upstream commit 4a54903ff68ddb33b6463c94b4eb37fc584ef760 ]
    
    Add a check for NULL on the alloc return.  If devlink_alloc() fails and
    we try to use devlink_priv() on the NULL return, the kernel gets very
    unhappy and panics. With this fix, the driver load will still fail,
    but at least it won't panic the kernel.
    
    Fixes: df69ba43217d ("ionic: Add basic framework for IONIC Network device driver")
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ionic: remove noise from ethtool rxnfc error msg [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Tue May 2 11:47:40 2023 -0700

    ionic: remove noise from ethtool rxnfc error msg
    
    [ Upstream commit 3711d44fac1f80ea69ecb7315fed05b3812a7401 ]
    
    It seems that ethtool is calling into .get_rxnfc more often with
    ETHTOOL_GRXCLSRLCNT which ionic doesn't know about.  We don't
    need to log a message about it, just return not supported.
    
    Fixes: aa3198819bea6 ("ionic: Add RSS support")
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ksmbd: add channel rwlock [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Fri Jul 22 10:15:57 2022 +0900

    ksmbd: add channel rwlock
    
    [ Upstream commit 8e06b31e348107c5d78e2c90bb7e69388cb97fb6 ]
    
    Add missing rwlock for channel list in session.
    
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Reviewed-by: Hyunchul Lee <hyc.lee@gmail.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Stable-dep-of: 7b4323373d84 ("ksmbd: fix deadlock in ksmbd_find_crypto_ctx()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: fix deadlock in ksmbd_find_crypto_ctx() [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Wed May 3 08:44:14 2023 +0900

    ksmbd: fix deadlock in ksmbd_find_crypto_ctx()
    
    [ Upstream commit 7b4323373d844954bb76e0e9f39c4e5fc785fa7b ]
    
    Deadlock is triggered by sending multiple concurrent session setup
    requests. It should be reused after releasing when getting ctx for crypto.
    Multiple consecutive ctx uses cause deadlock while waiting for releasing
    due to the limited number of ctx.
    
    Cc: stable@vger.kernel.org
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-20591
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: fix kernel oops from idr_remove() [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Fri Jul 22 10:17:06 2022 +0900

    ksmbd: fix kernel oops from idr_remove()
    
    [ Upstream commit 17ea92a9f6d0b9a97aaec5ab748e4591d70a562c ]
    
    There is a report that kernel oops happen from idr_remove().
    
    kernel: BUG: kernel NULL pointer dereference, address: 0000000000000010
    kernel: RIP: 0010:idr_remove+0x1/0x20
    kernel:  __ksmbd_close_fd+0xb2/0x2d0 [ksmbd]
    kernel:  ksmbd_vfs_read+0x91/0x190 [ksmbd]
    kernel:  ksmbd_fd_put+0x29/0x40 [ksmbd]
    kernel:  smb2_read+0x210/0x390 [ksmbd]
    kernel:  __process_request+0xa4/0x180 [ksmbd]
    kernel:  __handle_ksmbd_work+0xf0/0x290 [ksmbd]
    kernel:  handle_ksmbd_work+0x2d/0x50 [ksmbd]
    kernel:  process_one_work+0x21d/0x3f0
    kernel:  worker_thread+0x50/0x3d0
    kernel:  rescuer_thread+0x390/0x390
    kernel:  kthread+0xee/0x120
    kthread_complete_and_exit+0x20/0x20
    kernel:  ret_from_fork+0x22/0x30
    
    While accessing files, If connection is disconnected, windows send
    session setup request included previous session destroy. But while still
    processing requests on previous session, this request destroy file
    table, which mean file table idr will be freed and set to NULL.
    So kernel oops happen from ft->idr in __ksmbd_close_fd().
    This patch don't directly destroy session in destroy_previous_session().
    It just set to KSMBD_SESS_EXITING so that connection will be
    terminated after finishing the rest of requests.
    
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Reviewed-by: Hyunchul Lee <hyc.lee@gmail.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Stable-dep-of: 7b4323373d84 ("ksmbd: fix deadlock in ksmbd_find_crypto_ctx()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: fix multi session connection failure [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Wed Dec 15 14:57:27 2021 +0900

    ksmbd: fix multi session connection failure
    
    [ Upstream commit ce53d365378cde71bb6596d79c257e600d951d29 ]
    
    When RSS mode is enable, windows client do simultaneously send several
    session requests to server. There is racy issue using
    sess->ntlmssp.cryptkey on N connection : 1 session. So authetication
    failed using wrong cryptkey on some session. This patch move cryptkey
    to ksmbd_conn structure to use each cryptkey on connection.
    
    Tested-by: Ziwei Xie <zw.xie@high-flyer.cn>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Stable-dep-of: 7b4323373d84 ("ksmbd: fix deadlock in ksmbd_find_crypto_ctx()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: fix racy issue while destroying session on multichannel [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Mon Jul 25 13:36:52 2022 +0900

    ksmbd: fix racy issue while destroying session on multichannel
    
    [ Upstream commit af7c39d971e43cd0af488729bca362427ad99488 ]
    
    After multi-channel connection with windows, Several channels of
    session are connected. Among them, if there is a problem in one channel,
    Windows connects again after disconnecting the channel. In this process,
    the session is released and a kernel oop can occurs while processing
    requests to other channels. When the channel is disconnected, if other
    channels still exist in the session after deleting the channel from
    the channel list in the session, the session should not be released.
    Finally, the session will be released after all channels are disconnected.
    
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Reviewed-by: Hyunchul Lee <hyc.lee@gmail.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Stable-dep-of: 7b4323373d84 ("ksmbd: fix deadlock in ksmbd_find_crypto_ctx()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: not allow guest user on multichannel [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Wed May 3 08:45:08 2023 +0900

    ksmbd: not allow guest user on multichannel
    
    [ Upstream commit 3353ab2df5f68dab7da8d5ebb427a2d265a1f2b2 ]
    
    This patch return STATUS_NOT_SUPPORTED if binding session is guest.
    
    Cc: stable@vger.kernel.org
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-20480
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: replace sessions list in connection with xarray [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Fri Jul 22 10:15:10 2022 +0900

    ksmbd: replace sessions list in connection with xarray
    
    [ Upstream commit e4d3e6b524c0c928f7fc9e03e047885c4951ae60 ]
    
    Replace sessions list in connection with xarray.
    
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Reviewed-by: Hyunchul Lee <hyc.lee@gmail.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Stable-dep-of: 7b4323373d84 ("ksmbd: fix deadlock in ksmbd_find_crypto_ctx()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: set RSS capable in FSCTL_QUERY_NETWORK_INTERFACE_INFO [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Thu Dec 16 10:26:43 2021 +0900

    ksmbd: set RSS capable in FSCTL_QUERY_NETWORK_INTERFACE_INFO
    
    [ Upstream commit a58b45a4dbfd0bf2ebb157789da4d8e6368afb1b ]
    
    Set RSS capable in FSCTL_QUERY_NETWORK_INTERFACE_INFO if netdev has
    multi tx queues. And add ksmbd_compare_user() to avoid racy condition
    issue in ksmbd_free_user(). because windows client is simultaneously used
    to send session setup requests for multichannel connection.
    
    Tested-by: Ziwei Xie <zw.xie@high-flyer.cn>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Stable-dep-of: 7b4323373d84 ("ksmbd: fix deadlock in ksmbd_find_crypto_ctx()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.15.112 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed May 17 11:50:31 2023 +0200

    Linux 5.15.112
    
    Link: https://lore.kernel.org/r/20230515161702.887638251@linuxfoundation.org
    Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
locking/rwsem: Add __always_inline annotation to __down_read_common() and inlined callers [+ + +]
Author: John Stultz <jstultz@google.com>
Date:   Wed May 3 02:33:51 2023 +0000

    locking/rwsem: Add __always_inline annotation to __down_read_common() and inlined callers
    
    commit 92cc5d00a431e96e5a49c0b97e5ad4fa7536bd4b upstream.
    
    Apparently despite it being marked inline, the compiler
    may not inline __down_read_common() which makes it difficult
    to identify the cause of lock contention, as the blocked
    function in traceevents will always be listed as
    __down_read_common().
    
    So this patch adds __always_inline annotation to the common
    function (as well as the inlined helper callers) to force it to
    be inlined so the blocking function will be listed (via Wchan)
    in traceevents.
    
    Fixes: c995e638ccbb ("locking/rwsem: Fold __down_{read,write}*()")
    Reported-by: Tim Murray <timmurray@google.com>
    Signed-off-by: John Stultz <jstultz@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Waiman Long <longman@redhat.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20230503023351.2832796-1-jstultz@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mailbox: zynq: Switch to flexible array to simplify code [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Nov 20 09:25:54 2022 +0100

    mailbox: zynq: Switch to flexible array to simplify code
    
    [ Upstream commit 043f85ce81cb1714e14d31c322c5646513dde3fb ]
    
    Using flexible array is more straight forward. It
      - saves 1 pointer in the 'zynqmp_ipi_pdata' structure
      - saves an indirection when using this array
      - saves some LoC and avoids some always spurious pointer arithmetic
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
    Stable-dep-of: f72f805e7288 ("mailbox: zynqmp: Fix counts of child nodes")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mailbox: zynqmp: Fix counts of child nodes [+ + +]
Author: Tanmay Shah <tanmay.shah@amd.com>
Date:   Fri Mar 10 17:24:04 2023 -0800

    mailbox: zynqmp: Fix counts of child nodes
    
    [ Upstream commit f72f805e72882c361e2a612c64a6e549f3da7152 ]
    
    If child mailbox node status is disabled it causes
    crash in interrupt handler. Fix this by assigning
    only available child node during driver probe.
    
    Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller")
    Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
    Acked-by: Michal Simek <michal.simek@amd.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230311012407.1292118-2-tanmay.shah@amd.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/ncsi: clear Tx enable mode when handling a Config required AEN [+ + +]
Author: Cosmo Chou <chou.cosmo@gmail.com>
Date:   Wed Apr 26 16:13:50 2023 +0800

    net/ncsi: clear Tx enable mode when handling a Config required AEN
    
    [ Upstream commit 6f75cd166a5a3c0bc50441faa8b8304f60522fdd ]
    
    ncsi_channel_is_tx() determines whether a given channel should be
    used for Tx or not. However, when reconfiguring the channel by
    handling a Configuration Required AEN, there is a misjudgment that
    the channel Tx has already been enabled, which results in the Enable
    Channel Network Tx command not being sent.
    
    Clear the channel Tx enable flag before reconfiguring the channel to
    avoid the misjudgment.
    
    Fixes: 8d951a75d022 ("net/ncsi: Configure multi-package, multi-channel modes with failover")
    Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: act_mirred: Add carrier check [+ + +]
Author: Victor Nogueira <victor@mojatatu.com>
Date:   Wed Apr 26 15:19:40 2023 +0000

    net/sched: act_mirred: Add carrier check
    
    [ Upstream commit 526f28bd0fbdc699cda31426928802650c1528e5 ]
    
    There are cases where the device is adminstratively UP, but operationally
    down. For example, we have a physical device (Nvidia ConnectX-6 Dx, 25Gbps)
    who's cable was pulled out, here is its ip link output:
    
    5: ens2f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
        link/ether b8:ce:f6:4b:68:35 brd ff:ff:ff:ff:ff:ff
        altname enp179s0f1np1
    
    As you can see, it's administratively UP but operationally down.
    In this case, sending a packet to this port caused a nasty kernel hang (so
    nasty that we were unable to capture it). Aborting a transmit based on
    operational status (in addition to administrative status) fixes the issue.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: Victor Nogueira <victor@mojatatu.com>
    v1->v2: Add fixes tag
    v2->v3: Remove blank line between tags + add change log, suggested by Leon
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/sched: cls_api: remove block_cb from driver_list before freeing [+ + +]
Author: Vlad Buslov <vladbu@nvidia.com>
Date:   Wed Apr 26 14:31:11 2023 +0200

    net/sched: cls_api: remove block_cb from driver_list before freeing
    
    [ Upstream commit da94a7781fc3c92e7df7832bc2746f4d39bc624e ]
    
    Error handler of tcf_block_bind() frees the whole bo->cb_list on error.
    However, by that time the flow_block_cb instances are already in the driver
    list because driver ndo_setup_tc() callback is called before that up the
    call chain in tcf_block_offload_cmd(). This leaves dangling pointers to
    freed objects in the list and causes use-after-free[0]. Fix it by also
    removing flow_block_cb instances from driver_list before deallocating them.
    
    [0]:
    [  279.868433] ==================================================================
    [  279.869964] BUG: KASAN: slab-use-after-free in flow_block_cb_setup_simple+0x631/0x7c0
    [  279.871527] Read of size 8 at addr ffff888147e2bf20 by task tc/2963
    
    [  279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4
    [  279.874273] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    [  279.876295] Call Trace:
    [  279.876882]  <TASK>
    [  279.877413]  dump_stack_lvl+0x33/0x50
    [  279.878198]  print_report+0xc2/0x610
    [  279.878987]  ? flow_block_cb_setup_simple+0x631/0x7c0
    [  279.879994]  kasan_report+0xae/0xe0
    [  279.880750]  ? flow_block_cb_setup_simple+0x631/0x7c0
    [  279.881744]  ? mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core]
    [  279.883047]  flow_block_cb_setup_simple+0x631/0x7c0
    [  279.884027]  tcf_block_offload_cmd.isra.0+0x189/0x2d0
    [  279.885037]  ? tcf_block_setup+0x6b0/0x6b0
    [  279.885901]  ? mutex_lock+0x7d/0xd0
    [  279.886669]  ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0
    [  279.887844]  ? ingress_init+0x1c0/0x1c0 [sch_ingress]
    [  279.888846]  tcf_block_get_ext+0x61c/0x1200
    [  279.889711]  ingress_init+0x112/0x1c0 [sch_ingress]
    [  279.890682]  ? clsact_init+0x2b0/0x2b0 [sch_ingress]
    [  279.891701]  qdisc_create+0x401/0xea0
    [  279.892485]  ? qdisc_tree_reduce_backlog+0x470/0x470
    [  279.893473]  tc_modify_qdisc+0x6f7/0x16d0
    [  279.894344]  ? tc_get_qdisc+0xac0/0xac0
    [  279.895213]  ? mutex_lock+0x7d/0xd0
    [  279.896005]  ? __mutex_lock_slowpath+0x10/0x10
    [  279.896910]  rtnetlink_rcv_msg+0x5fe/0x9d0
    [  279.897770]  ? rtnl_calcit.isra.0+0x2b0/0x2b0
    [  279.898672]  ? __sys_sendmsg+0xb5/0x140
    [  279.899494]  ? do_syscall_64+0x3d/0x90
    [  279.900302]  ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [  279.901337]  ? kasan_save_stack+0x2e/0x40
    [  279.902177]  ? kasan_save_stack+0x1e/0x40
    [  279.903058]  ? kasan_set_track+0x21/0x30
    [  279.903913]  ? kasan_save_free_info+0x2a/0x40
    [  279.904836]  ? ____kasan_slab_free+0x11a/0x1b0
    [  279.905741]  ? kmem_cache_free+0x179/0x400
    [  279.906599]  netlink_rcv_skb+0x12c/0x360
    [  279.907450]  ? rtnl_calcit.isra.0+0x2b0/0x2b0
    [  279.908360]  ? netlink_ack+0x1550/0x1550
    [  279.909192]  ? rhashtable_walk_peek+0x170/0x170
    [  279.910135]  ? kmem_cache_alloc_node+0x1af/0x390
    [  279.911086]  ? _copy_from_iter+0x3d6/0xc70
    [  279.912031]  netlink_unicast+0x553/0x790
    [  279.912864]  ? netlink_attachskb+0x6a0/0x6a0
    [  279.913763]  ? netlink_recvmsg+0x416/0xb50
    [  279.914627]  netlink_sendmsg+0x7a1/0xcb0
    [  279.915473]  ? netlink_unicast+0x790/0x790
    [  279.916334]  ? iovec_from_user.part.0+0x4d/0x220
    [  279.917293]  ? netlink_unicast+0x790/0x790
    [  279.918159]  sock_sendmsg+0xc5/0x190
    [  279.918938]  ____sys_sendmsg+0x535/0x6b0
    [  279.919813]  ? import_iovec+0x7/0x10
    [  279.920601]  ? kernel_sendmsg+0x30/0x30
    [  279.921423]  ? __copy_msghdr+0x3c0/0x3c0
    [  279.922254]  ? import_iovec+0x7/0x10
    [  279.923041]  ___sys_sendmsg+0xeb/0x170
    [  279.923854]  ? copy_msghdr_from_user+0x110/0x110
    [  279.924797]  ? ___sys_recvmsg+0xd9/0x130
    [  279.925630]  ? __perf_event_task_sched_in+0x183/0x470
    [  279.926656]  ? ___sys_sendmsg+0x170/0x170
    [  279.927529]  ? ctx_sched_in+0x530/0x530
    [  279.928369]  ? update_curr+0x283/0x4f0
    [  279.929185]  ? perf_event_update_userpage+0x570/0x570
    [  279.930201]  ? __fget_light+0x57/0x520
    [  279.931023]  ? __switch_to+0x53d/0xe70
    [  279.931846]  ? sockfd_lookup_light+0x1a/0x140
    [  279.932761]  __sys_sendmsg+0xb5/0x140
    [  279.933560]  ? __sys_sendmsg_sock+0x20/0x20
    [  279.934436]  ? fpregs_assert_state_consistent+0x1d/0xa0
    [  279.935490]  do_syscall_64+0x3d/0x90
    [  279.936300]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [  279.937311] RIP: 0033:0x7f21c814f887
    [  279.938085] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
    [  279.941448] RSP: 002b:00007fff11efd478 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    [  279.942964] RAX: ffffffffffffffda RBX: 0000000064401979 RCX: 00007f21c814f887
    [  279.944337] RDX: 0000000000000000 RSI: 00007fff11efd4e0 RDI: 0000000000000003
    [  279.945660] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
    [  279.947003] R10: 00007f21c8008708 R11: 0000000000000246 R12: 0000000000000001
    [  279.948345] R13: 0000000000409980 R14: 000000000047e538 R15: 0000000000485400
    [  279.949690]  </TASK>
    
    [  279.950706] Allocated by task 2960:
    [  279.951471]  kasan_save_stack+0x1e/0x40
    [  279.952338]  kasan_set_track+0x21/0x30
    [  279.953165]  __kasan_kmalloc+0x77/0x90
    [  279.954006]  flow_block_cb_setup_simple+0x3dd/0x7c0
    [  279.955001]  tcf_block_offload_cmd.isra.0+0x189/0x2d0
    [  279.956020]  tcf_block_get_ext+0x61c/0x1200
    [  279.956881]  ingress_init+0x112/0x1c0 [sch_ingress]
    [  279.957873]  qdisc_create+0x401/0xea0
    [  279.958656]  tc_modify_qdisc+0x6f7/0x16d0
    [  279.959506]  rtnetlink_rcv_msg+0x5fe/0x9d0
    [  279.960392]  netlink_rcv_skb+0x12c/0x360
    [  279.961216]  netlink_unicast+0x553/0x790
    [  279.962044]  netlink_sendmsg+0x7a1/0xcb0
    [  279.962906]  sock_sendmsg+0xc5/0x190
    [  279.963702]  ____sys_sendmsg+0x535/0x6b0
    [  279.964534]  ___sys_sendmsg+0xeb/0x170
    [  279.965343]  __sys_sendmsg+0xb5/0x140
    [  279.966132]  do_syscall_64+0x3d/0x90
    [  279.966908]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    [  279.968407] Freed by task 2960:
    [  279.969114]  kasan_save_stack+0x1e/0x40
    [  279.969929]  kasan_set_track+0x21/0x30
    [  279.970729]  kasan_save_free_info+0x2a/0x40
    [  279.971603]  ____kasan_slab_free+0x11a/0x1b0
    [  279.972483]  __kmem_cache_free+0x14d/0x280
    [  279.973337]  tcf_block_setup+0x29d/0x6b0
    [  279.974173]  tcf_block_offload_cmd.isra.0+0x226/0x2d0
    [  279.975186]  tcf_block_get_ext+0x61c/0x1200
    [  279.976080]  ingress_init+0x112/0x1c0 [sch_ingress]
    [  279.977065]  qdisc_create+0x401/0xea0
    [  279.977857]  tc_modify_qdisc+0x6f7/0x16d0
    [  279.978695]  rtnetlink_rcv_msg+0x5fe/0x9d0
    [  279.979562]  netlink_rcv_skb+0x12c/0x360
    [  279.980388]  netlink_unicast+0x553/0x790
    [  279.981214]  netlink_sendmsg+0x7a1/0xcb0
    [  279.982043]  sock_sendmsg+0xc5/0x190
    [  279.982827]  ____sys_sendmsg+0x535/0x6b0
    [  279.983703]  ___sys_sendmsg+0xeb/0x170
    [  279.984510]  __sys_sendmsg+0xb5/0x140
    [  279.985298]  do_syscall_64+0x3d/0x90
    [  279.986076]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    [  279.987532] The buggy address belongs to the object at ffff888147e2bf00
                    which belongs to the cache kmalloc-192 of size 192
    [  279.989747] The buggy address is located 32 bytes inside of
                    freed 192-byte region [ffff888147e2bf00, ffff888147e2bfc0)
    
    [  279.992367] The buggy address belongs to the physical page:
    [  279.993430] page:00000000550f405c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x147e2a
    [  279.995182] head:00000000550f405c order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0
    [  279.996713] anon flags: 0x200000000010200(slab|head|node=0|zone=2)
    [  279.997878] raw: 0200000000010200 ffff888100042a00 0000000000000000 dead000000000001
    [  279.999384] raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
    [  280.000894] page dumped because: kasan: bad access detected
    
    [  280.002386] Memory state around the buggy address:
    [  280.003338]  ffff888147e2be00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  280.004781]  ffff888147e2be80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [  280.006224] >ffff888147e2bf00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  280.007700]                                ^
    [  280.008592]  ffff888147e2bf80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [  280.010035]  ffff888147e2c000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  280.011564] ==================================================================
    
    Fixes: 59094b1e5094 ("net: sched: use flow block API")
    Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: dsa: mt7530: fix corrupt frames using trgmii on 40 MHz XTAL MT7621 [+ + +]
Author: Arınç ÜNAL <arinc.unal@arinc9.com>
Date:   Wed May 3 00:09:46 2023 +0300

    net: dsa: mt7530: fix corrupt frames using trgmii on 40 MHz XTAL MT7621
    
    [ Upstream commit 37c218d8021e36e226add4bab93d071d30fe0704 ]
    
    The multi-chip module MT7530 switch with a 40 MHz oscillator on the
    MT7621AT, MT7621DAT, and MT7621ST SoCs forwards corrupt frames using
    trgmii.
    
    This is caused by the assumption that MT7621 SoCs have got 150 MHz PLL,
    hence using the ncpo1 value, 0x0780.
    
    My testing shows this value works on Unielec U7621-06, Bartel's testing
    shows it won't work on Hi-Link HLK-MT7621A and Netgear WAC104. All devices
    tested have got 40 MHz oscillators.
    
    Using the value for 125 MHz PLL, 0x0640, works on all boards at hand. The
    definitions for 125 MHz PLL exist on the Banana Pi BPI-R2 BSP source code
    whilst 150 MHz PLL don't.
    
    Forwarding frames using trgmii on the MCM MT7530 switch with a 25 MHz
    oscillator on the said MT7621 SoCs works fine because the ncpo1 value
    defined for it is for 125 MHz PLL.
    
    Change the 150 MHz PLL comment to 125 MHz PLL, and use the 125 MHz PLL
    ncpo1 values for both oscillator frequencies.
    
    Link: https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/81d24bbce7d99524d0771a8bdb2d6663e4eb4faa/u-boot-mt/drivers/net/rt2880_eth.c#L2195
    Fixes: 7ef6f6f8d237 ("net: dsa: mt7530: Add MT7621 TRGMII mode support")
    Tested-by: Bartel Eerdekens <bartel.eerdekens@constell8.be>
    Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: mv88e6xxx: add mv88e6321 rsvd2cpu [+ + +]
Author: Angelo Dureghello <angelo.dureghello@timesys.com>
Date:   Wed Apr 26 22:28:15 2023 +0200

    net: dsa: mv88e6xxx: add mv88e6321 rsvd2cpu
    
    [ Upstream commit 6686317855c6997671982d4489ccdd946f644957 ]
    
    Add rsvd2cpu capability for mv88e6321 model, to allow proper bpdu
    processing.
    
    Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com>
    Fixes: 51c901a775621 ("net: dsa: mv88e6xxx: distinguish Global 2 Rsvd2CPU")
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: enetc: check the index of the SFI rather than the handle [+ + +]
Author: Wei Fang <wei.fang@nxp.com>
Date:   Thu May 4 16:03:59 2023 +0800

    net: enetc: check the index of the SFI rather than the handle
    
    [ Upstream commit 299efdc2380aac588557f4d0b2ce7bee05bd0cf2 ]
    
    We should check whether the current SFI (Stream Filter Instance) table
    is full before creating a new SFI entry. However, the previous logic
    checks the handle by mistake and might lead to unpredictable behavior.
    
    Fixes: 888ae5a3952b ("net: enetc: add tc flower psfp offload driver")
    Signed-off-by: Wei Fang <wei.fang@nxp.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-af: Secure APR table update with the lock [+ + +]
Author: Geetha sowjanya <gakula@marvell.com>
Date:   Wed May 3 12:39:34 2023 +0530

    octeontx2-af: Secure APR table update with the lock
    
    [ Upstream commit 048486f81d01db4d100af021ee2ea211d19732a0 ]
    
    APR table contains the lmtst base address of PF/VFs. These entries
    are updated by the PF/VF during the device probe. The lmtst address
    is fetched from HW using "TXN_REQ" and "ADDR_RSP_STS" registers.
    The lock tries to protect these registers from getting overwritten
    when multiple PFs invokes rvu_get_lmtaddr() simultaneously.
    
    For example, if PF1 submit the request and got permitted before it
    reads the response and PF2 got scheduled submit the request then the
    response of PF1 is overwritten by the PF2 response.
    
    Fixes: 893ae97214c3 ("octeontx2-af: cn10k: Support configurable LMTST regions")
    Signed-off-by: Geetha sowjanya <gakula@marvell.com>
    Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
    Signed-off-by: Sai Krishna <saikrishnag@marvell.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-af: Skip PFs if not enabled [+ + +]
Author: Ratheesh Kannoth <rkannoth@marvell.com>
Date:   Wed May 3 12:39:42 2023 +0530

    octeontx2-af: Skip PFs if not enabled
    
    [ Upstream commit 5eb1b7220948a69298a436148a735f32ec325289 ]
    
    Firmware enables PFs and allocate mbox resources for each of the PFs.
    Currently PF driver configures mbox resources without checking whether
    PF is enabled or not. This results in crash. This patch fixes this issue
    by skipping disabled PF's mbox initialization.
    
    Fixes: 9bdc47a6e328 ("octeontx2-af: Mbox communication support btw AF and it's VFs")
    Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
    Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
    Signed-off-by: Sai Krishna <saikrishnag@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-pf: Disable packet I/O for graceful exit [+ + +]
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date:   Wed May 3 12:39:43 2023 +0530

    octeontx2-pf: Disable packet I/O for graceful exit
    
    [ Upstream commit c926252205c424c4842dbdbe02f8e3296f623204 ]
    
    At the stage of enabling packet I/O in otx2_open, If mailbox
    timeout occurs then interface ends up in down state where as
    hardware packet I/O is enabled. Hence disable packet I/O also
    before bailing out.
    
    Fixes: 1ea0166da050 ("octeontx2-pf: Fix the device state on error")
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
    Signed-off-by: Sai Krishna <saikrishnag@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-vf: Detach LF resources on probe cleanup [+ + +]
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date:   Wed May 3 12:39:44 2023 +0530

    octeontx2-vf: Detach LF resources on probe cleanup
    
    [ Upstream commit 99ae1260fdb5f15beab8a3adfb93a9041c87a2c1 ]
    
    When a VF device probe fails due to error in MSIX vector allocation then
    the resources NIX and NPA LFs were not detached. Fix this by detaching
    the LFs when MSIX vector allocation fails.
    
    Fixes: 3184fb5ba96e ("octeontx2-vf: Virtual function driver support")
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
    Signed-off-by: Sai Krishna <saikrishnag@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf evlist: Refactor evlist__for_each_cpu() [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue Jan 4 22:13:37 2022 -0800

    perf evlist: Refactor evlist__for_each_cpu()
    
    [ Upstream commit 472832d2c000b9611feaea66fe521055c3dbf17a ]
    
    Previously evlist__for_each_cpu() needed to iterate over the evlist in
    an inner loop and call "skip" routines. Refactor this so that the
    iteratr is smarter and the next function can update both the current CPU
    and evsel.
    
    By using a cpu map index, fix apparent off-by-1 in __run_perf_stat's
    call to perf_evsel__close_cpu().
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: John Garry <john.garry@huawei.com>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Paul Clarke <pc@us.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Riccardo Mancini <rickyman7@gmail.com>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
    Cc: Vineet Singh <vineet.singh@intel.com>
    Cc: coresight@lists.linaro.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: zhengjun.xing@intel.com
    Link: https://lore.kernel.org/r/20220105061351.120843-35-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: ecc68ee216c6 ("perf stat: Separate bperf from bpf_profiler")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf map: Delete two variable initialisations before null pointer checks in sort__sym_from_cmp() [+ + +]
Author: Markus Elfring <Markus.Elfring@web.de>
Date:   Thu Apr 13 14:46:39 2023 +0200

    perf map: Delete two variable initialisations before null pointer checks in sort__sym_from_cmp()
    
    [ Upstream commit c160118a90d4acf335993d8d59b02ae2147a524e ]
    
    Addresses of two data structure members were determined before
    corresponding null pointer checks in the implementation of the function
    “sort__sym_from_cmp”.
    
    Thus avoid the risk for undefined behaviour by removing extra
    initialisations for the local variables “from_l” and “from_r” (also
    because they were already reassigned with the same value behind this
    pointer check).
    
    This issue was detected by using the Coccinelle software.
    
    Fixes: 1b9e97a2a95e4941 ("perf tools: Fix report -F symbol_from for data without branch info")
    Signed-off-by: <elfring@users.sourceforge.net>
    Acked-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: German Gomez <german.gomez@arm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/cocci/54a21fea-64e3-de67-82ef-d61b90ffad05@web.de/
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf pmu: zfree() expects a pointer to a pointer to zero it after freeing its contents [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Wed Apr 12 10:23:35 2023 -0300

    perf pmu: zfree() expects a pointer to a pointer to zero it after freeing its contents
    
    [ Upstream commit 57f14b5ae1a97537f2abd2828ee7212cada7036e ]
    
    An audit showed just this one problem with zfree(), fix it.
    
    Fixes: 9fbc61f832ebf432 ("perf pmu: Add support for PMU capabilities")
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf scripts intel-pt-events.py: Fix IPC output for Python 2 [+ + +]
Author: Roman Lozko <lozko.roma@gmail.com>
Date:   Fri Mar 10 15:04:45 2023 +0000

    perf scripts intel-pt-events.py: Fix IPC output for Python 2
    
    [ Upstream commit 1f64cfdebfe0494264271e8d7a3a47faf5f58ec7 ]
    
    Integers are not converted to floats during division in Python 2 which
    results in incorrect IPC values. Fix by switching to new division
    behavior.
    
    Fixes: a483e64c0b62e93a ("perf scripting python: intel-pt-events.py: Add --insn-trace and --src-trace")
    Signed-off-by: Roman Lozko <lozko.roma@gmail.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20230310150445.2925841-1-lozko.roma@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf stat: Separate bperf from bpf_profiler [+ + +]
Author: Dmitrii Dolgov <9erthalion6@gmail.com>
Date:   Wed Apr 12 20:23:16 2023 +0200

    perf stat: Separate bperf from bpf_profiler
    
    [ Upstream commit ecc68ee216c6c5b2f84915e1441adf436f1b019b ]
    
    It seems that perf stat -b <prog id> doesn't produce any results:
    
        $ perf stat -e cycles -b 4 -I 10000 -vvv
        Control descriptor is not initialized
        cycles: 0 0 0
                    time        counts unit      events
            10.007641640    <not supported>      cycles
    
    Looks like this happens because fentry/fexit progs are getting loaded, but the
    corresponding perf event is not enabled and not added into the events bpf map.
    I think there is some mixing up between two type of bpf support, one for bperf
    and one for bpf_profiler. Both are identified via evsel__is_bpf, based on which
    perf events are enabled, but for the latter (bpf_profiler) a perf event is
    required. Using evsel__is_bperf to check only bperf produces expected results:
    
        $ perf stat -e cycles -b 4 -I 10000 -vvv
        Control descriptor is not initialized
        ------------------------------------------------------------
        perf_event_attr:
          size                             136
          sample_type                      IDENTIFIER
          read_format                      TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
          disabled                         1
          exclude_guest                    1
        ------------------------------------------------------------
        sys_perf_event_open: pid -1  cpu 0  group_fd -1  flags 0x8 = 3
        ------------------------------------------------------------
        [...perf_event_attr for other CPUs...]
        ------------------------------------------------------------
        cycles: 309426 169009 169009
                    time             counts unit events
            10.010091271             309426      cycles
    
    The final numbers correspond (at least in the level of magnitude) to the
    same metric obtained via bpftool.
    
    Fixes: 112cb56164bc2108 ("perf stat: Introduce config stat.bpf-counter-events")
    Reviewed-by: Song Liu <song@kernel.org>
    Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
    Tested-by: Song Liu <song@kernel.org>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20230412182316.11628-1-9erthalion6@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf symbols: Fix return incorrect build_id size in elf_read_build_id() [+ + +]
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Thu Apr 27 01:28:41 2023 +0000

    perf symbols: Fix return incorrect build_id size in elf_read_build_id()
    
    [ Upstream commit 1511e4696acb715a4fe48be89e1e691daec91c0e ]
    
    In elf_read_build_id(), if gnu build_id is found, should return the size of
    the actually copied data. If descsz is greater thanBuild_ID_SIZE,
    write_buildid data access may occur.
    
    Fixes: be96ea8ffa788dcc ("perf symbols: Fix issue with binaries using 16-bytes buildids (v2)")
    Reported-by: Will Ochowicz <Will.Ochowicz@genusplc.com>
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Tested-by: Will Ochowicz <Will.Ochowicz@genusplc.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Link: https://lore.kernel.org/lkml/CWLP265MB49702F7BA3D6D8F13E4B1A719C649@CWLP265MB4970.GBRP265.PROD.OUTLOOK.COM/T/
    Link: https://lore.kernel.org/r/20230427012841.231729-1-yangjihong1@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf vendor events power9: Remove UTF-8 characters from JSON files [+ + +]
Author: Kajol Jain <kjain@linux.ibm.com>
Date:   Tue Mar 28 16:59:08 2023 +0530

    perf vendor events power9: Remove UTF-8 characters from JSON files
    
    [ Upstream commit 5d9df8731c0941f3add30f96745a62586a0c9d52 ]
    
    Commit 3c22ba5243040c13 ("perf vendor events powerpc: Update POWER9
    events") added and updated power9 PMU JSON events. However some of the
    JSON events which are part of other.json and pipeline.json files,
    contains UTF-8 characters in their brief description.  Having UTF-8
    character could breaks the perf build on some distros.
    
    Fix this issue by removing the UTF-8 characters from other.json and
    pipeline.json files.
    
    Result without the fix:
    
      [command]# file -i pmu-events/arch/powerpc/power9/*
      pmu-events/arch/powerpc/power9/cache.json:          application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/floating-point.json: application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/frontend.json:       application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/marked.json:         application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/memory.json:         application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/metrics.json:        application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/nest_metrics.json:   application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/other.json:          application/json; charset=utf-8
      pmu-events/arch/powerpc/power9/pipeline.json:       application/json; charset=utf-8
      pmu-events/arch/powerpc/power9/pmc.json:            application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/translation.json:    application/json; charset=us-ascii
      [command]#
    
    Result with the fix:
    
      [command]# file -i pmu-events/arch/powerpc/power9/*
      pmu-events/arch/powerpc/power9/cache.json:          application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/floating-point.json: application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/frontend.json:       application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/marked.json:         application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/memory.json:         application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/metrics.json:        application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/nest_metrics.json:   application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/other.json:          application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/pipeline.json:       application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/pmc.json:            application/json; charset=us-ascii
      pmu-events/arch/powerpc/power9/translation.json:    application/json; charset=us-ascii
      [command]#
    
    Fixes: 3c22ba5243040c13 ("perf vendor events powerpc: Update POWER9 events")
    Reported-by: Arnaldo Carvalho de Melo <acme@kernel.com>
    Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
    Acked-by: Ian Rogers <irogers@google.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Disha Goel <disgoel@linux.ibm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
    Cc: linuxppc-dev@lists.ozlabs.org
    Link: https://lore.kernel.org/lkml/ZBxP77deq7ikTxwG@kernel.org/
    Link: https://lore.kernel.org/r/20230328112908.113158-1-kjain@linux.ibm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: touchscreen_dmi: Add info for the Dexp Ursus KX210i [+ + +]
Author: Andrey Avdeev <jamesstoun@gmail.com>
Date:   Sun Apr 30 11:01:10 2023 +0300

    platform/x86: touchscreen_dmi: Add info for the Dexp Ursus KX210i
    
    commit 4b65f95c87c35699bc6ad540d6b9dd7f950d0924 upstream.
    
    Add touchscreen info for the Dexp Ursus KX210i
    
    Signed-off-by: Andrey Avdeev <jamesstoun@gmail.com>
    Link: https://lore.kernel.org/r/ZE4gRgzRQCjXFYD0@avdeevavpc
    Cc: stable@vger.kernel.org
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

platform/x86: touchscreen_dmi: Add upside-down quirk for GDIX1002 ts on the Juno Tablet [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri May 5 23:03:23 2023 +0200

    platform/x86: touchscreen_dmi: Add upside-down quirk for GDIX1002 ts on the Juno Tablet
    
    commit 6abfa99ce52f61a31bcfc2aaaae09006f5665495 upstream.
    
    The Juno Computers Juno Tablet has an upside-down mounted Goodix
    touchscreen. Add a quirk to invert both axis to correct for this.
    
    Link: https://junocomputers.com/us/product/juno-tablet/
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20230505210323.43177-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
r8152: fix flow control issue of RTL8156A [+ + +]
Author: Hayes Wang <hayeswang@realtek.com>
Date:   Fri Apr 28 16:53:29 2023 +0800

    r8152: fix flow control issue of RTL8156A
    
    [ Upstream commit 8ceda6d5a1e5402fd852e6cc59a286ce3dc545ee ]
    
    The feature of flow control becomes abnormal, if the device sends a
    pause frame and the tx/rx is disabled before sending a release frame. It
    causes the lost of packets.
    
    Set PLA_RX_FIFO_FULL and PLA_RX_FIFO_EMPTY to zeros before disabling the
    tx/rx. And, toggle FC_PATCH_TASK before enabling tx/rx to reset the flow
    control patch and timer. Then, the hardware could clear the state and
    the flow control becomes normal after enabling tx/rx.
    
    Besides, remove inline for fc_pause_on_auto() and fc_pause_off_auto().
    
    Fixes: 195aae321c82 ("r8152: support new chips")
    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

r8152: fix the poor throughput for 2.5G devices [+ + +]
Author: Hayes Wang <hayeswang@realtek.com>
Date:   Fri Apr 28 16:53:30 2023 +0800

    r8152: fix the poor throughput for 2.5G devices
    
    [ Upstream commit 61b0ad6f58e2066e054c6d4839d67974d2861a7d ]
    
    Fix the poor throughput for 2.5G devices, when changing the speed from
    auto mode to force mode. This patch is used to notify the MAC when the
    mode is changed.
    
    Fixes: 195aae321c82 ("r8152: support new chips")
    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

r8152: move setting r8153b_rx_agg_chg_indicate() [+ + +]
Author: Hayes Wang <hayeswang@realtek.com>
Date:   Fri Apr 28 16:53:31 2023 +0800

    r8152: move setting r8153b_rx_agg_chg_indicate()
    
    [ Upstream commit cce8334f4aacd9936309a002d4a4de92a07cd2c2 ]
    
    Move setting r8153b_rx_agg_chg_indicate() for 2.5G devices. The
    r8153b_rx_agg_chg_indicate() has to be called after enabling tx/rx.
    Otherwise, the coalescing settings are useless.
    
    Fixes: 195aae321c82 ("r8152: support new chips")
    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
remoteproc: imx_rproc: Call of_node_put() on iteration error [+ + +]
Author: Mathieu Poirier <mathieu.poirier@linaro.org>
Date:   Mon Mar 20 16:18:25 2023 -0600

    remoteproc: imx_rproc: Call of_node_put() on iteration error
    
    commit 5ef074e805ecfd9a16dbb7b6b88bbfa8abad7054 upstream.
    
    Function of_phandle_iterator_next() calls of_node_put() on the last
    device_node it iterated over, but when the loop exits prematurely it has
    to be called explicitly.
    
    Fixes: b29b4249f8f0 ("remoteproc: imx_rproc: add i.MX specific parse fw hook")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Link: https://lore.kernel.org/r/20230320221826.2728078-5-mathieu.poirier@linaro.org
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

remoteproc: st: Call of_node_put() on iteration error [+ + +]
Author: Mathieu Poirier <mathieu.poirier@linaro.org>
Date:   Mon Mar 20 16:18:23 2023 -0600

    remoteproc: st: Call of_node_put() on iteration error
    
    commit 8a74918948b40317a5b5bab9739d13dcb5de2784 upstream.
    
    Function of_phandle_iterator_next() calls of_node_put() on the last
    device_node it iterated over, but when the loop exits prematurely it has
    to be called explicitly.
    
    Fixes: 3df52ed7f269 ("remoteproc: st: add reserved memory support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Link: https://lore.kernel.org/r/20230320221826.2728078-3-mathieu.poirier@linaro.org
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

remoteproc: stm32: Call of_node_put() on iteration error [+ + +]
Author: Mathieu Poirier <mathieu.poirier@linaro.org>
Date:   Mon Mar 20 16:18:22 2023 -0600

    remoteproc: stm32: Call of_node_put() on iteration error
    
    commit ccadca5baf5124a880f2bb50ed1ec265415f025b upstream.
    
    Function of_phandle_iterator_next() calls of_node_put() on the last
    device_node it iterated over, but when the loop exits prematurely it has
    to be called explicitly.
    
    Fixes: 13140de09cc2 ("remoteproc: stm32: add an ST stm32_rproc driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Link: https://lore.kernel.org/r/20230320221826.2728078-2-mathieu.poirier@linaro.org
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ring-buffer: Ensure proper resetting of atomic variables in ring_buffer_reset_online_cpus [+ + +]
Author: Tze-nan Wu <Tze-nan.Wu@mediatek.com>
Date:   Wed Apr 26 14:20:23 2023 +0800

    ring-buffer: Ensure proper resetting of atomic variables in ring_buffer_reset_online_cpus
    
    [ Upstream commit 7c339fb4d8577792378136c15fde773cfb863cb8 ]
    
    In ring_buffer_reset_online_cpus, the buffer_size_kb write operation
    may permanently fail if the cpu_online_mask changes between two
    for_each_online_buffer_cpu loops. The number of increases and decreases
    on both cpu_buffer->resize_disabled and cpu_buffer->record_disabled may be
    inconsistent, causing some CPUs to have non-zero values for these atomic
    variables after the function returns.
    
    This issue can be reproduced by "echo 0 > trace" while hotplugging cpu.
    After reproducing success, we can find out buffer_size_kb will not be
    functional anymore.
    
    To prevent leaving 'resize_disabled' and 'record_disabled' non-zero after
    ring_buffer_reset_online_cpus returns, we ensure that each atomic variable
    has been set up before atomic_sub() to it.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20230426062027.17451-1-Tze-nan.Wu@mediatek.com
    
    Cc: stable@vger.kernel.org
    Cc: <mhiramat@kernel.org>
    Cc: npiggin@gmail.com
    Fixes: b23d7a5f4a07 ("ring-buffer: speed up buffer resets by avoiding synchronize_rcu for each CPU")
    Reviewed-by: Cheng-Jui Wang <cheng-jui.wang@mediatek.com>
    Signed-off-by: Tze-nan Wu <Tze-nan.Wu@mediatek.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
RISC-V: Fix up a cherry-pick warning in setup_vm_final() [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Tue May 9 14:51:41 2023 +0200

    RISC-V: Fix up a cherry-pick warning in setup_vm_final()
    
    This triggers a -Wdeclaration-after-statement as the code has changed a
    bit since upstream.  It might be better to hoist the whole block up, but
    this is a smaller change so I went with it.
    
    arch/riscv/mm/init.c:755:16: warning: mixing declarations and code is a C99 extension [-Wdeclaration-after-statement]
                 unsigned long idx = pgd_index(__fix_to_virt(FIX_FDT));
                               ^
         1 warning generated.
    
    Fixes: bbf94b042155 ("riscv: Move early dtb mapping into the fixmap region")
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/oe-kbuild-all/202304300429.SXZOA5up-lkp@intel.com/
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

RISC-V: mm: Enable huge page support to kernel_page_present() function [+ + +]
Author: Sia Jee Heng <jeeheng.sia@starfivetech.com>
Date:   Thu Mar 30 14:43:20 2023 +0800

    RISC-V: mm: Enable huge page support to kernel_page_present() function
    
    [ Upstream commit a15c90b67a662c75f469822a7f95c7aaa049e28f ]
    
    Currently kernel_page_present() function doesn't support huge page
    detection causes the function to mistakenly return false to the
    hibernation core.
    
    Add huge page detection to the function to solve the problem.
    
    Fixes: 9e953cda5cdf ("riscv: Introduce huge page support for 32/64bit kernel")
    Signed-off-by: Sia Jee Heng <jeeheng.sia@starfivetech.com>
    Reviewed-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
    Reviewed-by: Mason Huo <mason.huo@starfivetech.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20230330064321.1008373-4-jeeheng.sia@starfivetech.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rxrpc: Fix hard call timeout units [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Fri Apr 28 21:27:54 2023 +0100

    rxrpc: Fix hard call timeout units
    
    [ Upstream commit 0d098d83c5d9e107b2df7f5e11f81492f56d2fe7 ]
    
    The hard call timeout is specified in the RXRPC_SET_CALL_TIMEOUT cmsg in
    seconds, so fix the point at which sendmsg() applies it to the call to
    convert to jiffies from seconds, not milliseconds.
    
    Fixes: a158bdd3247b ("rxrpc: Fix timeout of a call that hasn't yet been granted a channel")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: "David S. Miller" <davem@davemloft.net>
    cc: Eric Dumazet <edumazet@google.com>
    cc: Jakub Kicinski <kuba@kernel.org>
    cc: Paolo Abeni <pabeni@redhat.com>
    cc: linux-afs@lists.infradead.org
    cc: netdev@vger.kernel.org
    cc: linux-kernel@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: qedi: Fix use after free bug in qedi_remove() [+ + +]
Author: Zheng Wang <zyytlz.wz@163.com>
Date:   Thu Apr 13 11:34:22 2023 +0800

    scsi: qedi: Fix use after free bug in qedi_remove()
    
    [ Upstream commit c5749639f2d0a1f6cbe187d05f70c2e7c544d748 ]
    
    In qedi_probe() we call __qedi_probe() which initializes
    &qedi->recovery_work with qedi_recovery_handler() and
    &qedi->board_disable_work with qedi_board_disable_work().
    
    When qedi_schedule_recovery_handler() is called, schedule_delayed_work()
    will finally start the work.
    
    In qedi_remove(), which is called to remove the driver, the following
    sequence may be observed:
    
    Fix this by finishing the work before cleanup in qedi_remove().
    
    CPU0                  CPU1
    
                         |qedi_recovery_handler
    qedi_remove          |
      __qedi_remove      |
    iscsi_host_free      |
    scsi_host_put        |
    //free shost         |
                         |iscsi_host_for_each_session
                         |//use qedi->shost
    
    Cancel recovery_work and board_disable_work in __qedi_remove().
    
    Fixes: 4b1068f5d74b ("scsi: qedi: Add MFW error recovery process")
    Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
    Link: https://lore.kernel.org/r/20230413033422.28003-1-zyytlz.wz@163.com
    Acked-by: Manish Rangankar <mrangankar@marvell.com>
    Reviewed-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: srv6: make srv6_end_dt46_l3vpn_test more robust [+ + +]
Author: Andrea Mayer <andrea.mayer@uniroma2.it>
Date:   Thu Apr 27 11:49:23 2023 +0200

    selftests: srv6: make srv6_end_dt46_l3vpn_test more robust
    
    [ Upstream commit 46ef24c60f8ee70662968ac55325297ed4624d61 ]
    
    On some distributions, the rp_filter is automatically set (=1) by
    default on a netdev basis (also on VRFs).
    In an SRv6 End.DT46 behavior, decapsulated IPv4 packets are routed using
    the table associated with the VRF bound to that tunnel. During lookup
    operations, the rp_filter can lead to packet loss when activated on the
    VRF.
    Therefore, we chose to make this selftest more robust by explicitly
    disabling the rp_filter during tests (as it is automatically set by some
    Linux distributions).
    
    Fixes: 03a0b567a03d ("selftests: seg6: add selftest for SRv6 End.DT46 Behavior")
    Reported-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
    Tested-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: 8250: Fix serial8250_tx_empty() race with DMA Tx [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Fri Mar 17 13:33:18 2023 +0200

    serial: 8250: Fix serial8250_tx_empty() race with DMA Tx
    
    commit 146a37e05d620cef4ad430e5d1c9c077fe6fa76f upstream.
    
    There's a potential race before THRE/TEMT deasserts when DMA Tx is
    starting up (or the next batch of continuous Tx is being submitted).
    This can lead to misdetecting Tx empty condition.
    
    It is entirely normal for THRE/TEMT to be set for some time after the
    DMA Tx had been setup in serial8250_tx_dma(). As Tx side is definitely
    not empty at that point, it seems incorrect for serial8250_tx_empty()
    claim Tx is empty.
    
    Fix the race by also checking in serial8250_tx_empty() whether there's
    DMA Tx active.
    
    Note: This fix only addresses in-kernel race mainly to make using
    TCSADRAIN/FLUSH robust. Userspace can still cause other races but they
    seem userspace concurrency control problems.
    
    Fixes: 9ee4b83e51f74 ("serial: 8250: Add support for dmaengine")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20230317113318.31327-3-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sfc: Fix module EEPROM reporting for QSFP modules [+ + +]
Author: Andy Moreton <andy.moreton@amd.com>
Date:   Fri Apr 28 12:33:33 2023 +0100

    sfc: Fix module EEPROM reporting for QSFP modules
    
    [ Upstream commit 281900a923d4c50df109b52a22ae3cdac150159b ]
    
    The sfc driver does not report QSFP module EEPROM contents correctly
    as only the first page is fetched from hardware.
    
    Commit 0e1a2a3e6e7d ("ethtool: Add SFF-8436 and SFF-8636 max EEPROM
    length definitions") added ETH_MODULE_SFF_8436_MAX_LEN for the overall
    size of the EEPROM info, so use that to report the full EEPROM contents.
    
    Fixes: 9b17010da57a ("sfc: Add ethtool -m support for QSFP modules")
    Signed-off-by: Andy Moreton <andy.moreton@amd.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sh: init: use OF_EARLY_FLATTREE for early init [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Mar 5 20:00:33 2023 -0800

    sh: init: use OF_EARLY_FLATTREE for early init
    
    commit 6cba655543c7959f8a6d2979b9d40a6a66b7ed4f upstream.
    
    When CONFIG_OF_EARLY_FLATTREE and CONFIG_SH_DEVICE_TREE are not set,
    SH3 build fails with a call to early_init_dt_scan(), so in
    arch/sh/kernel/setup.c and arch/sh/kernel/head_32.S, use
    CONFIG_OF_EARLY_FLATTREE instead of CONFIG_OF_FLATTREE.
    
    Fixes this build error:
    ../arch/sh/kernel/setup.c: In function 'sh_fdt_init':
    ../arch/sh/kernel/setup.c:262:26: error: implicit declaration of function 'early_init_dt_scan' [-Werror=implicit-function-declaration]
      262 |         if (!dt_virt || !early_init_dt_scan(dt_virt)) {
    
    Fixes: 03767daa1387 ("sh: fix build regression with CONFIG_OF && !CONFIG_OF_FLATTREE")
    Fixes: eb6b6930a70f ("sh: fix memory corruption of unflattened device tree")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Suggested-by: Rob Herring <robh+dt@kernel.org>
    Cc: Frank Rowand <frowand.list@gmail.com>
    Cc: devicetree@vger.kernel.org
    Cc: Rich Felker <dalias@libc.org>
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Cc: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Cc: linux-sh@vger.kernel.org
    Cc: stable@vger.kernel.org
    Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Link: https://lore.kernel.org/r/20230306040037.20350-4-rdunlap@infradead.org
    Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sh: math-emu: fix macro redefined warning [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Mar 5 20:00:34 2023 -0800

    sh: math-emu: fix macro redefined warning
    
    commit 58a49ad90939386a8682e842c474a0d2c00ec39c upstream.
    
    Fix a warning that was reported by the kernel test robot:
    
    In file included from ../include/math-emu/soft-fp.h:27,
                     from ../arch/sh/math-emu/math.c:22:
    ../arch/sh/include/asm/sfp-machine.h:17: warning: "__BYTE_ORDER" redefined
       17 | #define __BYTE_ORDER __BIG_ENDIAN
    In file included from ../arch/sh/math-emu/math.c:21:
    ../arch/sh/math-emu/sfp-util.h:71: note: this is the location of the previous definition
       71 | #define __BYTE_ORDER __LITTLE_ENDIAN
    
    Fixes: b929926f01f2 ("sh: define __BIG_ENDIAN for math-emu")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Link: lore.kernel.org/r/202111121827.6v6SXtVv-lkp@intel.com
    Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Cc: Rich Felker <dalias@libc.org>
    Cc: linux-sh@vger.kernel.org
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: stable@vger.kernel.org
    Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Link: https://lore.kernel.org/r/20230306040037.20350-5-rdunlap@infradead.org
    Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sh: mcount.S: fix build error when PRINTK is not enabled [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Mar 5 20:00:37 2023 -0800

    sh: mcount.S: fix build error when PRINTK is not enabled
    
    commit c2bd1e18c6f85c0027da2e5e7753b9bfd9f8e6dc upstream.
    
    Fix a build error in mcount.S when CONFIG_PRINTK is not enabled.
    Fixes this build error:
    
    sh2-linux-ld: arch/sh/lib/mcount.o: in function `stack_panic':
    (.text+0xec): undefined reference to `dump_stack'
    
    Fixes: e460ab27b6c3 ("sh: Fix up stack overflow check with ftrace disabled.")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Cc: Rich Felker <dalias@libc.org>
    Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: stable@vger.kernel.org
    Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Link: https://lore.kernel.org/r/20230306040037.20350-8-rdunlap@infradead.org
    Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sh: nmi_debug: fix return value of __setup handler [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Mar 5 20:00:32 2023 -0800

    sh: nmi_debug: fix return value of __setup handler
    
    commit d1155e4132de712a9d3066e2667ceaad39a539c5 upstream.
    
    __setup() handlers should return 1 to obsolete_checksetup() in
    init/main.c to indicate that the boot option has been handled.
    A return of 0 causes the boot option/value to be listed as an Unknown
    kernel parameter and added to init's (limited) argument or environment
    strings. Also, error return codes don't mean anything to
    obsolete_checksetup() -- only non-zero (usually 1) or zero.
    So return 1 from nmi_debug_setup().
    
    Fixes: 1e1030dccb10 ("sh: nmi_debug support.")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: Igor Zhbanov <izh1979@gmail.com>
    Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
    Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Cc: Rich Felker <dalias@libc.org>
    Cc: linux-sh@vger.kernel.org
    Cc: stable@vger.kernel.org
    Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Link: https://lore.kernel.org/r/20230306040037.20350-3-rdunlap@infradead.org
    Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sit: update dev->needed_headroom in ipip6_tunnel_bind_dev() [+ + +]
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Wed Apr 26 23:00:06 2023 -0700

    sit: update dev->needed_headroom in ipip6_tunnel_bind_dev()
    
    [ Upstream commit c88f8d5cd95fd039cff95d682b8e71100c001df0 ]
    
    When a tunnel device is bound with the underlying device, its
    dev->needed_headroom needs to be updated properly. IPv4 tunnels
    already do the same in ip_tunnel_bind_dev(). Otherwise we may
    not have enough header room for skb, especially after commit
    b17f709a2401 ("gue: TX support for using remote checksum offload option").
    
    Fixes: 32b8a8e59c9c ("sit: add IPv4 over IPv4 support")
    Reported-by: Palash Oswal <oswalpalash@gmail.com>
    Link: https://lore.kernel.org/netdev/CAGyP=7fDcSPKu6nttbGwt7RXzE3uyYxLjCSE97J64pRxJP8jPA@mail.gmail.com/
    Cc: Kuniyuki Iwashima <kuniyu@amazon.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
smb3: fix problem remounting a share after shutdown [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Tue May 9 01:37:19 2023 -0500

    smb3: fix problem remounting a share after shutdown
    
    commit 716a3cf317456fa01d54398bb14ab354f50ed6a2 upstream.
    
    xfstests generic/392 showed a problem where even after a
    shutdown call was made on a mount, we would still attempt
    to use the (now inaccessible) superblock if another mount
    was attempted for the same share.
    
    Reported-by: David Howells <dhowells@redhat.com>
    Reviewed-by: David Howells <dhowells@redhat.com>
    Cc: <stable@vger.kernel.org>
    Fixes: 087f757b0129 ("cifs: add shutdown support")
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
SMB3: force unmount was failing to close deferred close files [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Tue May 9 01:00:42 2023 -0500

    SMB3: force unmount was failing to close deferred close files
    
    commit 2cb6f968775a9fd60c90a6042b9550bcec3ea087 upstream.
    
    In investigating a failure with xfstest generic/392 it
    was noticed that mounts were reusing a superblock that should
    already have been freed. This turned out to be related to
    deferred close files keeping a reference count until the
    closetimeo expired.
    
    Currently the only way an fs knows that mount is beginning is
    when force unmount is called, but when this, ie umount_begin(),
    is called all deferred close files on the share (tree
    connection) should be closed immediately (unless shared by
    another mount) to avoid using excess resources on the server
    and to avoid reusing a superblock which should already be freed.
    
    In umount_begin, close all deferred close handles for that
    share if this is the last mount using that share on this
    client (ie send the SMB3 close request over the wire for those
    that have been already closed by the app but that we have
    kept a handle lease open for and have not sent closes to the
    server for yet).
    
    Reported-by: David Howells <dhowells@redhat.com>
    Acked-by: Bharath SM <bharathsm@microsoft.com>
    Cc: <stable@vger.kernel.org>
    Fixes: 78c09634f7dc ("Cifs: Fix kernel oops caused by deferred close for files.")
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ubifs: Fix AA deadlock when setting xattr for encrypted file [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Tue Jul 19 16:00:17 2022 +0800

    ubifs: Fix AA deadlock when setting xattr for encrypted file
    
    [ Upstream commit a0c51565730729f0df2ee886e34b4da6d359a10b ]
    
    Following process:
    vfs_setxattr(host)
      ubifs_xattr_set
        down_write(host_ui->xattr_sem)   <- lock first time
          create_xattr
            ubifs_new_inode(host)
              fscrypt_prepare_new_inode(host)
                fscrypt_policy_to_inherit(host)
                  if (IS_ENCRYPTED(inode))
                    fscrypt_require_key(host)
                      fscrypt_get_encryption_info(host)
                        ubifs_xattr_get(host)
                          down_read(host_ui->xattr_sem) <- AA deadlock
    
    , which may trigger an AA deadlock problem:
    
    [  102.620871] INFO: task setfattr:1599 blocked for more than 10 seconds.
    [  102.625298]       Not tainted 5.19.0-rc7-00001-gb666b6823ce0-dirty #711
    [  102.628732] task:setfattr        state:D stack:    0 pid: 1599
    [  102.628749] Call Trace:
    [  102.628753]  <TASK>
    [  102.628776]  __schedule+0x482/0x1060
    [  102.629964]  schedule+0x92/0x1a0
    [  102.629976]  rwsem_down_read_slowpath+0x287/0x8c0
    [  102.629996]  down_read+0x84/0x170
    [  102.630585]  ubifs_xattr_get+0xd1/0x370 [ubifs]
    [  102.630730]  ubifs_crypt_get_context+0x1f/0x30 [ubifs]
    [  102.630791]  fscrypt_get_encryption_info+0x7d/0x1c0
    [  102.630810]  fscrypt_policy_to_inherit+0x56/0xc0
    [  102.630817]  fscrypt_prepare_new_inode+0x35/0x160
    [  102.630830]  ubifs_new_inode+0xcc/0x4b0 [ubifs]
    [  102.630873]  ubifs_xattr_set+0x591/0x9f0 [ubifs]
    [  102.630961]  xattr_set+0x8c/0x3e0 [ubifs]
    [  102.631003]  __vfs_setxattr+0x71/0xc0
    [  102.631026]  vfs_setxattr+0x105/0x270
    [  102.631034]  do_setxattr+0x6d/0x110
    [  102.631041]  setxattr+0xa0/0xd0
    [  102.631087]  __x64_sys_setxattr+0x2f/0x40
    
    Fetch a reproducer in [Link].
    
    Just like ext4 does, which skips encrypting for inode with
    EXT4_EA_INODE_FL flag. Stop encypting xattr inode for ubifs.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216260
    Fixes: f4e3634a3b64222 ("ubifs: Fix races between xattr_{set|get} ...")
    Fixes: d475a507457b5ca ("ubifs: Add skeleton for fscrypto")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Stable-dep-of: 3a36d20e0129 ("ubifs: Fix memory leak in do_rename")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ubifs: Fix memory leak in do_rename [+ + +]
Author: Mårten Lindahl <marten.lindahl@axis.com>
Date:   Thu Mar 30 16:40:59 2023 +0200

    ubifs: Fix memory leak in do_rename
    
    [ Upstream commit 3a36d20e012903f45714df2731261fdefac900cb ]
    
    If renaming a file in an encrypted directory, function
    fscrypt_setup_filename allocates memory for a file name. This name is
    never used, and before returning to the caller the memory for it is not
    freed.
    
    When running kmemleak on it we see that it is registered as a leak. The
    report below is triggered by a simple program 'rename' that renames a
    file in an encrypted directory:
    
      unreferenced object 0xffff888101502840 (size 32):
        comm "rename", pid 9404, jiffies 4302582475 (age 435.735s)
        backtrace:
          __kmem_cache_alloc_node
          __kmalloc
          fscrypt_setup_filename
          do_rename
          ubifs_rename
          vfs_rename
          do_renameat2
    
    To fix this we can remove the call to fscrypt_setup_filename as it's not
    needed.
    
    Fixes: 278d9a243635f26 ("ubifs: Rename whiteout atomically")
    Reported-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
    Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio_net: split free_unused_bufs() [+ + +]
Author: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Date:   Mon Aug 1 14:38:59 2022 +0800

    virtio_net: split free_unused_bufs()
    
    [ Upstream commit 6e345f8c7cd029ad3aaece15ad4425ac26e4eb63 ]
    
    This patch separates two functions for freeing sq buf and rq buf from
    free_unused_bufs().
    
    When supporting the enable/disable tx/rq queue in the future, it is
    necessary to support separate recovery of a sq buf or a rq buf.
    
    Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Message-Id: <20220801063902.129329-40-xuanzhuo@linux.alibaba.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Stable-dep-of: f8bb51043945 ("virtio_net: suppress cpu stall when free_unused_bufs")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

virtio_net: suppress cpu stall when free_unused_bufs [+ + +]
Author: Wenliang Wang <wangwenliang.1995@bytedance.com>
Date:   Thu May 4 10:27:06 2023 +0800

    virtio_net: suppress cpu stall when free_unused_bufs
    
    [ Upstream commit f8bb5104394560e29017c25bcade4c6b7aabd108 ]
    
    For multi-queue and large ring-size use case, the following error
    occurred when free_unused_bufs:
    rcu: INFO: rcu_sched self-detected stall on CPU.
    
    Fixes: 986a4f4d452d ("virtio_net: multiqueue support")
    Signed-off-by: Wenliang Wang <wangwenliang.1995@bytedance.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
watchdog: dw_wdt: Fix the error handling path of dw_wdt_drv_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Apr 26 08:52:48 2023 +0200

    watchdog: dw_wdt: Fix the error handling path of dw_wdt_drv_probe()
    
    [ Upstream commit 7f5390750645756bd5da2b24fac285f2654dd922 ]
    
    The commit in Fixes has only updated the remove function and missed the
    error handling path of the probe.
    
    Add the missing reset_control_assert() call.
    
    Fixes: 65a3b6935d92 ("watchdog: dw_wdt: get reset lines from dt")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/fbb650650bbb33a8fa2fd028c23157bedeed50e1.1682491863.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: rtw88: rtw8821c: Fix rfe_option field width [+ + +]
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Mon Apr 17 16:03:56 2023 +0200

    wifi: rtw88: rtw8821c: Fix rfe_option field width
    
    [ Upstream commit 14705f969d98187a1cc2682e0c9bd2e230b8098f ]
    
    On my RTW8821CU chipset rfe_option reads as 0x22. Looking at the
    vendor driver suggests that the field width of rfe_option is 5 bit,
    so rfe_option should be masked with 0x1f.
    
    Without this the rfe_option comparisons with 2 further down the
    driver evaluate as false when they should really evaluate as true.
    The effect is that 2G channels do not work.
    
    rfe_option is also used as an array index into rtw8821c_rfe_defs[].
    rtw8821c_rfe_defs[34] (0x22) was added as part of adding USB support,
    likely because rfe_option reads as 0x22. As this now becomes 0x2,
    rtw8821c_rfe_defs[34] is no longer used and can be removed.
    
    Note that this might not be the whole truth. In the vendor driver
    there are indeed places where the unmasked rfe_option value is used.
    However, the driver has several places where rfe_option is tested
    with the pattern if (rfe_option == 2 || rfe_option == 0x22) or
    if (rfe_option == 4 || rfe_option == 0x24), so that rfe_option BIT(5)
    has no influence on the code path taken. We therefore mask BIT(5)
    out from rfe_option entirely until this assumption is proved wrong
    by some chip variant we do not know yet.
    
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Tested-by: Alexandru gagniuc <mr.nuke.me@gmail.com>
    Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
    Tested-by: ValdikSS <iam@valdikss.org.ru>
    Cc: stable@vger.kernel.org
    Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230417140358.2240429-3-s.hauer@pengutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
writeback: fix call of incorrect macro [+ + +]
Author: Maxim Korotkov <korotkov.maxim.s@gmail.com>
Date:   Thu Jan 19 13:44:43 2023 +0300

    writeback: fix call of incorrect macro
    
    [ Upstream commit 3e46c89c74f2c38e5337d2cf44b0b551adff1cb4 ]
    
     the variable 'history' is of type u16, it may be an error
     that the hweight32 macro was used for it
     I guess macro hweight16 should be used
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 2a81490811d0 ("writeback: implement foreign cgroup inode detection")
    Signed-off-by: Maxim Korotkov <korotkov.maxim.s@gmail.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230119104443.3002-1-korotkov.maxim.s@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>