Linux 5.15.155

 
ALSA: firewire-lib: handle quirk to calculate payload quadlets as data block counter [+ + +]
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sun Feb 18 16:41:27 2024 +0900

    ALSA: firewire-lib: handle quirk to calculate payload quadlets as data block counter
    
    [ Upstream commit 4a486439d2ca85752c46711f373b6ddc107bb35d ]
    
    Miglia Harmony Audio (OXFW970) has a quirk to put the number of
    accumulated quadlets in CIP payload into the dbc field of CIP header.
    
    This commit handles the quirk in the packet processing layer.
    
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://lore.kernel.org/r/20240218074128.95210-4-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
amdkfd: use calloc instead of kzalloc to avoid integer overflow [+ + +]
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Apr 12 06:11:25 2024 +1000

    amdkfd: use calloc instead of kzalloc to avoid integer overflow
    
    commit 3b0daecfeac0103aba8b293df07a0cbaf8b43f29 upstream.
    
    This uses calloc instead of doing the multiplication which might
    overflow.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
arm64: dts: rockchip: fix rk3328 hdmi ports node [+ + +]
Author: Johan Jonker <jbx6244@gmail.com>
Date:   Wed Jan 31 22:17:08 2024 +0100

    arm64: dts: rockchip: fix rk3328 hdmi ports node
    
    [ Upstream commit 1d00ba4700d1e0f88ae70d028d2e17e39078fa1c ]
    
    Fix rk3328 hdmi ports node so that it matches the
    rockchip,dw-hdmi.yaml binding.
    
    Signed-off-by: Johan Jonker <jbx6244@gmail.com>
    Link: https://lore.kernel.org/r/e5dea3b7-bf84-4474-9530-cc2da3c41104@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: fix rk3399 hdmi ports node [+ + +]
Author: Johan Jonker <jbx6244@gmail.com>
Date:   Wed Jan 31 22:17:31 2024 +0100

    arm64: dts: rockchip: fix rk3399 hdmi ports node
    
    [ Upstream commit f051b6ace7ffcc48d6d1017191f167c0a85799f6 ]
    
    Fix rk3399 hdmi ports node so that it matches the
    rockchip,dw-hdmi.yaml binding.
    
    Signed-off-by: Johan Jonker <jbx6244@gmail.com>
    Link: https://lore.kernel.org/r/a6ab6f75-3b80-40b1-bd30-3113e14becdd@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: soc-core.c: Skip dummy codec when adding platforms [+ + +]
Author: Chancel Liu <chancel.liu@nxp.com>
Date:   Tue Mar 5 15:56:06 2024 +0900

    ASoC: soc-core.c: Skip dummy codec when adding platforms
    
    [ Upstream commit 23fb6bc2696119391ec3a92ccaffe50e567c515e ]
    
    When pcm_runtime is adding platform components it will scan all
    registered components. In case of DPCM FE/BE some DAI links will
    configure dummy platform. However both dummy codec and dummy platform
    are using "snd-soc-dummy" as component->name. Dummy codec should be
    skipped when adding platforms otherwise there'll be overflow and UBSAN
    complains.
    
    Reported-by: Zhipeng Wang <zhipeng.wang_1@nxp.com>
    Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
    Link: https://msgid.link/r/20240305065606.3778642-1-chancel.liu@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: prevent division by zero in blk_rq_stat_sum() [+ + +]
Author: Roman Smirnov <r.smirnov@omp.ru>
Date:   Tue Mar 5 16:45:09 2024 +0300

    block: prevent division by zero in blk_rq_stat_sum()
    
    [ Upstream commit 93f52fbeaf4b676b21acfe42a5152620e6770d02 ]
    
    The expression dst->nr_samples + src->nr_samples may
    have zero value on overflow. It is necessary to add
    a check to avoid division by zero.
    
    Found by Linux Verification Center (linuxtesting.org) with Svace.
    
    Signed-off-by: Roman Smirnov <r.smirnov@omp.ru>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/20240305134509.23108-1-r.smirnov@omp.ru
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: btintel: Fix null ptr deref in btintel_read_version [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Thu Jan 18 12:40:34 2024 +0800

    Bluetooth: btintel: Fix null ptr deref in btintel_read_version
    
    [ Upstream commit b79e040910101b020931ba0c9a6b77e81ab7f645 ]
    
    If hci_cmd_sync_complete() is triggered and skb is NULL, then
    hdev->req_skb is NULL, which will cause this issue.
    
    Reported-and-tested-by: syzbot+830d9e3fa61968246abd@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: btintel: Fixe build regression [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Feb 23 12:36:23 2024 -0500

    Bluetooth: btintel: Fixe build regression
    
    commit 6e62ebfb49eb65bdcbfc5797db55e0ce7f79c3dd upstream.
    
    This fixes the following build regression:
    
    drivers-bluetooth-btintel.c-btintel_read_version()-warn:
    passing-zero-to-PTR_ERR
    
    Fixes: b79e04091010 ("Bluetooth: btintel: Fix null ptr deref in btintel_read_version")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
btrfs: export: handle invalid inode or root reference in btrfs_get_parent() [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Fri Jan 19 21:19:18 2024 +0100

    btrfs: export: handle invalid inode or root reference in btrfs_get_parent()
    
    [ Upstream commit 26b66d1d366a375745755ca7365f67110bbf6bd5 ]
    
    The get_parent handler looks up a parent of a given dentry, this can be
    either a subvolume or a directory. The search is set up with offset -1
    but it's never expected to find such item, as it would break allowed
    range of inode number or a root id. This means it's a corruption (ext4
    also returns this error code).
    
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Tue Jan 23 23:42:29 2024 +0100

    btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
    
    [ Upstream commit 7411055db5ce64f836aaffd422396af0075fdc99 ]
    
    The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,
    as it could be caused only by two impossible conditions:
    
    - at first the search key is set up to look for a chunk tree item, with
      offset -1, this is an inexact search and the key->offset will contain
      the correct offset upon a successful search, a valid chunk tree item
      cannot have an offset -1
    
    - after first successful search, the found_key corresponds to a chunk
      item, the offset is decremented by 1 before the next loop, it's
      impossible to find a chunk item there due to alignment and size
      constraints
    
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: send: handle path ref underflow in header iterate_inode_ref() [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Tue Feb 6 22:47:13 2024 +0100

    btrfs: send: handle path ref underflow in header iterate_inode_ref()
    
    [ Upstream commit 3c6ee34c6f9cd12802326da26631232a61743501 ]
    
    Change BUG_ON to proper error handling if building the path buffer
    fails. The pointers are not printed so we don't accidentally leak kernel
    addresses.
    
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpuidle: Avoid potential overflow in integer multiplication [+ + +]
Author: C Cheng <C.Cheng@mediatek.com>
Date:   Tue Dec 19 11:14:42 2023 +0800

    cpuidle: Avoid potential overflow in integer multiplication
    
    [ Upstream commit 88390dd788db485912ee7f9a8d3d56fc5265d52f ]
    
    In detail:
    
    In C language, when you perform a multiplication operation, if
    both operands are of int type, the multiplication operation is
    performed on the int type, and then the result is converted to
    the target type. This means that if the product of int type
    multiplication exceeds the range that int type can represent,
    an overflow will occur even if you store the result in a
    variable of int64_t type.
    
    For a multiplication of two int values, it is better to use
    mul_u32_u32() rather than s->exit_latency_ns = s->exit_latency *
    NSEC_PER_USEC to avoid potential overflow happenning.
    
    Signed-off-by: C Cheng <C.Cheng@mediatek.com>
    Signed-off-by: Bo Ye <bo.ye@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    [ rjw: New subject ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers/nvme: Add quirks for device 126f:2262 [+ + +]
Author: Jiawei Fu (iBug) <i@ibugone.com>
Date:   Sat Mar 16 03:27:49 2024 +0800

    drivers/nvme: Add quirks for device 126f:2262
    
    [ Upstream commit e89086c43f0500bc7c4ce225495b73b8ce234c1f ]
    
    This commit adds NVME_QUIRK_NO_DEEPEST_PS and NVME_QUIRK_BOGUS_NID for
    device [126f:2262], which appears to be a generic VID:PID pair used for
    many SSDs based on the Silicon Motion SM2262/SM2262EN controller.
    
    Two of my SSDs with this VID:PID pair exhibit the same behavior:
    
      * They frequently have trouble exiting the deepest power state (5),
        resulting in the entire disk unresponsive.
        Verified by setting nvme_core.default_ps_max_latency_us=10000 and
        observing them behaving normally.
      * They produce all-zero nguid and eui64 with `nvme id-ns` command.
    
    The offending products are:
    
      * HP SSD EX950 1TB
      * HIKVISION C2000Pro 2TB
    
    Signed-off-by: Jiawei Fu <i@ibugone.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Fix nanosec stat overflow [+ + +]
Author: Aric Cyr <aric.cyr@amd.com>
Date:   Thu Aug 29 11:53:52 2019 -0400

    drm/amd/display: Fix nanosec stat overflow
    
    [ Upstream commit 14d68acfd04b39f34eea7bea65dda652e6db5bf6 ]
    
    [Why]
    Nanosec stats can overflow on long running systems potentially causing
    statistic logging issues.
    
    [How]
    Use 64bit types for nanosec stats to ensure no overflow.
    
    Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Aric Cyr <aric.cyr@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: add a hint for block bitmap corrupt state in mb_groups [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Fri Jan 19 14:11:54 2024 +0800

    ext4: add a hint for block bitmap corrupt state in mb_groups
    
    [ Upstream commit 68ee261fb15457ecb17e3683cb4e6a4792ca5b71 ]
    
    If one group is marked as block bitmap corrupted, its free blocks cannot
    be used and its free count is also deducted from the global
    sbi->s_freeclusters_counter. User might be confused about the absent
    free space because we can't query the information about corrupted block
    groups except unreliable error messages in syslog. So add a hint to show
    block bitmap corrupted groups in mb_groups.
    
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240119061154.1525781-1-yi.zhang@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: forbid commit inconsistent quota data when errors=remount-ro [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Fri Jan 19 14:29:08 2024 +0800

    ext4: forbid commit inconsistent quota data when errors=remount-ro
    
    [ Upstream commit d8b945fa475f13d787df00c26a6dc45a3e2e1d1d ]
    
    There's issue as follows When do IO fault injection test:
    Quota error (device dm-3): find_block_dqentry: Quota for id 101 referenced but not present
    Quota error (device dm-3): qtree_read_dquot: Can't read quota structure for id 101
    Quota error (device dm-3): do_check_range: Getting block 2021161007 out of range 1-186
    Quota error (device dm-3): qtree_read_dquot: Can't read quota structure for id 661
    
    Now, ext4_write_dquot()/ext4_acquire_dquot()/ext4_release_dquot() may commit
    inconsistent quota data even if process failed. This may lead to filesystem
    corruption.
    To ensure filesystem consistent when errors=remount-ro there is need to call
    ext4_handle_error() to abort journal.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240119062908.3598806-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbdev: viafb: fix typo in hw_bitblt_1 and hw_bitblt_2 [+ + +]
Author: Aleksandr Burakov <a.burakov@rosalinux.ru>
Date:   Fri Mar 1 14:35:43 2024 +0300

    fbdev: viafb: fix typo in hw_bitblt_1 and hw_bitblt_2
    
    [ Upstream commit bc87bb342f106a0402186bcb588fcbe945dced4b ]
    
    There are some actions with value 'tmp' but 'dst_addr' is checked instead.
    It is obvious that a copy-paste error was made here and the value
    of variable 'tmp' should be checked here.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Aleksandr Burakov <a.burakov@rosalinux.ru>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbmon: prevent division by zero in fb_videomode_from_videomode() [+ + +]
Author: Roman Smirnov <r.smirnov@omp.ru>
Date:   Tue Mar 19 11:13:44 2024 +0300

    fbmon: prevent division by zero in fb_videomode_from_videomode()
    
    [ Upstream commit c2d953276b8b27459baed1277a4fdd5dd9bd4126 ]
    
    The expression htotal * vtotal can have a zero value on
    overflow. It is necessary to prevent division by zero like in
    fb_var_to_videomode().
    
    Found by Linux Verification Center (linuxtesting.org) with Svace.
    
    Signed-off-by: Roman Smirnov <r.smirnov@omp.ru>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gcc-plugins/stackleak: Avoid .head.text section [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Thu Mar 28 07:42:57 2024 +0100

    gcc-plugins/stackleak: Avoid .head.text section
    
    commit e7d24c0aa8e678f41457d1304e2091cac6fd1a2e upstream.
    
    The .head.text section carries the startup code that runs with the MMU
    off or with a translation of memory that deviates from the ordinary one.
    So avoid instrumentation with the stackleak plugin, which already avoids
    .init.text and .noinstr.text entirely.
    
    Fixes: 48204aba801f1b51 ("x86/sme: Move early SME kernel encryption handling into .head.text")
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Closes: https://lore.kernel.org/oe-lkp/202403221630.2692c998-oliver.sang@intel.com
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Link: https://lore.kernel.org/r/20240328064256.2358634-2-ardb+git@google.com
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

gcc-plugins/stackleak: Ignore .noinstr.text and .entry.text [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Sun Feb 6 09:12:50 2022 -0800

    gcc-plugins/stackleak: Ignore .noinstr.text and .entry.text
    
    commit ae978009fc013e3166c9f523f8b17e41a3c0286e upstream.
    
    The .noinstr.text section functions may not have "current()" sanely
    available. Similarly true for .entry.text, though such a check is
    currently redundant. Add a check for both. In an x86_64 defconfig build,
    the following functions no longer receive stackleak instrumentation:
    
            __do_fast_syscall_32()
            do_int80_syscall_32()
            do_machine_check()
            do_syscall_64()
            exc_general_protection()
            fixup_bad_iret()
    
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Alexander Popov <alex.popov@linux.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Input: allocate keycode for Display refresh rate toggle [+ + +]
Author: Gergo Koteles <soyer@irl.hu>
Date:   Sun Mar 10 12:31:41 2024 +0100

    Input: allocate keycode for Display refresh rate toggle
    
    [ Upstream commit cfeb98b95fff25c442f78a6f616c627bc48a26b7 ]
    
    Newer Lenovo Yogas and Legions with 60Hz/90Hz displays send a wmi event
    when Fn + R is pressed. This is intended for use to switch between the
    two refresh rates.
    
    Allocate a new KEY_REFRESH_RATE_TOGGLE keycode for it.
    
    Signed-off-by: Gergo Koteles <soyer@irl.hu>
    Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Link: https://lore.kernel.org/r/15a5d08c84cf4d7b820de34ebbcf8ae2502fb3ca.1710065750.git.soyer@irl.hu
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: synaptics-rmi4 - fail probing if memory allocation for "phys" fails [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Thu Jan 18 11:37:59 2024 -0800

    Input: synaptics-rmi4 - fail probing if memory allocation for "phys" fails
    
    [ Upstream commit bc4996184d56cfaf56d3811ac2680c8a0e2af56e ]
    
    While input core can work with input->phys set to NULL userspace might
    depend on it, so better fail probing if allocation fails. The system must
    be in a pretty bad shape for it to happen anyway.
    
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Link: https://lore.kernel.org/r/20240117073124.143636-1-chentao@kylinos.cn
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ionic: set adminq irq affinity [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Wed Feb 14 09:59:01 2024 -0800

    ionic: set adminq irq affinity
    
    [ Upstream commit c699f35d658f3c21b69ed24e64b2ea26381e941d ]
    
    We claim to have the AdminQ on our irq0 and thus cpu id 0,
    but we need to be sure we set the affinity hint to try to
    keep it there.
    
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Reviewed-by: Brett Creeley <brett.creeley@amd.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
isofs: handle CDs with bad root inode but good Joliet root directory [+ + +]
Author: Alex Henrie <alexhenrie24@gmail.com>
Date:   Wed Feb 7 19:21:32 2024 -0700

    isofs: handle CDs with bad root inode but good Joliet root directory
    
    [ Upstream commit 4243bf80c79211a8ca2795401add9c4a3b1d37ca ]
    
    I have a CD copy of the original Tom Clancy's Ghost Recon game from
    2001. The disc mounts without error on Windows, but on Linux mounting
    fails with the message "isofs_fill_super: get root inode failed". The
    error originates in isofs_read_inode, which returns -EIO because de_len
    is 0. The superblock on this disc appears to be intentionally corrupt as
    a form of copy protection.
    
    When the root inode is unusable, instead of giving up immediately, try
    to continue with the Joliet file table. This fixes the Ghost Recon CD
    and probably other copy-protected CDs too.
    
    Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Message-Id: <20240208022134.451490-1-alexhenrie24@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ktest: force $buildonly = 1 for 'make_warnings_file' test type [+ + +]
Author: Ricardo B. Marliere <ricardo@marliere.net>
Date:   Fri Mar 15 12:28:08 2024 -0300

    ktest: force $buildonly = 1 for 'make_warnings_file' test type
    
    [ Upstream commit 07283c1873a4d0eaa0e822536881bfdaea853910 ]
    
    The test type "make_warnings_file" should have no mandatory configuration
    parameters other than the ones required by the "build" test type, because
    its purpose is to create a file with build warnings that may or may not be
    used by other subsequent tests. Currently, the only way to use it as a
    stand-alone test is by setting POWER_CYCLE, CONSOLE, SSH_USER,
    BUILD_TARGET, TARGET_IMAGE, REBOOT_TYPE and GRUB_MENU.
    
    Link: https://lkml.kernel.org/r/20240315-ktest-v2-1-c5c20a75f6a3@marliere.net
    
    Cc: John Hawley <warthog9@eaglescrag.net>
    Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libperf evlist: Avoid out-of-bounds access [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Wed Feb 28 23:07:57 2024 -0800

    libperf evlist: Avoid out-of-bounds access
    
    [ Upstream commit 1947b92464c3268381604bbe2ac977a3fd78192f ]
    
    Parallel testing appears to show a race between allocating and setting
    evsel ids. As there is a bounds check on the xyarray it yields a segv
    like:
    
    ```
    AddressSanitizer:DEADLYSIGNAL
    
    =================================================================
    
    ==484408==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010
    
    ==484408==The signal is caused by a WRITE memory access.
    
    ==484408==Hint: address points to the zero page.
    
        #0 0x55cef5d4eff4 in perf_evlist__id_hash tools/lib/perf/evlist.c:256
        #1 0x55cef5d4f132 in perf_evlist__id_add tools/lib/perf/evlist.c:274
        #2 0x55cef5d4f545 in perf_evlist__id_add_fd tools/lib/perf/evlist.c:315
        #3 0x55cef5a1923f in store_evsel_ids util/evsel.c:3130
        #4 0x55cef5a19400 in evsel__store_ids util/evsel.c:3147
        #5 0x55cef5888204 in __run_perf_stat tools/perf/builtin-stat.c:832
        #6 0x55cef5888c06 in run_perf_stat tools/perf/builtin-stat.c:960
        #7 0x55cef58932db in cmd_stat tools/perf/builtin-stat.c:2878
    ...
    ```
    
    Avoid this crash by early exiting the perf_evlist__id_add_fd and
    perf_evlist__id_add is the access is out-of-bounds.
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/r/20240229070757.796244-1-irogers@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.15.155 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Apr 13 13:01:48 2024 +0200

    Linux 5.15.155
    
    Link: https://lore.kernel.org/r/20240411095407.982258070@linuxfoundation.org
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: sta2x11: fix irq handler cast [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Feb 13 10:54:47 2024 +0100

    media: sta2x11: fix irq handler cast
    
    [ Upstream commit 3de49ae81c3a0f83a554ecbce4c08e019f30168e ]
    
    clang-16 warns about casting incompatible function pointers:
    
    drivers/media/pci/sta2x11/sta2x11_vip.c:1057:6: error: cast from 'irqreturn_t (*)(int, struct sta2x11_vip *)' (aka 'enum irqreturn (*)(int, struct sta2x11_vip *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
    
    Change the prototype of the irq handler to the regular version with a
    local variable to adjust the argument type.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    [hverkuil: update argument documentation]
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Mar 2 10:07:44 2024 +0000

    net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list()
    
    [ Upstream commit 00af2aa93b76b1bade471ad0d0525d4d29ca5cc0 ]
    
    Many syzbot reports show extreme rtnl pressure, and many of them hint
    that smc acquires rtnl in netns creation for no good reason [1]
    
    This patch returns early from smc_pnet_net_init()
    if there is no netdevice yet.
    
    I am not even sure why smc_pnet_create_pnetids_list() even exists,
    because smc_pnet_netdev_event() is also calling
    smc_pnet_add_base_pnetid() when handling NETDEV_UP event.
    
    [1] extract of typical syzbot reports
    
    2 locks held by syz-executor.3/12252:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.4/12253:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.1/12257:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.2/12261:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.0/12265:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.3/12268:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.4/12271:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.1/12274:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.2/12280:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Wenjia Zhang <wenjia@linux.ibm.com>
    Cc: Jan Karcher <jaka@linux.ibm.com>
    Cc: "D. Wythe" <alibuda@linux.alibaba.com>
    Cc: Tony Lu <tonylu@linux.alibaba.com>
    Cc: Wen Gu <guwen@linux.alibaba.com>
    Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240302100744.3868021-1-edumazet@google.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: dsa: fix panic when DSA master device unbinds on shutdown [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Wed Feb 9 14:04:33 2022 +0200

    net: dsa: fix panic when DSA master device unbinds on shutdown
    
    commit ee534378f00561207656663d93907583958339ae upstream.
    
    Rafael reports that on a system with LX2160A and Marvell DSA switches,
    if a reboot occurs while the DSA master (dpaa2-eth) is up, the following
    panic can be seen:
    
    systemd-shutdown[1]: Rebooting.
    Unable to handle kernel paging request at virtual address 00a0000800000041
    [00a0000800000041] address between user and kernel address ranges
    Internal error: Oops: 96000004 [#1] PREEMPT SMP
    CPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32
    pc : dsa_slave_netdevice_event+0x130/0x3e4
    lr : raw_notifier_call_chain+0x50/0x6c
    Call trace:
     dsa_slave_netdevice_event+0x130/0x3e4
     raw_notifier_call_chain+0x50/0x6c
     call_netdevice_notifiers_info+0x54/0xa0
     __dev_close_many+0x50/0x130
     dev_close_many+0x84/0x120
     unregister_netdevice_many+0x130/0x710
     unregister_netdevice_queue+0x8c/0xd0
     unregister_netdev+0x20/0x30
     dpaa2_eth_remove+0x68/0x190
     fsl_mc_driver_remove+0x20/0x5c
     __device_release_driver+0x21c/0x220
     device_release_driver_internal+0xac/0xb0
     device_links_unbind_consumers+0xd4/0x100
     __device_release_driver+0x94/0x220
     device_release_driver+0x28/0x40
     bus_remove_device+0x118/0x124
     device_del+0x174/0x420
     fsl_mc_device_remove+0x24/0x40
     __fsl_mc_device_remove+0xc/0x20
     device_for_each_child+0x58/0xa0
     dprc_remove+0x90/0xb0
     fsl_mc_driver_remove+0x20/0x5c
     __device_release_driver+0x21c/0x220
     device_release_driver+0x28/0x40
     bus_remove_device+0x118/0x124
     device_del+0x174/0x420
     fsl_mc_bus_remove+0x80/0x100
     fsl_mc_bus_shutdown+0xc/0x1c
     platform_shutdown+0x20/0x30
     device_shutdown+0x154/0x330
     __do_sys_reboot+0x1cc/0x250
     __arm64_sys_reboot+0x20/0x30
     invoke_syscall.constprop.0+0x4c/0xe0
     do_el0_svc+0x4c/0x150
     el0_svc+0x24/0xb0
     el0t_64_sync_handler+0xa8/0xb0
     el0t_64_sync+0x178/0x17c
    
    It can be seen from the stack trace that the problem is that the
    deregistration of the master causes a dev_close(), which gets notified
    as NETDEV_GOING_DOWN to dsa_slave_netdevice_event().
    But dsa_switch_shutdown() has already run, and this has unregistered the
    DSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts to
    call dev_close_many() on those slave interfaces, leading to the problem.
    
    The previous attempt to avoid the NETDEV_GOING_DOWN on the master after
    dsa_switch_shutdown() was called seems improper. Unregistering the slave
    interfaces is unnecessary and unhelpful. Instead, after the slaves have
    stopped being uppers of the DSA master, we can now reset to NULL the
    master->dsa_ptr pointer, which will make DSA start ignoring all future
    notifier events on the master.
    
    Fixes: 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown")
    Reported-by: Rafael Richter <rafael.richter@gin.de>
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: xu.xin16@zte.com.cn
    Cc: Vladimir Oltean <olteanv@gmail.com>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: pcs: xpcs: Return EINVAL in the internal methods [+ + +]
Author: Serge Semin <fancer.lancer@gmail.com>
Date:   Thu Feb 22 20:58:22 2024 +0300

    net: pcs: xpcs: Return EINVAL in the internal methods
    
    [ Upstream commit f5151005d379d9ce42e327fd3b2d2aaef61cda81 ]
    
    In particular the xpcs_soft_reset() and xpcs_do_config() functions
    currently return -1 if invalid auto-negotiation mode is specified. That
    value might be then passed to the generic kernel subsystems which require
    a standard kernel errno value. Even though the erroneous conditions are
    very specific (memory corruption or buggy driver implementation) using a
    hard-coded -1 literal doesn't seem correct anyway especially when it comes
    to passing it higher to the network subsystem or printing to the system
    log.  Convert the hard-coded error values to -EINVAL then.
    
    Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
    Tested-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: nf_tables: discard table flag update with pending basechain deletion [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Apr 8 23:19:30 2024 +0200

    netfilter: nf_tables: discard table flag update with pending basechain deletion
    
    commit 1bc83a019bbe268be3526406245ec28c2458a518 upstream.
    
    Hook unregistration is deferred to the commit phase, same occurs with
    hook updates triggered by the table dormant flag. When both commands are
    combined, this results in deleting a basechain while leaving its hook
    still registered in the core.
    
    Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: release batch on table validation from abort path [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Apr 8 23:19:28 2024 +0200

    netfilter: nf_tables: release batch on table validation from abort path
    
    commit a45e6889575c2067d3c0212b6bc1022891e65b91 upstream.
    
    Unlike early commit path stage which triggers a call to abort, an
    explicit release of the batch is required on abort, otherwise mutex is
    released and commit_list remains in place.
    
    Add WARN_ON_ONCE to ensure commit_list is empty from the abort path
    before releasing the mutex.
    
    After this patch, commit_list is always assumed to be empty before
    grabbing the mutex, therefore
    
      03c1f1ef1584 ("netfilter: Cleanup nft_net->module_list from nf_tables_exit_net()")
    
    only needs to release the pending modules for registration.
    
    Cc: stable@vger.kernel.org
    Fixes: c0391b6ab810 ("netfilter: nf_tables: missing validation from the abort path")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Apr 8 23:19:29 2024 +0200

    netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path
    
    commit 0d459e2ffb541841714839e8228b845458ed3b27 upstream.
    
    The commit mutex should not be released during the critical section
    between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC
    worker could collect expired objects and get the released commit lock
    within the same GC sequence.
    
    nf_tables_module_autoload() temporarily releases the mutex to load
    module dependencies, then it goes back to replay the transaction again.
    Move it at the end of the abort phase after nft_gc_seq_end() is called.
    
    Cc: stable@vger.kernel.org
    Fixes: 720344340fb9 ("netfilter: nf_tables: GC transaction race with abort path")
    Reported-by: Kuan-Ting Chen <hexrabbit@devco.re>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
panic: Flush kernel log buffer at the end [+ + +]
Author: John Ogness <john.ogness@linutronix.de>
Date:   Wed Feb 7 14:47:02 2024 +0106

    panic: Flush kernel log buffer at the end
    
    [ Upstream commit d988d9a9b9d180bfd5c1d353b3b176cb90d6861b ]
    
    If the kernel crashes in a context where printk() calls always
    defer printing (such as in NMI or inside a printk_safe section)
    then the final panic messages will be deferred to irq_work. But
    if irq_work is not available, the messages will not get printed
    unless explicitly flushed. The result is that the final
    "end Kernel panic" banner does not get printed.
    
    Add one final flush after the last printk() call to make sure
    the final panic messages make it out as well.
    
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20240207134103.1357162-14-john.ogness@linutronix.de
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: renesas: checker: Limit cfg reg enum checks to provided IDs [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Jan 22 14:43:38 2024 +0100

    pinctrl: renesas: checker: Limit cfg reg enum checks to provided IDs
    
    [ Upstream commit 3803584a4e9b65bb5b013f862f55c5055aa86c25 ]
    
    If the number of provided enum IDs in a variable width config register
    description does not match the expected number, the checker uses the
    expected number for validating the individual enum IDs.
    
    However, this may cause out-of-bounds accesses on the array holding the
    enum IDs, leading to bogus enum_id conflict warnings.  Worse, if the bug
    is an incorrect bit field description (e.g. accidentally using "12"
    instead of "-12" for a reserved field), thousands of warnings may be
    printed, overflowing the kernel log buffer.
    
    Fix this by limiting the enum ID check to the number of provided enum
    IDs.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/c7385f44f2faebb8856bcbb4e908d846fc1531fb.1705930809.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: intel-vbtn: Update tablet mode switch at end of probe [+ + +]
Author: Gwendal Grignou <gwendal@chromium.org>
Date:   Fri Mar 29 07:32:06 2024 -0700

    platform/x86: intel-vbtn: Update tablet mode switch at end of probe
    
    [ Upstream commit 434e5781d8cd2d0ed512d920c6cdeba4b33a2e81 ]
    
    ACER Vivobook Flip (TP401NAS) virtual intel switch is implemented as
    follow:
    
       Device (VGBI)
       {
           Name (_HID, EisaId ("INT33D6") ...
           Name (VBDS, Zero)
           Method (_STA, 0, Serialized)  // _STA: Status ...
           Method (VBDL, 0, Serialized)
           {
               PB1E |= 0x20
               VBDS |= 0x40
           }
           Method (VGBS, 0, Serialized)
           {
               Return (VBDS) /* \_SB_.PCI0.SBRG.EC0_.VGBI.VBDS */
           }
           ...
        }
    
    By default VBDS is set to 0. At boot it is set to clamshell (bit 6 set)
    only after method VBDL is executed.
    
    Since VBDL is now evaluated in the probe routine later, after the device
    is registered, the retrieved value of VBDS was still 0 ("tablet mode")
    when setting up the virtual switch.
    
    Make sure to evaluate VGBS after VBDL, to ensure the
    convertible boots in clamshell mode, the expected default.
    
    Fixes: 26173179fae1 ("platform/x86: intel-vbtn: Eval VBDL after registering our notifier")
    Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240329143206.2977734-3-gwendal@chromium.org
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: touchscreen_dmi: Add an extra entry for a variant of the Chuwi Vi8 tablet [+ + +]
Author: Alban Boyé <alban.boye@protonmail.com>
Date:   Tue Feb 27 22:40:17 2024 +0000

    platform/x86: touchscreen_dmi: Add an extra entry for a variant of the Chuwi Vi8 tablet
    
    [ Upstream commit 1266e2efb7512dbf20eac820ca2ed34de6b1c3e7 ]
    
    Signed-off-by: Alban Boyé <alban.boye@protonmail.com>
    Link: https://lore.kernel.org/r/20240227223919.11587-1-alban.boye@protonmail.com
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pstore/zone: Add a null pointer check to the psz_kmsg_read [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Thu Jan 18 18:02:06 2024 +0800

    pstore/zone: Add a null pointer check to the psz_kmsg_read
    
    [ Upstream commit 98bc7e26e14fbb26a6abf97603d59532475e97f8 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure. Ensure the allocation was successful
    by checking the pointer validity.
    
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Link: https://lore.kernel.org/r/20240118100206.213928-1-chentao@kylinos.cn
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
randomize_kstack: Improve entropy diffusion [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Sat Mar 9 12:24:48 2024 -0800

    randomize_kstack: Improve entropy diffusion
    
    [ Upstream commit 9c573cd313433f6c1f7236fe64b9b743500c1628 ]
    
    The kstack_offset variable was really only ever using the low bits for
    kernel stack offset entropy. Add a ror32() to increase bit diffusion.
    
    Suggested-by: Arnd Bergmann <arnd@arndb.de>
    Fixes: 39218ff4c625 ("stack: Optionally randomize kernel stack offset each syscall")
    Link: https://lore.kernel.org/r/20240309202445.work.165-kees@kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/cm: add timeout to cm_destroy_id wait [+ + +]
Author: Manjunath Patil <manjunath.b.patil@oracle.com>
Date:   Fri Mar 8 22:33:23 2024 -0800

    RDMA/cm: add timeout to cm_destroy_id wait
    
    [ Upstream commit 96d9cbe2f2ff7abde021bac75eafaceabe9a51fa ]
    
    Add timeout to cm_destroy_id, so that userspace can trigger any data
    collection that would help in analyzing the cause of delay in destroying
    the cm_id.
    
    New noinline function helps dtrace/ebpf programs to hook on to it.
    Existing functionality isn't changed except triggering a probe-able new
    function at every timeout interval.
    
    We have seen cases where CM messages stuck with MAD layer (either due to
    software bug or faulty HCA), leading to cm_id getting stuck in the
    following call stack. This patch helps in resolving such issues faster.
    
    kernel: ... INFO: task XXXX:56778 blocked for more than 120 seconds.
    ...
            Call Trace:
            __schedule+0x2bc/0x895
            schedule+0x36/0x7c
            schedule_timeout+0x1f6/0x31f
            ? __slab_free+0x19c/0x2ba
            wait_for_completion+0x12b/0x18a
            ? wake_up_q+0x80/0x73
            cm_destroy_id+0x345/0x610 [ib_cm]
            ib_destroy_cm_id+0x10/0x20 [ib_cm]
            rdma_destroy_id+0xa8/0x300 [rdma_cm]
            ucma_destroy_id+0x13e/0x190 [rdma_ucm]
            ucma_write+0xe0/0x160 [rdma_ucm]
            __vfs_write+0x3a/0x16d
            vfs_write+0xb2/0x1a1
            ? syscall_trace_enter+0x1ce/0x2b8
            SyS_write+0x5c/0xd3
            do_syscall_64+0x79/0x1b9
            entry_SYSCALL_64_after_hwframe+0x16d/0x0
    
    Signed-off-by: Manjunath Patil <manjunath.b.patil@oracle.com>
    Link: https://lore.kernel.org/r/20240309063323.458102-1-manjunath.b.patil@oracle.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "ACPI: CPPC: Use access_width over bit_width for system memory accesses" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Apr 12 10:23:42 2024 +0200

    Revert "ACPI: CPPC: Use access_width over bit_width for system memory accesses"
    
    This reverts commit 4949affd5288b867cdf115f5b08d6166b2027f87 which is
    commit 2f4a4d63a193be6fd530d180bb13c3592052904c upstream.
    
    It breaks AmpereOne systems and should not have been added to the stable
    tree just yet.
    
    Link: https://lore.kernel.org/r/97d25ef7-dee9-4cc5-842a-273f565869b3@linux.microsoft.com
    Reported-by: Easwar Hariharan <eahariha@linux.microsoft.com>
    Cc: Jarred White <jarredwhite@linux.microsoft.com>
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default" [+ + +]
Author: Daniel Drake <drake@endlessos.org>
Date:   Wed Feb 28 08:53:16 2024 +0100

    Revert "ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default"
    
    [ Upstream commit cb98555fcd8eee98c30165537c7e394f3a66e809 ]
    
    This reverts commit d52848620de00cde4a3a5df908e231b8c8868250, which was
    originally put in place to work around a s2idle failure on this platform
    where the NVMe device was inaccessible upon resume.
    
    After extended testing, we found that the firmware's implementation of S3
    is buggy and intermittently fails to wake up the system. We need to revert
    to s2idle mode.
    
    The NVMe issue has now been solved more precisely in the commit titled
    "PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge"
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215742
    Link: https://lore.kernel.org/r/20240228075316.7404-2-drake@endlessos.org
    Signed-off-by: Daniel Drake <drake@endlessos.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Jian-Hong Pan <jhp@endlessos.org>
    Acked-by: Rafael J. Wysocki <rafael@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ring-buffer: use READ_ONCE() to read cpu_buffer->commit_page in concurrent environment [+ + +]
Author: linke li <lilinke99@qq.com>
Date:   Sat Mar 2 12:42:21 2024 +0800

    ring-buffer: use READ_ONCE() to read cpu_buffer->commit_page in concurrent environment
    
    [ Upstream commit f1e30cb6369251c03f63c564006f96a54197dcc4 ]
    
    In function ring_buffer_iter_empty(), cpu_buffer->commit_page is read
    while other threads may change it. It may cause the time_stamp that read
    in the next line come from a different page. Use READ_ONCE() to avoid
    having to reason about compiler optimizations now and in future.
    
    Link: https://lore.kernel.org/linux-trace-kernel/tencent_DFF7D3561A0686B5E8FC079150A02505180A@qq.com
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: linke li <lilinke99@qq.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc() [+ + +]
Author: Justin Tee <justin.tee@broadcom.com>
Date:   Wed Jan 31 10:50:57 2024 -0800

    scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
    
    [ Upstream commit 2ae917d4bcab80ab304b774d492e2fcd6c52c06b ]
    
    The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an
    unsuccessful status.  In such cases, the elsiocb is not issued, the
    completion is not called, and thus the elsiocb resource is leaked.
    
    Check return value after calling lpfc_sli4_resume_rpi() and conditionally
    release the elsiocb resource.
    
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Link: https://lore.kernel.org/r/20240131185112.149731-3-justintee8345@gmail.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
SUNRPC: increase size of rpc_wait_queue.qlen from unsigned short to unsigned int [+ + +]
Author: Dai Ngo <dai.ngo@oracle.com>
Date:   Tue Jan 30 11:38:25 2024 -0800

    SUNRPC: increase size of rpc_wait_queue.qlen from unsigned short to unsigned int
    
    [ Upstream commit 2c35f43b5a4b9cdfaa6fdd946f5a212615dac8eb ]
    
    When the NFS client is under extreme load the rpc_wait_queue.qlen counter
    can be overflowed. Here is an instant of the backlog queue overflow in a
    real world environment shown by drgn helper:
    
    rpc_task_stats(rpc_clnt):
    -------------------------
    rpc_clnt: 0xffff92b65d2bae00
    rpc_xprt: 0xffff9275db64f000
      Queue:  sending[64887] pending[524] backlog[30441] binding[0]
    XMIT task: 0xffff925c6b1d8e98
         WRITE: 750654
            __dta_call_status_580: 65463
            __dta_call_transmit_status_579: 1
            call_reserveresult: 685189
            nfs_client_init_is_complete: 1
        COMMIT: 584
            call_reserveresult: 573
            __dta_call_status_580: 11
        ACCESS: 1
            __dta_call_status_580: 1
       GETATTR: 10
            __dta_call_status_580: 4
            call_reserveresult: 6
    751249 tasks for server 111.222.333.444
    Total tasks: 751249
    
    count_rpc_wait_queues(xprt):
    ----------------------------
    **** rpc_xprt: 0xffff9275db64f000 num_reqs: 65511
    wait_queue: xprt_binding[0] cnt: 0
    wait_queue: xprt_binding[1] cnt: 0
    wait_queue: xprt_binding[2] cnt: 0
    wait_queue: xprt_binding[3] cnt: 0
    rpc_wait_queue[xprt_binding].qlen: 0 maxpriority: 0
    wait_queue: xprt_sending[0] cnt: 0
    wait_queue: xprt_sending[1] cnt: 64887
    wait_queue: xprt_sending[2] cnt: 0
    wait_queue: xprt_sending[3] cnt: 0
    rpc_wait_queue[xprt_sending].qlen: 64887 maxpriority: 3
    wait_queue: xprt_pending[0] cnt: 524
    wait_queue: xprt_pending[1] cnt: 0
    wait_queue: xprt_pending[2] cnt: 0
    wait_queue: xprt_pending[3] cnt: 0
    rpc_wait_queue[xprt_pending].qlen: 524 maxpriority: 0
    wait_queue: xprt_backlog[0] cnt: 0
    wait_queue: xprt_backlog[1] cnt: 685801
    wait_queue: xprt_backlog[2] cnt: 0
    wait_queue: xprt_backlog[3] cnt: 0
    rpc_wait_queue[xprt_backlog].qlen: 30441 maxpriority: 3 [task cnt mismatch]
    
    There is no effect on operations when this overflow occurs. However
    it causes confusion when trying to diagnose the performance problem.
    
    Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sysv: don't call sb_bread() with pointers_lock held [+ + +]
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon Apr 10 21:04:50 2023 +0900

    sysv: don't call sb_bread() with pointers_lock held
    
    [ Upstream commit f123dc86388cb669c3d6322702dc441abc35c31e ]
    
    syzbot is reporting sleep in atomic context in SysV filesystem [1], for
    sb_bread() is called with rw_spinlock held.
    
    A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug
    and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by
    "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
    
    Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the
    former bug by moving pointers_lock lock to the callers, but instead
    introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made
    this problem easier to hit).
    
    Al Viro suggested that why not to do like get_branch()/get_block()/
    find_shared() in Minix filesystem does. And doing like that is almost a
    revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()
     from with find_shared() is called without write_lock(&pointers_lock).
    
    Reported-by: syzbot <syzbot+69b40dc5fd40f32c199f@syzkaller.appspotmail.com>
    Link: https://syzkaller.appspot.com/bug?extid=69b40dc5fd40f32c199f
    Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Link: https://lore.kernel.org/r/0d195f93-a22a-49a2-0020-103534d6f7f6@I-love.SAKURA.ne.jp
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools/power x86_energy_perf_policy: Fix file leak in get_pkg_num() [+ + +]
Author: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
Date:   Tue Feb 13 16:19:56 2024 -0800

    tools/power x86_energy_perf_policy: Fix file leak in get_pkg_num()
    
    [ Upstream commit f85450f134f0b4ca7e042dc3dc89155656a2299d ]
    
    In function get_pkg_num() if fopen_or_die() succeeds it returns a file
    pointer to be used. But fclose() is never called before returning from
    the function.
    
    Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools: iio: replace seekdir() in iio_generic_buffer [+ + +]
Author: Petre Rodan <petre.rodan@subdimension.ro>
Date:   Mon Jan 8 12:32:20 2024 +0200

    tools: iio: replace seekdir() in iio_generic_buffer
    
    [ Upstream commit 4e6500bfa053dc133021f9c144261b77b0ba7dc8 ]
    
    Replace seekdir() with rewinddir() in order to fix a localized glibc bug.
    
    One of the glibc patches that stable Gentoo is using causes an improper
    directory stream positioning bug on 32bit arm. That in turn ends up as a
    floating point exception in iio_generic_buffer.
    
    The attached patch provides a fix by using an equivalent function which
    should not cause trouble for other distros and is easier to reason about
    in general as it obviously always goes back to to the start.
    
    https://sourceware.org/bugzilla/show_bug.cgi?id=31212
    
    Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro>
    Link: https://lore.kernel.org/r/20240108103224.3986-1-petre.rodan@subdimension.ro
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc [+ + +]
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Mon Jul 31 15:59:42 2023 -0300

    tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
    
    commit 67c37756898a5a6b2941a13ae7260c89b54e0d88 upstream.
    
    Any unprivileged user can attach N_GSM0710 ldisc, but it requires
    CAP_NET_ADMIN to create a GSM network anyway.
    
    Require initial namespace CAP_NET_ADMIN to do that.
    
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Link: https://lore.kernel.org/r/20230731185942.279611-1-cascardo@canonical.com
    Cc: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: sl811-hcd: only defined function checkdone if QUIRK2 is defined [+ + +]
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Thu Mar 7 11:13:51 2024 +0000

    usb: sl811-hcd: only defined function checkdone if QUIRK2 is defined
    
    [ Upstream commit 12f371e2b6cb4b79c788f1f073992e115f4ca918 ]
    
    Function checkdone is only required if QUIRK2 is defined, so add
    appropriate #if / #endif around the function.
    
    Cleans up clang scan build warning:
    drivers/usb/host/sl811-hcd.c:588:18: warning: unused function
    'checkdone' [-Wunused-function]
    
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Link: https://lore.kernel.org/r/20240307111351.1982382-1-colin.i.king@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: typec: tcpci: add generic tcpci fallback compatible [+ + +]
Author: Marco Felsch <m.felsch@pengutronix.de>
Date:   Thu Feb 22 22:09:01 2024 +0100

    usb: typec: tcpci: add generic tcpci fallback compatible
    
    [ Upstream commit 8774ea7a553e2aec323170d49365b59af0a2b7e0 ]
    
    The driver already support the tcpci binding for the i2c_device_id so
    add the support for the of_device_id too.
    
    Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240222210903.208901-3-m.felsch@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio: reenable config if freezing device failed [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Tue Feb 13 14:54:25 2024 +0100

    virtio: reenable config if freezing device failed
    
    commit 310227f42882c52356b523e2f4e11690eebcd2ab upstream.
    
    Currently, we don't reenable the config if freezing the device failed.
    
    For example, virtio-mem currently doesn't support suspend+resume, and
    trying to freeze the device will always fail. Afterwards, the device
    will no longer respond to resize requests, because it won't get notified
    about config changes.
    
    Let's fix this by re-enabling the config if freezing fails.
    
    Fixes: 22b7050a024d ("virtio: defer config changed notifications")
    Cc: <stable@kernel.org>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Jason Wang <jasowang@redhat.com>
    Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Message-Id: <20240213135425.795001-1-david@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host() [+ + +]
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Fri Jan 5 08:40:00 2024 -0800

    VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()
    
    [ Upstream commit 19b070fefd0d024af3daa7329cbc0d00de5302ec ]
    
    Syzkaller hit 'WARNING in dg_dispatch_as_host' bug.
    
    memcpy: detected field-spanning write (size 56) of single field "&dg_info->msg"
    at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24)
    
    WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237
    dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237
    
    Some code commentry, based on my understanding:
    
    544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size)
    /// This is 24 + payload_size
    
    memcpy(&dg_info->msg, dg, dg_size);
            Destination = dg_info->msg ---> this is a 24 byte
                                            structure(struct vmci_datagram)
            Source = dg --> this is a 24 byte structure (struct vmci_datagram)
            Size = dg_size = 24 + payload_size
    
    {payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32.
    
     35 struct delayed_datagram_info {
     36         struct datagram_entry *entry;
     37         struct work_struct work;
     38         bool in_dg_host_queue;
     39         /* msg and msg_payload must be together. */
     40         struct vmci_datagram msg;
     41         u8 msg_payload[];
     42 };
    
    So those extra bytes of payload are copied into msg_payload[], a run time
    warning is seen while fuzzing with Syzkaller.
    
    One possible way to fix the warning is to split the memcpy() into
    two parts -- one -- direct assignment of msg and second taking care of payload.
    
    Gustavo quoted:
    "Under FORTIFY_SOURCE we should not copy data across multiple members
    in a structure."
    
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Suggested-by: Vegard Nossum <vegard.nossum@oracle.com>
    Suggested-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/20240105164001.2129796-2-harshit.m.mogalapalli@oracle.com
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

VMCI: Fix possible memcpy() run-time warning in vmci_datagram_invoke_guest_handler() [+ + +]
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date:   Mon Feb 19 13:53:15 2024 +0300

    VMCI: Fix possible memcpy() run-time warning in vmci_datagram_invoke_guest_handler()
    
    commit e606e4b71798cc1df20e987dde2468e9527bd376 upstream.
    
    The changes are similar to those given in the commit 19b070fefd0d
    ("VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()").
    
    Fix filling of the msg and msg_payload in dg_info struct, which prevents a
    possible "detected field-spanning write" of memcpy warning that is issued
    by the tracking mechanism __fortify_memcpy_chk.
    
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Link: https://lore.kernel.org/r/20240219105315.76955-1-kovalev@altlinux.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: ath11k: decrease MHI channel buffer length to 8KB [+ + +]
Author: Baochen Qiang <quic_bqiang@quicinc.com>
Date:   Fri Feb 23 13:31:11 2024 +0800

    wifi: ath11k: decrease MHI channel buffer length to 8KB
    
    [ Upstream commit 1cca1bddf9ef080503c15378cecf4877f7510015 ]
    
    Currently buf_len field of ath11k_mhi_config_qca6390 is assigned
    with 0, making MHI use a default size, 64KB, to allocate channel
    buffers. This is likely to fail in some scenarios where system
    memory is highly fragmented and memory compaction or reclaim is
    not allowed.
    
    There is a fail report which is caused by it:
    kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
    CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb
    Workqueue: events_unbound async_run_entry_fn
    Call Trace:
     <TASK>
     dump_stack_lvl+0x47/0x60
     warn_alloc+0x13a/0x1b0
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? __alloc_pages_direct_compact+0xab/0x210
     __alloc_pages_slowpath.constprop.0+0xd3e/0xda0
     __alloc_pages+0x32d/0x350
     ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
     __kmalloc_large_node+0x72/0x110
     __kmalloc+0x37c/0x480
     ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
     ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
     mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
     __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
     ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
     device_for_each_child+0x5c/0xa0
     ? __pfx_pci_pm_resume+0x10/0x10
     ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e]
     ? srso_alias_return_thunk+0x5/0xfbef5
     ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec]
     ? srso_alias_return_thunk+0x5/0xfbef5
     dpm_run_callback+0x8c/0x1e0
     device_resume+0x104/0x340
     ? __pfx_dpm_watchdog_handler+0x10/0x10
     async_resume+0x1d/0x30
     async_run_entry_fn+0x32/0x120
     process_one_work+0x168/0x330
     worker_thread+0x2f5/0x410
     ? __pfx_worker_thread+0x10/0x10
     kthread+0xe8/0x120
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x34/0x50
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1b/0x30
     </TASK>
    
    Actually those buffers are used only by QMI target -> host communication.
    And for WCN6855 and QCA6390, the largest packet size for that is less
    than 6KB. So change buf_len field to 8KB, which results in order 1
    allocation if page size is 4KB. In this way, we can at least save some
    memory, and as well as decrease the possibility of allocation failure
    in those scenarios.
    
    Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
    
    Reported-by: Vlastimil Babka <vbabka@suse.cz>
    Closes: https://lore.kernel.org/ath11k/96481a45-3547-4d23-ad34-3a8f1d90c1cd@suse.cz/
    Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
    Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://msgid.link/20240223053111.29170-1-quic_bqiang@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: ath9k: fix LNA selection in ath_ant_try_scan() [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Sun Dec 17 13:29:03 2023 +0200

    wifi: ath9k: fix LNA selection in ath_ant_try_scan()
    
    [ Upstream commit d6b27eb997ef9a2aa51633b3111bc4a04748e6d3 ]
    
    In 'ath_ant_try_scan()', (most likely) the 2nd LNA's signal
    strength should be used in comparison against RSSI when
    selecting first LNA as the main one. Compile tested only.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://msgid.link/20231211172502.25202-1-dmantipov@yandex.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/mm/pat: fix VM_PAT handling in COW mappings [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Wed Apr 3 23:21:30 2024 +0200

    x86/mm/pat: fix VM_PAT handling in COW mappings
    
    commit 04c35ab3bdae7fefbd7c7a7355f29fa03a035221 upstream.
    
    PAT handling won't do the right thing in COW mappings: the first PTE (or,
    in fact, all PTEs) can be replaced during write faults to point at anon
    folios.  Reliably recovering the correct PFN and cachemode using
    follow_phys() from PTEs will not work in COW mappings.
    
    Using follow_phys(), we might just get the address+protection of the anon
    folio (which is very wrong), or fail on swap/nonswap entries, failing
    follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
    track_pfn_copy(), not properly calling free_pfn_range().
    
    In free_pfn_range(), we either wouldn't call memtype_free() or would call
    it with the wrong range, possibly leaking memory.
    
    To fix that, let's update follow_phys() to refuse returning anon folios,
    and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings
    if we run into that.
    
    We will now properly handle untrack_pfn() with COW mappings, where we
    don't need the cachemode.  We'll have to fail fork()->track_pfn_copy() if
    the first page was replaced by an anon folio, though: we'd have to store
    the cachemode in the VMA to make this work, likely growing the VMA size.
    
    For now, lets keep it simple and let track_pfn_copy() just fail in that
    case: it would have failed in the past with swap/nonswap entries already,
    and it would have done the wrong thing with anon folios.
    
    Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
    
    <--- C reproducer --->
     #include <stdio.h>
     #include <sys/mman.h>
     #include <unistd.h>
     #include <liburing.h>
    
     int main(void)
     {
             struct io_uring_params p = {};
             int ring_fd;
             size_t size;
             char *map;
    
             ring_fd = io_uring_setup(1, &p);
             if (ring_fd < 0) {
                     perror("io_uring_setup");
                     return 1;
             }
             size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
    
             /* Map the submission queue ring MAP_PRIVATE */
             map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
                        ring_fd, IORING_OFF_SQ_RING);
             if (map == MAP_FAILED) {
                     perror("mmap");
                     return 1;
             }
    
             /* We have at least one page. Let's COW it. */
             *map = 0;
             pause();
             return 0;
     }
    <--- C reproducer --->
    
    On a system with 16 GiB RAM and swap configured:
     # ./iouring &
     # memhog 16G
     # killall iouring
    [  301.552930] ------------[ cut here ]------------
    [  301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100
    [  301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g
    [  301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1
    [  301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4
    [  301.559569] RIP: 0010:untrack_pfn+0xf4/0x100
    [  301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000
    [  301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282
    [  301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047
    [  301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200
    [  301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000
    [  301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000
    [  301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000
    [  301.564186] FS:  0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000
    [  301.564773] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0
    [  301.565725] PKRU: 55555554
    [  301.565944] Call Trace:
    [  301.566148]  <TASK>
    [  301.566325]  ? untrack_pfn+0xf4/0x100
    [  301.566618]  ? __warn+0x81/0x130
    [  301.566876]  ? untrack_pfn+0xf4/0x100
    [  301.567163]  ? report_bug+0x171/0x1a0
    [  301.567466]  ? handle_bug+0x3c/0x80
    [  301.567743]  ? exc_invalid_op+0x17/0x70
    [  301.568038]  ? asm_exc_invalid_op+0x1a/0x20
    [  301.568363]  ? untrack_pfn+0xf4/0x100
    [  301.568660]  ? untrack_pfn+0x65/0x100
    [  301.568947]  unmap_single_vma+0xa6/0xe0
    [  301.569247]  unmap_vmas+0xb5/0x190
    [  301.569532]  exit_mmap+0xec/0x340
    [  301.569801]  __mmput+0x3e/0x130
    [  301.570051]  do_exit+0x305/0xaf0
    ...
    
    Link: https://lkml.kernel.org/r/20240403212131.929421-3-david@redhat.com
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reported-by: Wupeng Ma <mawupeng1@huawei.com>
    Closes: https://lkml.kernel.org/r/20240227122814.3781907-1-mawupeng1@huawei.com
    Fixes: b1a86e15dc03 ("x86, pat: remove the dependency on 'vm_pgoff' in track/untrack pfn vma routines")
    Fixes: 5899329b1910 ("x86: PAT: implement track/untrack of pfnmap regions for x86 - v3")
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>