Linux 5.4.260

 
arm64: fix a concurrency issue in emulation_proc_handler() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Mon Oct 30 06:37:09 2023 +0000

    arm64: fix a concurrency issue in emulation_proc_handler()
    
    In linux-6.1, the related code is refactored in commit 124c49b1b5d9
    ("arm64: armv8_deprecated: rework deprected instruction handling") and this
    issue was incidentally fixed. I have adapted the patch set to linux stable
    5.10. However, 4.19 and 5.10 are too different and the patch set is
    hard to adapt to 4.19.
    
    This patch is to solve the problem of repeated addition of linked lists
    described below with few changes.
    
    How to reproduce:
    CONFIG_ARMV8_DEPRECATED=y, CONFIG_SWP_EMULATION=y, and CONFIG_DEBUG_LIST=y,
    then launch two shell executions:
           #!/bin/bash
           while [ 1 ];
           do
               echo 1 > /proc/sys/abi/swp
           done
    
    or "echo 1 > /proc/sys/abi/swp" and then aunch two shell executions:
           #!/bin/bash
           while [ 1 ];
           do
               echo 0 > /proc/sys/abi/swp
           done
    
    In emulation_proc_handler(), read and write operations are performed on
    insn->current_mode. In the concurrency scenario, mutex only protects
    writing insn->current_mode, and not protects the read. Suppose there are
    two concurrent tasks, task1 updates insn->current_mode to INSN_EMULATE
    in the critical section, the prev_mode of task2 is still the old data
    INSN_UNDEF of insn->current_mode. As a result, two tasks call
    update_insn_emulation_mode twice with prev_mode = INSN_UNDEF and
    current_mode = INSN_EMULATE, then call register_emulation_hooks twice,
    resulting in a list_add double problem.
    
    After applying this patch, the following list add or list del double
    warnings never occur.
    
    Call trace:
     __list_add_valid+0xd8/0xe4
     register_undef_hook+0x94/0x13c
     update_insn_emulation_mode+0xd0/0x12c
     emulation_proc_handler+0xd8/0xf4
     proc_sys_call_handler+0x140/0x250
     proc_sys_write+0x1c/0x2c
     new_sync_write+0xec/0x18c
     vfs_write+0x214/0x2ac
     ksys_write+0x70/0xfc
     __arm64_sys_write+0x24/0x30
     el0_svc_common.constprop.0+0x7c/0x1bc
     do_el0_svc+0x2c/0x94
     el0_svc+0x20/0x30
     el0_sync_handler+0xb0/0xb4
     el0_sync+0x160/0x180
    
    Call trace:
     __list_del_entry_valid+0xac/0x110
     unregister_undef_hook+0x34/0x80
     update_insn_emulation_mode+0xf0/0x180
     emulation_proc_handler+0x8c/0xd8
     proc_sys_call_handler+0x1d8/0x208
     proc_sys_write+0x14/0x20
     new_sync_write+0xf0/0x190
     vfs_write+0x304/0x388
     ksys_write+0x6c/0x100
     __arm64_sys_write+0x1c/0x28
     el0_svc_common.constprop.4+0x68/0x188
     do_el0_svc+0x24/0xa0
     el0_svc+0x14/0x20
     el0_sync_handler+0x90/0xb8
     el0_sync+0x160/0x180
    
    Fixes: af483947d472 ("arm64: fix oops in concurrently setting insn_emulation sysctls")
    Cc: [email protected]#4.19.x
    Cc: [email protected]
    Signed-off-by: Jinjie Ruan <[email protected]>
    Acked-by: Mark Rutland <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ASoC: rt5650: fix the wrong result of key button [+ + +]
Author: Shuming Fan <[email protected]>
Date:   Fri Oct 13 17:45:25 2023 +0800

    ASoC: rt5650: fix the wrong result of key button
    
    [ Upstream commit f88dfbf333b3661faff996bb03af2024d907b76a ]
    
    The RT5650 should enable a power setting for button detection to avoid the wrong result.
    
    Signed-off-by: Shuming Fan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ata: ahci: fix enum constants for gcc-13 [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Sat Dec 3 11:54:25 2022 +0100

    ata: ahci: fix enum constants for gcc-13
    
    commit f07788079f515ca4a681c5f595bdad19cfbd7b1d upstream.
    
    gcc-13 slightly changes the type of constant expressions that are defined
    in an enum, which triggers a compile time sanity check in libata:
    
    linux/drivers/ata/libahci.c: In function 'ahci_led_store':
    linux/include/linux/compiler_types.h:357:45: error: call to '__compiletime_assert_302' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
    357 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
    
    The new behavior is that sizeof() returns the same value for the
    constant as it does for the enum type, which is generally more sensible
    and consistent.
    
    The problem in libata is that it contains a single enum definition for
    lots of unrelated constants, some of which are large positive (unsigned)
    integers like 0xffffffff, while others like (1<<31) are interpreted as
    negative integers, and this forces the enum type to become 64 bit wide
    even though most constants would still fit into a signed 32-bit 'int'.
    
    Fix this by changing the entire enum definition to use BIT(x) in place
    of (1<<x), which results in all values being seen as 'unsigned' and
    fitting into an unsigned 32-bit type.
    
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107917
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
    Reported-by: Luis Machado <[email protected]>
    Cc: [email protected]
    Cc: Damien Le Moal <[email protected]>
    Cc: [email protected]
    Cc: Randy Dunlap <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Tested-by: Luis Machado <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    [Backport to linux-5.4.y]
    Signed-off-by: Paul Barker <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
clk: Sanitize possible_parent_show to Handle Return Value of of_clk_get_parent_name [+ + +]
Author: Alessandro Carminati <[email protected]>
Date:   Thu Sep 21 07:32:17 2023 +0000

    clk: Sanitize possible_parent_show to Handle Return Value of of_clk_get_parent_name
    
    commit ceb87a361d0b079ecbc7d2831618c19087f304a9 upstream.
    
    In the possible_parent_show function, ensure proper handling of the return
    value from of_clk_get_parent_name to prevent potential issues arising from
    a NULL return.
    The current implementation invokes seq_puts directly on the result of
    of_clk_get_parent_name without verifying the return value, which can lead
    to kernel panic if the function returns NULL.
    
    This patch addresses the concern by introducing a check on the return
    value of of_clk_get_parent_name. If the return value is not NULL, the
    function proceeds to call seq_puts, providing the returned value as
    argument.
    However, if of_clk_get_parent_name returns NULL, the function provides a
    static string as argument, avoiding the panic.
    
    Fixes: 1ccc0ddf046a ("clk: Use seq_puts() in possible_parent_show()")
    Reported-by: Philip Daly <[email protected]>
    Signed-off-by: Alessandro Carminati (Red Hat) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dmaengine: ste_dma40: Fix PM disable depth imbalance in d40_probe [+ + +]
Author: Zhang Shurong <[email protected]>
Date:   Thu Oct 5 22:28:35 2023 +0800

    dmaengine: ste_dma40: Fix PM disable depth imbalance in d40_probe
    
    [ Upstream commit 0618c077a8c20e8c81e367988f70f7e32bb5a717 ]
    
    The pm_runtime_enable will increase power disable depth. Thus
    a pairing decrement is needed on the error handling path to
    keep it balanced according to context.
    We fix it by calling pm_runtime_disable when error returns.
    
    Signed-off-by: Zhang Shurong <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
driver: platform: Add helper for safer setting of driver_override [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Oct 31 11:37:43 2023 +0000

    driver: platform: Add helper for safer setting of driver_override
    
    commit 6c2f421174273de8f83cde4286d1c076d43a2d35 upstream.
    
    Several core drivers and buses expect that driver_override is a
    dynamically allocated memory thus later they can kfree() it.
    
    However such assumption is not documented, there were in the past and
    there are already users setting it to a string literal. This leads to
    kfree() of static memory during device release (e.g. in error paths or
    during unbind):
    
        kernel BUG at ../mm/slub.c:3960!
        Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
        ...
        (kfree) from [<c058da50>] (platform_device_release+0x88/0xb4)
        (platform_device_release) from [<c0585be0>] (device_release+0x2c/0x90)
        (device_release) from [<c0a69050>] (kobject_put+0xec/0x20c)
        (kobject_put) from [<c0f2f120>] (exynos5_clk_probe+0x154/0x18c)
        (exynos5_clk_probe) from [<c058de70>] (platform_drv_probe+0x6c/0xa4)
        (platform_drv_probe) from [<c058b7ac>] (really_probe+0x280/0x414)
        (really_probe) from [<c058baf4>] (driver_probe_device+0x78/0x1c4)
        (driver_probe_device) from [<c0589854>] (bus_for_each_drv+0x74/0xb8)
        (bus_for_each_drv) from [<c058b48c>] (__device_attach+0xd4/0x16c)
        (__device_attach) from [<c058a638>] (bus_probe_device+0x88/0x90)
        (bus_probe_device) from [<c05871fc>] (device_add+0x3dc/0x62c)
        (device_add) from [<c075ff10>] (of_platform_device_create_pdata+0x94/0xbc)
        (of_platform_device_create_pdata) from [<c07600ec>] (of_platform_bus_create+0x1a8/0x4fc)
        (of_platform_bus_create) from [<c0760150>] (of_platform_bus_create+0x20c/0x4fc)
        (of_platform_bus_create) from [<c07605f0>] (of_platform_populate+0x84/0x118)
        (of_platform_populate) from [<c0f3c964>] (of_platform_default_populate_init+0xa0/0xb8)
        (of_platform_default_populate_init) from [<c01031f8>] (do_one_initcall+0x8c/0x404)
    
    Provide a helper which clearly documents the usage of driver_override.
    This will allow later to reuse the helper and reduce the amount of
    duplicated code.
    
    Convert the platform driver to use a new helper and make the
    driver_override field const char (it is not modified by the core).
    
    Reviewed-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/dp_mst: Fix NULL deref in get_mst_branch_device_by_guid_helper() [+ + +]
Author: Lukasz Majczak <[email protected]>
Date:   Fri Sep 22 08:34:10 2023 +0200

    drm/dp_mst: Fix NULL deref in get_mst_branch_device_by_guid_helper()
    
    commit 3d887d512494d678b17c57b835c32f4e48d34f26 upstream.
    
    As drm_dp_get_mst_branch_device_by_guid() is called from
    drm_dp_get_mst_branch_device_by_guid(), mstb parameter has to be checked,
    otherwise NULL dereference may occur in the call to
    the memcpy() and cause following:
    
    [12579.365869] BUG: kernel NULL pointer dereference, address: 0000000000000049
    [12579.365878] #PF: supervisor read access in kernel mode
    [12579.365880] #PF: error_code(0x0000) - not-present page
    [12579.365882] PGD 0 P4D 0
    [12579.365887] Oops: 0000 [#1] PREEMPT SMP NOPTI
    ...
    [12579.365895] Workqueue: events_long drm_dp_mst_up_req_work
    [12579.365899] RIP: 0010:memcmp+0xb/0x29
    [12579.365921] Call Trace:
    [12579.365927] get_mst_branch_device_by_guid_helper+0x22/0x64
    [12579.365930] drm_dp_mst_up_req_work+0x137/0x416
    [12579.365933] process_one_work+0x1d0/0x419
    [12579.365935] worker_thread+0x11a/0x289
    [12579.365938] kthread+0x13e/0x14f
    [12579.365941] ? process_one_work+0x419/0x419
    [12579.365943] ? kthread_blkcg+0x31/0x31
    [12579.365946] ret_from_fork+0x1f/0x30
    
    As get_mst_branch_device_by_guid_helper() is recursive, moving condition
    to the first line allow to remove a similar one for step over of NULL elements
    inside a loop.
    
    Fixes: 5e93b8208d3c ("drm/dp/mst: move GUID storage from mgr, port to only mst branch")
    Cc: <[email protected]> # 4.14+
    Signed-off-by: Lukasz Majczak <[email protected]>
    Reviewed-by: Radoslaw Biernacki <[email protected]>
    Signed-off-by: Manasi Navare <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ext4: add two helper functions extent_logical_end() and pa_logical_end() [+ + +]
Author: Baokun Li <[email protected]>
Date:   Sat Oct 28 14:53:29 2023 +0800

    ext4: add two helper functions extent_logical_end() and pa_logical_end()
    
    commit 43bbddc067883d94de7a43d5756a295439fbe37d upstream.
    
    When we use lstart + len to calculate the end of free extent or prealloc
    space, it may exceed the maximum value of 4294967295(0xffffffff) supported
    by ext4_lblk_t and cause overflow, which may lead to various problems.
    
    Therefore, we add two helper functions, extent_logical_end() and
    pa_logical_end(), to limit the type of end to loff_t, and also convert
    lstart to loff_t for calculation to avoid overflow.
    
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Baokun Li <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: avoid overlapping preallocations due to overflow [+ + +]
Author: Baokun Li <[email protected]>
Date:   Sat Oct 28 14:53:31 2023 +0800

    ext4: avoid overlapping preallocations due to overflow
    
    commit bedc5d34632c21b5adb8ca7143d4c1f794507e4c upstream.
    
    Let's say we want to allocate 2 blocks starting from 4294966386, after
    predicting the file size, start is aligned to 4294965248, len is changed
    to 2048, then end = start + size = 0x100000000. Since end is of
    type ext4_lblk_t, i.e. uint, end is truncated to 0.
    
    This causes (pa->pa_lstart >= end) to always hold when checking if the
    current extent to be allocated crosses already preallocated blocks, so the
    resulting ac_g_ex may cross already preallocated blocks. Hence we convert
    the end type to loff_t and use pa_logical_end() to avoid overflow.
    
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Baokun Li <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow [+ + +]
Author: Baokun Li <[email protected]>
Date:   Sat Oct 28 14:53:30 2023 +0800

    ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow
    
    commit bc056e7163ac7db945366de219745cf94f32a3e6 upstream.
    
    When we calculate the end position of ext4_free_extent, this position may
    be exactly where ext4_lblk_t (i.e. uint) overflows. For example, if
    ac_g_ex.fe_logical is 4294965248 and ac_orig_goal_len is 2048, then the
    computed end is 0x100000000, which is 0. If ac->ac_o_ex.fe_logical is not
    the first case of adjusting the best extent, that is, new_bex_end > 0, the
    following BUG_ON will be triggered:
    
    =========================================================
    kernel BUG at fs/ext4/mballoc.c:5116!
    invalid opcode: 0000 [#1] PREEMPT SMP PTI
    CPU: 3 PID: 673 Comm: xfs_io Tainted: G E 6.5.0-rc1+ #279
    RIP: 0010:ext4_mb_new_inode_pa+0xc5/0x430
    Call Trace:
     <TASK>
     ext4_mb_use_best_found+0x203/0x2f0
     ext4_mb_try_best_found+0x163/0x240
     ext4_mb_regular_allocator+0x158/0x1550
     ext4_mb_new_blocks+0x86a/0xe10
     ext4_ext_map_blocks+0xb0c/0x13a0
     ext4_map_blocks+0x2cd/0x8f0
     ext4_iomap_begin+0x27b/0x400
     iomap_iter+0x222/0x3d0
     __iomap_dio_rw+0x243/0xcb0
     iomap_dio_rw+0x16/0x80
    =========================================================
    
    A simple reproducer demonstrating the problem:
    
            mkfs.ext4 -F /dev/sda -b 4096 100M
            mount /dev/sda /tmp/test
            fallocate -l1M /tmp/test/tmp
            fallocate -l10M /tmp/test/file
            fallocate -i -o 1M -l16777203M /tmp/test/file
            fsstress -d /tmp/test -l 0 -n 100000 -p 8 &
            sleep 10 && killall -9 fsstress
            rm -f /tmp/test/tmp
            xfs_io -c "open -ad /tmp/test/file" -c "pwrite -S 0xff 0 8192"
    
    We simply refactor the logic for adjusting the best extent by adding
    a temporary ext4_free_extent ex and use extent_logical_end() to avoid
    overflow, which also simplifies the code.
    
    Cc: [email protected] # 6.4
    Fixes: 93cdf49f6eca ("ext4: Fix best extent lstart adjustment logic in ext4_mb_new_inode_pa()")
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Baokun Li <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
f2fs: fix to do sanity check on inode type during garbage collection [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Dec 6 22:44:19 2021 +0800

    f2fs: fix to do sanity check on inode type during garbage collection
    
    commit 9056d6489f5a41cfbb67f719d2c0ce61ead72d9f upstream.
    
    As report by Wenqing Liu in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=215231
    
    - Overview
    kernel NULL pointer dereference triggered  in folio_mark_dirty() when mount and operate on a crafted f2fs image
    
    - Reproduce
    tested on kernel 5.16-rc3, 5.15.X under root
    
    1. mkdir mnt
    2. mount -t f2fs tmp1.img mnt
    3. touch tmp
    4. cp tmp mnt
    
    F2FS-fs (loop0): sanity_check_inode: inode (ino=49) extent info [5942, 4294180864, 4] is incorrect, run fsck to fix
    F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=31340049, run fsck to fix.
    BUG: kernel NULL pointer dereference, address: 0000000000000000
     folio_mark_dirty+0x33/0x50
     move_data_page+0x2dd/0x460 [f2fs]
     do_garbage_collect+0xc18/0x16a0 [f2fs]
     f2fs_gc+0x1d3/0xd90 [f2fs]
     f2fs_balance_fs+0x13a/0x570 [f2fs]
     f2fs_create+0x285/0x840 [f2fs]
     path_openat+0xe6d/0x1040
     do_filp_open+0xc5/0x140
     do_sys_openat2+0x23a/0x310
     do_sys_open+0x57/0x80
    
    The root cause is for special file: e.g. character, block, fifo or socket file,
    f2fs doesn't assign address space operations pointer array for mapping->a_ops field,
    so, in a fuzzed image, SSA table indicates a data block belong to special file, when
    f2fs tries to migrate that block, it causes NULL pointer access once move_data_page()
    calls a_ops->set_dirty_page().
    
    Cc: [email protected]
    Reported-by: Wenqing Liu <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Kazunori Kobayashi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fbdev: atyfb: only use ioremap_uc() on i386 and ia64 [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Thu Sep 21 19:04:21 2023 +0800

    fbdev: atyfb: only use ioremap_uc() on i386 and ia64
    
    [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ]
    
    ioremap_uc() is only meaningful on old x86-32 systems with the PAT
    extension, and on ia64 with its slightly unconventional ioremap()
    behavior, everywhere else this is the same as ioremap() anyway.
    
    Change the only driver that still references ioremap_uc() to only do so
    on x86-32/ia64 in order to allow removing that interface at some
    point in the future for the other architectures.
    
    On some architectures, ioremap_uc() just returns NULL, changing
    the driver to call ioremap() means that they now have a chance
    of working correctly.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Baoquan He <[email protected]>
    Reviewed-by: Luis Chamberlain <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Christophe Leroy <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fbdev: uvesafb: Call cn_del_callback() at the end of uvesafb_exit() [+ + +]
Author: Jorge Maidana <[email protected]>
Date:   Fri Oct 6 17:43:47 2023 -0300

    fbdev: uvesafb: Call cn_del_callback() at the end of uvesafb_exit()
    
    [ Upstream commit 1022e7e2f40574c74ed32c3811b03d26b0b81daf ]
    
    Delete the v86d netlink only after all the VBE tasks have been
    completed.
    
    Fixes initial state restore on module unload:
    uvesafb: VBE state restore call failed (eax=0x4f04, err=-19)
    
    Signed-off-by: Jorge Maidana <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gtp: fix fragmentation needed check with gso [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Sun Oct 22 22:25:18 2023 +0200

    gtp: fix fragmentation needed check with gso
    
    [ Upstream commit 4530e5b8e2dad63dcad2206232dd86e4b1489b6c ]
    
    Call skb_gso_validate_network_len() to check if packet is over PMTU.
    
    Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gtp: uapi: fix GTPA_MAX [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Sun Oct 22 22:25:17 2023 +0200

    gtp: uapi: fix GTPA_MAX
    
    [ Upstream commit adc8df12d91a2b8350b0cd4c7fec3e8546c9d1f8 ]
    
    Subtract one to __GTPA_MAX, otherwise GTPA_MAX is off by 2.
    
    Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
i2c: aspeed: Fix i2c bus hang in slave read [+ + +]
Author: Jian Zhang <[email protected]>
Date:   Fri Oct 6 10:22:33 2023 +0800

    i2c: aspeed: Fix i2c bus hang in slave read
    
    commit 54f1840ddee9bbdc8dd89fbbfdfa632401244146 upstream.
    
    When the `CONFIG_I2C_SLAVE` option is enabled and the device operates
    as a slave, a situation arises where the master sends a START signal
    without the accompanying STOP signal. This action results in a
    persistent I2C bus timeout. The core issue stems from the fact that
    the i2c controller remains in a slave read state without a timeout
    mechanism. As a consequence, the bus perpetually experiences timeouts.
    
    In this case, the i2c bus will be reset, but the slave_state reset is
    missing.
    
    Fixes: fee465150b45 ("i2c: aspeed: Reset the i2c controller when timeout occurs")
    Signed-off-by: Jian Zhang <[email protected]>
    Acked-by: Andi Shyti <[email protected]>
    Tested-by: Andrew Jeffery <[email protected]>
    Reviewed-by: Andrew Jeffery <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: muxes: i2c-demux-pinctrl: Use of_get_i2c_adapter_by_node() [+ + +]
Author: Herve Codina <[email protected]>
Date:   Fri Oct 20 17:30:12 2023 +0200

    i2c: muxes: i2c-demux-pinctrl: Use of_get_i2c_adapter_by_node()
    
    commit 0fb118de5003028ad092a4e66fc6d07b86c3bc94 upstream.
    
    i2c-demux-pinctrl uses the pair of_find_i2c_adapter_by_node() /
    i2c_put_adapter(). These pair alone is not correct to properly lock the
    I2C parent adapter.
    
    Indeed, i2c_put_adapter() decrements the module refcount while
    of_find_i2c_adapter_by_node() does not increment it. This leads to an
    underflow of the parent module refcount.
    
    Use the dedicated function, of_get_i2c_adapter_by_node(), to handle
    correctly the module refcount.
    
    Fixes: 50a5ba876908 ("i2c: mux: demux-pinctrl: add driver")
    Signed-off-by: Herve Codina <[email protected]>
    Cc: [email protected]
    Acked-by: Peter Rosin <[email protected]>
    Reviewed-by: Jonathan Cameron <Jo[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: muxes: i2c-mux-gpmux: Use of_get_i2c_adapter_by_node() [+ + +]
Author: Herve Codina <[email protected]>
Date:   Fri Oct 20 17:30:13 2023 +0200

    i2c: muxes: i2c-mux-gpmux: Use of_get_i2c_adapter_by_node()
    
    commit 3dc0ec46f6e7511fc4fdf6b6cda439382bc957f1 upstream.
    
    i2c-mux-gpmux uses the pair of_find_i2c_adapter_by_node() /
    i2c_put_adapter(). These pair alone is not correct to properly lock the
    I2C parent adapter.
    
    Indeed, i2c_put_adapter() decrements the module refcount while
    of_find_i2c_adapter_by_node() does not increment it. This leads to an
    underflow of the parent module refcount.
    
    Use the dedicated function, of_get_i2c_adapter_by_node(), to handle
    correctly the module refcount.
    
    Fixes: ac8498f0ce53 ("i2c: i2c-mux-gpmux: new driver")
    Signed-off-by: Herve Codina <[email protected]>
    Cc: [email protected]
    Acked-by: Peter Rosin <[email protected]>
    Reviewed-by: Jonathan Cameron <Jonathan.Camero[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: muxes: i2c-mux-pinctrl: Use of_get_i2c_adapter_by_node() [+ + +]
Author: Herve Codina <[email protected]>
Date:   Fri Oct 20 17:30:11 2023 +0200

    i2c: muxes: i2c-mux-pinctrl: Use of_get_i2c_adapter_by_node()
    
    commit 3171d37b58a76e1febbf3f4af2d06234a98cf88b upstream.
    
    i2c-mux-pinctrl uses the pair of_find_i2c_adapter_by_node() /
    i2c_put_adapter(). These pair alone is not correct to properly lock the
    I2C parent adapter.
    
    Indeed, i2c_put_adapter() decrements the module refcount while
    of_find_i2c_adapter_by_node() does not increment it. This leads to an
    underflow of the parent module refcount.
    
    Use the dedicated function, of_get_i2c_adapter_by_node(), to handle
    correctly the module refcount.
    
    Fixes: c4aee3e1b0de ("i2c: mux: pinctrl: remove platform_data")
    Signed-off-by: Herve Codina <[email protected]>
    Cc: [email protected]
    Acked-by: Peter Rosin <[email protected]>
    Reviewed-by: Jonathan Cameron <Jo[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: stm32f7: Fix PEC handling in case of SMBUS transfers [+ + +]
Author: Alain Volmat <[email protected]>
Date:   Tue Oct 10 10:44:54 2023 +0200

    i2c: stm32f7: Fix PEC handling in case of SMBUS transfers
    
    commit c896ff2dd8f30a6b0a922c83a96f6d43f05f0e92 upstream.
    
    In case of SMBUS byte read with PEC enabled, the whole transfer
    is split into two commands.  A first write command, followed by
    a read command.  The write command does not have any PEC byte
    and a PEC byte is appended at the end of the read command.
    (cf Read byte protocol with PEC in SMBUS specification)
    
    Within the STM32 I2C controller, handling (either sending
    or receiving) of the PEC byte is done via the PECBYTE bit in
    register CR2.
    
    Currently, the PECBYTE is set at the beginning of a transfer,
    which lead to sending a PEC byte at the end of the write command
    (hence losing the real last byte), and also does not check the
    PEC byte received during the read command.
    
    This patch corrects the function stm32f7_i2c_smbus_xfer_msg
    in order to only set the PECBYTE during the read command.
    
    Fixes: 9e48155f6bfe ("i2c: i2c-stm32f7: Add initial SMBus protocols support")
    Signed-off-by: Alain Volmat <[email protected]>
    Reviewed-by: Pierre-Yves MORDRET <[email protected]>
    Acked-by: Andi Shyti <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i40e: Fix wrong check for I40E_TXR_FLAGS_WB_ON_ITR [+ + +]
Author: Ivan Vecera <[email protected]>
Date:   Mon Oct 23 14:27:14 2023 -0700

    i40e: Fix wrong check for I40E_TXR_FLAGS_WB_ON_ITR
    
    [ Upstream commit 77a8c982ff0d4c3a14022c6fe9e3dbfb327552ec ]
    
    The I40E_TXR_FLAGS_WB_ON_ITR is i40e_ring flag and not i40e_pf one.
    
    Fixes: 8e0764b4d6be42 ("i40e/i40evf: Add support for writeback on ITR feature for X722")
    Signed-off-by: Ivan Vecera <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Jacob Keller <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
igb: Fix potential memory leak in igb_add_ethtool_nfc_entry [+ + +]
Author: Mateusz Palczewski <[email protected]>
Date:   Thu Oct 19 13:40:35 2023 -0700

    igb: Fix potential memory leak in igb_add_ethtool_nfc_entry
    
    [ Upstream commit 8c0b48e01daba5ca58f939a8425855d3f4f2ed14 ]
    
    Add check for return of igb_update_ethtool_nfc_entry so that in case
    of any potential errors the memory alocated for input will be freed.
    
    Fixes: 0e71def25281 ("igb: add support of RX network flow classification")
    Reviewed-by: Wojciech Drewek <[email protected]>
    Signed-off-by: Mateusz Palczewski <[email protected]>
    Tested-by: Arpana Arland <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Jacob Keller <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
igc: Fix ambiguity in the ethtool advertising [+ + +]
Author: Sasha Neftin <[email protected]>
Date:   Thu Oct 19 13:36:41 2023 -0700

    igc: Fix ambiguity in the ethtool advertising
    
    [ Upstream commit e7684d29efdf37304c62bb337ea55b3428ca118e ]
    
    The 'ethtool_convert_link_mode_to_legacy_u32' method does not allow us to
    advertise 2500M speed support and TP (twisted pair) properly. Convert to
    'ethtool_link_ksettings_test_link_mode' to advertise supported speed and
    eliminate ambiguity.
    
    Fixes: 8c5ad0dae93c ("igc: Add ethtool support")
    Suggested-by: Dima Ruinskiy <[email protected]>
    Suggested-by: Vitaly Lifshits <[email protected]>
    Signed-off-by: Sasha Neftin <[email protected]>
    Tested-by: Naama Meir <[email protected]>
    Signed-off-by: Jacob Keller <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iio: exynos-adc: request second interupt only when touchscreen mode is used [+ + +]
Author: Marek Szyprowski <[email protected]>
Date:   Mon Oct 9 12:14:12 2023 +0200

    iio: exynos-adc: request second interupt only when touchscreen mode is used
    
    commit 865b080e3229102f160889328ce2e8e97aa65ea0 upstream.
    
    Second interrupt is needed only when touchscreen mode is used, so don't
    request it unconditionally. This removes the following annoying warning
    during boot:
    
    exynos-adc 14d10000.adc: error -ENXIO: IRQ index 1 not found
    
    Fixes: 2bb8ad9b44c5 ("iio: exynos-adc: add experimental touchscreen support")
    Signed-off-by: Marek Szyprowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Input: i8042 - add Fujitsu Lifebook E5411 to i8042 quirk table [+ + +]
Author: Szilard Fabian <[email protected]>
Date:   Wed Oct 4 05:47:01 2023 -0700

    Input: i8042 - add Fujitsu Lifebook E5411 to i8042 quirk table
    
    [ Upstream commit 80f39e1c27ba9e5a1ea7e68e21c569c9d8e46062 ]
    
    In the initial boot stage the integrated keyboard of Fujitsu Lifebook E5411
    refuses to work and it's not possible to type for example a dm-crypt
    passphrase without the help of an external keyboard.
    
    i8042.nomux kernel parameter resolves this issue but using that a PS/2
    mouse is detected. This input device is unused even when the i2c-hid-acpi
    kernel module is blacklisted making the integrated ELAN touchpad
    (04F3:308A) not working at all.
    
    Since the integrated touchpad is managed by the i2c_designware input
    driver in the Linux kernel and you can't find a PS/2 mouse port on the
    computer I think it's safe to not use the PS/2 mouse port at all.
    
    Signed-off-by: Szilard Fabian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Input: synaptics-rmi4 - handle reset delay when using SMBus trsnsport [+ + +]
Author: Dmitry Torokhov <[email protected]>
Date:   Fri Oct 13 17:29:57 2023 -0700

    Input: synaptics-rmi4 - handle reset delay when using SMBus trsnsport
    
    [ Upstream commit 5030b2fe6aab37fe42d14f31842ea38be7c55c57 ]
    
    Touch controllers need some time after receiving reset command for the
    firmware to finish re-initializing and be ready to respond to commands
    from the host. The driver already had handling for the post-reset delay
    for I2C and SPI transports, this change adds the handling to
    SMBus-connected devices.
    
    SMBus devices are peculiar because they implement legacy PS/2
    compatibility mode, so reset is actually issued by psmouse driver on the
    associated serio port, after which the control is passed to the RMI4
    driver with SMBus companion device.
    
    Note that originally the delay was added to psmouse driver in
    92e24e0e57f7 ("Input: psmouse - add delay when deactivating for SMBus
    mode"), but that resulted in an unwanted delay in "fast" reconnect
    handler for the serio port, so it was decided to revert the patch and
    have the delay being handled in the RMI4 driver, similar to the other
    transports.
    
    Tested-by: Jeffery Miller <[email protected]>
    Link: https://lore.kernel.org/r/ZR1yUFJ8a9Zt606N@penguin
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
irqchip/stm32-exti: add missing DT IRQ flag translation [+ + +]
Author: Ben Wolsieffer <[email protected]>
Date:   Tue Oct 3 12:20:03 2023 -0400

    irqchip/stm32-exti: add missing DT IRQ flag translation
    
    [ Upstream commit 8554cba1d6dbd3c74e0549e28ddbaccbb1d6b30a ]
    
    The STM32F4/7 EXTI driver was missing the xlate callback, so IRQ trigger
    flags specified in the device tree were being ignored. This was
    preventing the RTC alarm interrupt from working, because it must be set
    to trigger on the rising edge to function correctly.
    
    Signed-off-by: Ben Wolsieffer <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
kobject: Fix slab-out-of-bounds in fill_kobj_path() [+ + +]
Author: Wang Hai <[email protected]>
Date:   Tue Dec 20 09:21:43 2022 +0800

    kobject: Fix slab-out-of-bounds in fill_kobj_path()
    
    commit 3bb2a01caa813d3a1845d378bbe4169ef280d394 upstream.
    
    In kobject_get_path(), if kobj->name is changed between calls
    get_kobj_path_length() and fill_kobj_path() and the length becomes
    longer, then fill_kobj_path() will have an out-of-bounds bug.
    
    The actual current problem occurs when the ixgbe probe.
    
    In ixgbe_mii_bus_init(), if the length of netdev->dev.kobj.name
    length becomes longer, out-of-bounds will occur.
    
    cpu0                                         cpu1
    ixgbe_probe
     register_netdev(netdev)
      netdev_register_kobject
       device_add
        kobject_uevent // Sending ADD events
                                                 systemd-udevd // rename netdev
                                                  dev_change_name
                                                   device_rename
                                                    kobject_rename
     ixgbe_mii_bus_init                             |
      mdiobus_register                              |
       __mdiobus_register                           |
        device_register                             |
         device_add                                 |
          kobject_uevent                            |
           kobject_get_path                         |
            len = get_kobj_path_length // old name  |
            path = kzalloc(len, gfp_mask);          |
                                                    kobj->name = name;
                                                    /* name length becomes
                                                     * longer
                                                     */
            fill_kobj_path /* kobj path length is
                            * longer than path,
                            * resulting in out of
                            * bounds when filling path
                            */
    
    This is the kasan report:
    
    ==================================================================
    BUG: KASAN: slab-out-of-bounds in fill_kobj_path+0x50/0xc0
    Write of size 7 at addr ff1100090573d1fd by task kworker/28:1/673
    
     Workqueue: events work_for_cpu_fn
     Call Trace:
     <TASK>
     dump_stack_lvl+0x34/0x48
     print_address_description.constprop.0+0x86/0x1e7
     print_report+0x36/0x4f
     kasan_report+0xad/0x130
     kasan_check_range+0x35/0x1c0
     memcpy+0x39/0x60
     fill_kobj_path+0x50/0xc0
     kobject_get_path+0x5a/0xc0
     kobject_uevent_env+0x140/0x460
     device_add+0x5c7/0x910
     __mdiobus_register+0x14e/0x490
     ixgbe_probe.cold+0x441/0x574 [ixgbe]
     local_pci_probe+0x78/0xc0
     work_for_cpu_fn+0x26/0x40
     process_one_work+0x3b6/0x6a0
     worker_thread+0x368/0x520
     kthread+0x165/0x1a0
     ret_from_fork+0x1f/0x30
    
    This reproducer triggers that bug:
    
    while:
    do
        rmmod ixgbe
        sleep 0.5
        modprobe ixgbe
        sleep 0.5
    
    When calling fill_kobj_path() to fill path, if the name length of
    kobj becomes longer, return failure and retry. This fixes the problem.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Wang Hai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Oleksandr Tymoshenko <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 5.4.260 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed Nov 8 11:23:43 2023 +0100

    Linux 5.4.260
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Harshit Mogalapalli <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mcb-lpc: Reallocate memory region to avoid memory overlapping [+ + +]
Author: Rodríguez Barbarin, José Javier <[email protected]>
Date:   Tue Apr 11 10:33:29 2023 +0200

    mcb-lpc: Reallocate memory region to avoid memory overlapping
    
    [ Upstream commit 2025b2ca8004c04861903d076c67a73a0ec6dfca ]
    
    mcb-lpc requests a fixed-size memory region to parse the chameleon
    table, however, if the chameleon table is smaller that the allocated
    region, it could overlap with the IP Cores' memory regions.
    
    After parsing the chameleon table, drop/reallocate the memory region
    with the actual chameleon table size.
    
    Co-developed-by: Jorge Sanjuan Garcia <[email protected]>
    Signed-off-by: Jorge Sanjuan Garcia <[email protected]>
    Signed-off-by: Javier Rodriguez <[email protected]>
    Signed-off-by: Johannes Thumshirn <[email protected]>
    Link: https://lore.kernel.org/r/20230411083329.4506-4-jth@kernel.org
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mcb: Return actual parsed size when reading chameleon table [+ + +]
Author: Rodríguez Barbarin, José Javier <[email protected]>
Date:   Tue Apr 11 10:33:27 2023 +0200

    mcb: Return actual parsed size when reading chameleon table
    
    [ Upstream commit a889c276d33d333ae96697510f33533f6e9d9591 ]
    
    The function chameleon_parse_cells() returns the number of cells
    parsed which has an undetermined size. This return value is only
    used for error checking but the number of cells is never used.
    
    Change return value to be number of bytes parsed to allow for
    memory management improvements.
    
    Co-developed-by: Jorge Sanjuan Garcia <[email protected]>
    Signed-off-by: Jorge Sanjuan Garcia <[email protected]>
    Signed-off-by: Javier Rodriguez <[email protected]>
    Signed-off-by: Johannes Thumshirn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mtd: rawnand: marvell: Ensure program page operations are successful [+ + +]
Author: Miquel Raynal <[email protected]>
Date:   Mon Jul 17 21:42:19 2023 +0200

    mtd: rawnand: marvell: Ensure program page operations are successful
    
    [ Upstream commit 3e01d5254698ea3d18e09d96b974c762328352cd ]
    
    The NAND core complies with the ONFI specification, which itself
    mentions that after any program or erase operation, a status check
    should be performed to see whether the operation was finished *and*
    successful.
    
    The NAND core offers helpers to finish a page write (sending the
    "PAGE PROG" command, waiting for the NAND chip to be ready again, and
    checking the operation status). But in some cases, advanced controller
    drivers might want to optimize this and craft their own page write
    helper to leverage additional hardware capabilities, thus not always
    using the core facilities.
    
    Some drivers, like this one, do not use the core helper to finish a page
    write because the final cycles are automatically managed by the
    hardware. In this case, the additional care must be taken to manually
    perform the final status check.
    
    Let's read the NAND chip status at the end of the page write helper and
    return -EIO upon error.
    
    Cc: [email protected]
    Fixes: 02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver")
    Reported-by: Aviram Dali <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Tested-by: Ravi Chandra Minnikanti <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>
 
neighbour: fix various data-races [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Oct 19 12:21:04 2023 +0000

    neighbour: fix various data-races
    
    [ Upstream commit a9beb7e81bcb876615e1fbb3c07f3f9dba69831f ]
    
    1) tbl->gc_thresh1, tbl->gc_thresh2, tbl->gc_thresh3 and tbl->gc_interval
       can be written from sysfs.
    
    2) tbl->last_flush is read locklessly from neigh_alloc()
    
    3) tbl->proxy_queue.qlen is read locklessly from neightbl_fill_info()
    
    4) neightbl_fill_info() reads cpu stats that can be changed concurrently.
    
    Fixes: c7fb64db001f ("[NETLINK]: Neighbour table configuration and statistics via rtnetlink")
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: chelsio: cxgb4: add an error code check in t4_load_phy_fw [+ + +]
Author: Su Hui <[email protected]>
Date:   Fri Oct 20 17:27:59 2023 +0800

    net: chelsio: cxgb4: add an error code check in t4_load_phy_fw
    
    [ Upstream commit 9f771493da935299c6393ad3563b581255d01a37 ]
    
    t4_set_params_timeout() can return -EINVAL if failed, add check
    for this.
    
    Signed-off-by: Su Hui <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ieee802154: adf7242: Fix some potential buffer overflow in adf7242_stats_show() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Oct 21 20:03:53 2023 +0200

    net: ieee802154: adf7242: Fix some potential buffer overflow in adf7242_stats_show()
    
    [ Upstream commit ca082f019d8fbb983f03080487946da714154bae ]
    
    strncat() usage in adf7242_debugfs_init() is wrong.
    The size given to strncat() is the maximum number of bytes that can be
    written, excluding the trailing NULL.
    
    Here, the size that is passed, DNAME_INLINE_LEN, does not take into account
    the size of "adf7242-" that is already in the array.
    
    In order to fix it, use snprintf() instead.
    
    Fixes: 7302b9d90117 ("ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: nfnetlink_log: silence bogus compiler warning [+ + +]
Author: Florian Westphal <[email protected]>
Date:   Thu Oct 5 10:53:08 2023 +0200

    netfilter: nfnetlink_log: silence bogus compiler warning
    
    [ Upstream commit 2e1d175410972285333193837a4250a74cd472e6 ]
    
    net/netfilter/nfnetlink_log.c:800:18: warning: variable 'ctinfo' is uninitialized
    
    The warning is bogus, the variable is only used if ct is non-NULL and
    always initialised in that case.  Init to 0 too to silence this.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfsd: lock_rename() needs both directories to live on the same fs [+ + +]
Author: Al Viro <[email protected]>
Date:   Sat Oct 14 21:34:40 2023 -0400

    nfsd: lock_rename() needs both directories to live on the same fs
    
    commit 1aee9158bc978f91701c5992e395efbc6da2de3c upstream.
    
    ... checking that after lock_rename() is too late.  Incidentally,
    NFSv2 had no nfserr_xdev...
    
    Fixes: aa387d6ce153 "nfsd: fix EXDEV checking in rename"
    Cc: [email protected] # v3.9+
    Reviewed-by: Jeff Layton <[email protected]>
    Acked-by: Chuck Lever <[email protected]>
    Tested-by: Jeff Layton <[email protected]>
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nvmem: imx: correct nregs for i.MX6SLL [+ + +]
Author: Peng Fan <[email protected]>
Date:   Fri Oct 13 13:49:02 2023 +0100

    nvmem: imx: correct nregs for i.MX6SLL
    
    commit 414a98abbefd82d591f4e2d1efd2917bcd3b6f6d upstream.
    
    The nregs for i.MX6SLL should be 80 per fuse map, correct it.
    
    Fixes: 6da27821a6f5 ("nvmem: imx-ocotp: add support for imx6sll")
    Cc: [email protected]
    Signed-off-by: Peng Fan <[email protected]>
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nvmem: imx: correct nregs for i.MX6UL [+ + +]
Author: Peng Fan <[email protected]>
Date:   Fri Oct 13 13:49:03 2023 +0100

    nvmem: imx: correct nregs for i.MX6UL
    
    commit 7d6e10f5d254681983b53d979422c8de3fadbefb upstream.
    
    The nregs for i.MX6UL should be 144 per fuse map, correct it.
    
    Fixes: 4aa2b4802046 ("nvmem: octop: Add support for imx6ul")
    Cc: [email protected]
    Signed-off-by: Peng Fan <[email protected]>
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nvmem: imx: correct nregs for i.MX6ULL [+ + +]
Author: Peng Fan <[email protected]>
Date:   Fri Oct 13 13:49:04 2023 +0100

    nvmem: imx: correct nregs for i.MX6ULL
    
    commit 2382c1b044231fd49eaf9aa82bc7113fc55487b8 upstream.
    
    The nregs for i.MX6ULL should be 80 per fuse map, correct it.
    
    Fixes: ffbc34bf0e9c ("nvmem: imx-ocotp: Implement i.MX6ULL/ULZ support")
    Cc: [email protected]
    Signed-off-by: Peng Fan <[email protected]>
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nvmet-tcp: Fix a possible UAF in queue intialization setup [+ + +]
Author: Sagi Grimberg <[email protected]>
Date:   Mon Oct 2 13:54:28 2023 +0300

    nvmet-tcp: Fix a possible UAF in queue intialization setup
    
    commit d920abd1e7c4884f9ecd0749d1921b7ab19ddfbd upstream.
    
    From Alon:
    "Due to a logical bug in the NVMe-oF/TCP subsystem in the Linux kernel,
    a malicious user can cause a UAF and a double free, which may lead to
    RCE (may also lead to an LPE in case the attacker already has local
    privileges)."
    
    Hence, when a queue initialization fails after the ahash requests are
    allocated, it is guaranteed that the queue removal async work will be
    called, hence leave the deallocation to the queue removal.
    
    Also, be extra careful not to continue processing the socket, so set
    queue rcv_state to NVMET_TCP_RECV_ERR upon a socket error.
    
    Cc: [email protected]
    Reported-by: Alon Zahavi <[email protected]>
    Tested-by: Alon Zahavi <z[email protected]>
    Signed-off-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Dragos-Marian Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nvmet-tcp: move send/recv error handling in the send/recv methods instead of call-sites [+ + +]
Author: Sagi Grimberg <[email protected]>
Date:   Mon May 18 10:47:48 2020 -0700

    nvmet-tcp: move send/recv error handling in the send/recv methods instead of call-sites
    
    commit 0236d3437909ff888e5c79228e2d5a851651c4c6 upstream.
    
    Have routines handle errors and just bail out of the poll loop.
    This simplifies the code and will help as we may enhance the poll
    loop logic and these are somewhat in the way.
    
    Signed-off-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Dragos-Marian Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
PCI: Prevent xHCI driver from claiming AMD VanGogh USB3 DRD device [+ + +]
Author: Vicki Pfau <[email protected]>
Date:   Wed Sep 27 13:22:12 2023 -0700

    PCI: Prevent xHCI driver from claiming AMD VanGogh USB3 DRD device
    
    commit 7e6f3b6d2c352b5fde37ce3fed83bdf6172eebd4 upstream.
    
    The AMD VanGogh SoC contains a DesignWare USB3 Dual-Role Device that can be
    operated as either a USB Host or a USB Device, similar to on the AMD Nolan
    platform.
    
    be6646bfbaec ("PCI: Prevent xHCI driver from claiming AMD Nolan USB3 DRD
    device") added a quirk to let the dwc3 driver claim the Nolan device since
    it provides more specific support.
    
    Extend that quirk to include the VanGogh SoC USB3 device.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vicki Pfau <[email protected]>
    [bhelgaas: include be6646bfbaec reference, add stable tag]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Cc: [email protected]      # v3.19+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
perf/core: Fix potential NULL deref [+ + +]
Author: Peter Zijlstra <[email protected]>
Date:   Tue Oct 24 11:42:21 2023 +0200

    perf/core: Fix potential NULL deref
    
    commit a71ef31485bb51b846e8db8b3a35e432cc15afb5 upstream.
    
    Smatch is awesome.
    
    Fixes: 32671e3799ca ("perf: Disallow mis-matched inherited group reads")
    Reported-by: Dan Carpenter <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
platform/mellanox: mlxbf-tmfifo: Fix a warning message [+ + +]
Author: Liming Sun <[email protected]>
Date:   Thu Oct 12 19:02:35 2023 -0400

    platform/mellanox: mlxbf-tmfifo: Fix a warning message
    
    [ Upstream commit 99c09c985e5973c8f0ad976ebae069548dd86f12 ]
    
    This commit fixes the smatch static checker warning in function
    mlxbf_tmfifo_rxtx_word() which complains data not initialized at
    line 634 when IS_VRING_DROP() is TRUE.
    
    Signed-off-by: Liming Sun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code from 0x20 to 0x2e [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Tue Oct 17 11:07:23 2023 +0200

    platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code from 0x20 to 0x2e
    
    [ Upstream commit f37cc2fc277b371fc491890afb7d8a26e36bb3a1 ]
    
    Older Asus laptops change the backlight level themselves and then send
    WMI events with different codes for different backlight levels.
    
    The asus-wmi.c code maps the entire range of codes reported on
    brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code:
    
    define NOTIFY_BRNUP_MIN                0x11
    define NOTIFY_BRNUP_MAX                0x1f
    define NOTIFY_BRNDOWN_MIN              0x20
    define NOTIFY_BRNDOWN_MAX              0x2e
    
            if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
                    code = ASUS_WMI_BRN_UP;
            else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
                    code = ASUS_WMI_BRN_DOWN;
    
    Before this commit all the NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX
    aka 0x20 - 0x2e events were mapped to 0x20.
    
    This mapping is causing issues on new laptop models which actually
    send 0x2b events for printscreen presses and 0x2c events for
    capslock presses, which get translated into spurious brightness-down
    presses.
    
    The plan is disable the 0x11-0x2e special mapping on laptops
    where asus-wmi does not register a backlight-device to avoid
    the spurious brightness-down keypresses. New laptops always send
    0x2e for brightness-down presses, change the special internal
    ASUS_WMI_BRN_DOWN value from 0x20 to 0x2e to match this in
    preparation for fixing the spurious brightness-down presses.
    
    This change does not have any functional impact since all
    of 0x20 - 0x2e is mapped to ASUS_WMI_BRN_DOWN first and only
    then checked against the keymap code and the new 0x2e
    value is still in the 0x20 - 0x2e range.
    
    Reported-by: James John <[email protected]>
    Closes: https://lore.kernel.org/platform-driver-x86/[email protected]/
    Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
r8152: Cancel hw_phy_work if we have an error in probe [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Fri Oct 20 14:06:54 2023 -0700

    r8152: Cancel hw_phy_work if we have an error in probe
    
    [ Upstream commit bb8adff9123e492598162ac1baad01a53891aef6 ]
    
    The error handling in rtl8152_probe() is missing a call to cancel the
    hw_phy_work. Add it in to match what's in the cleanup code in
    rtl8152_disconnect().
    
    Fixes: a028a9e003f2 ("r8152: move the settings of PHY to a work queue")
    Signed-off-by: Douglas Anderson <[email protected]>
    Reviewed-by: Grant Grundler <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

r8152: Increase USB control msg timeout to 5000ms as per spec [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Fri Oct 20 14:06:52 2023 -0700

    r8152: Increase USB control msg timeout to 5000ms as per spec
    
    [ Upstream commit a5feba71ec9c14a54c3babdc732c5b6866d8ee43 ]
    
    According to the comment next to USB_CTRL_GET_TIMEOUT and
    USB_CTRL_SET_TIMEOUT, although sending/receiving control messages is
    usually quite fast, the spec allows them to take up to 5 seconds.
    Let's increase the timeout in the Realtek driver from 500ms to 5000ms
    (using the #defines) to account for this.
    
    This is not just a theoretical change. The need for the longer timeout
    was seen in testing. Specifically, if you drop a sc7180-trogdor based
    Chromebook into the kdb debugger and then "go" again after sitting in
    the debugger for a while, the next USB control message takes a long
    time. Out of ~40 tests the slowest USB control message was 4.5
    seconds.
    
    While dropping into kdb is not exactly an end-user scenario, the above
    is similar to what could happen due to an temporary interrupt storm,
    what could happen if there was a host controller (HW or SW) issue, or
    what could happen if the Realtek device got into a confused state and
    needed time to recover.
    
    This change is fairly critical since the r8152 driver in Linux doesn't
    expect register reads/writes (which are backed by USB control
    messages) to fail.
    
    Fixes: ac718b69301c ("net/usb: new driver for RTL8152")
    Suggested-by: Hayes Wang <[email protected]>
    Signed-off-by: Douglas Anderson <[email protected]>
    Reviewed-by: Grant Grundler <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

r8152: Run the unload routine if we have errors during probe [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Fri Oct 20 14:06:53 2023 -0700

    r8152: Run the unload routine if we have errors during probe
    
    [ Upstream commit 5dd17689526971c5ae12bc8398f34bd68cd0499e ]
    
    The rtl8152_probe() function lacks a call to the chip-specific
    unload() routine when it sees an error in probe. Add it in to match
    the cleanup code in rtl8152_disconnect().
    
    Fixes: ac718b69301c ("net/usb: new driver for RTL8152")
    Signed-off-by: Douglas Anderson <[email protected]>
    Reviewed-by: Grant Grundler <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
r8169: fix the KCSAN reported data race in rtl_rx while reading desc->opts1 [+ + +]
Author: Mirsad Goran Todorovac <[email protected]>
Date:   Wed Oct 18 21:34:38 2023 +0200

    r8169: fix the KCSAN reported data race in rtl_rx while reading desc->opts1
    
    [ Upstream commit f97eee484e71890131f9c563c5cc6d5a69e4308d ]
    
    KCSAN reported the following data-race bug:
    
    ==================================================================
    BUG: KCSAN: data-race in rtl8169_poll (drivers/net/ethernet/realtek/r8169_main.c:4430 drivers/net/ethernet/realtek/r8169_main.c:4583) r8169
    
    race at unknown origin, with read to 0xffff888117e43510 of 4 bytes by interrupt on cpu 21:
    rtl8169_poll (drivers/net/ethernet/realtek/r8169_main.c:4430 drivers/net/ethernet/realtek/r8169_main.c:4583) r8169
    __napi_poll (net/core/dev.c:6527)
    net_rx_action (net/core/dev.c:6596 net/core/dev.c:6727)
    __do_softirq (kernel/softirq.c:553)
    __irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632)
    irq_exit_rcu (kernel/softirq.c:647)
    sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1074 (discriminator 14))
    asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:645)
    cpuidle_enter_state (drivers/cpuidle/cpuidle.c:291)
    cpuidle_enter (drivers/cpuidle/cpuidle.c:390)
    call_cpuidle (kernel/sched/idle.c:135)
    do_idle (kernel/sched/idle.c:219 kernel/sched/idle.c:282)
    cpu_startup_entry (kernel/sched/idle.c:378 (discriminator 1))
    start_secondary (arch/x86/kernel/smpboot.c:210 arch/x86/kernel/smpboot.c:294)
    secondary_startup_64_no_verify (arch/x86/kernel/head_64.S:433)
    
    value changed: 0x80003fff -> 0x3402805f
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 21 PID: 0 Comm: swapper/21 Tainted: G             L     6.6.0-rc2-kcsan-00143-gb5cbe7c00aa0 #41
    Hardware name: ASRock X670E PG Lightning/X670E PG Lightning, BIOS 1.21 04/26/2023
    ==================================================================
    
    drivers/net/ethernet/realtek/r8169_main.c:
    ==========================================
       4429
     → 4430                 status = le32_to_cpu(desc->opts1);
       4431                 if (status & DescOwn)
       4432                         break;
       4433
       4434                 /* This barrier is needed to keep us from reading
       4435                  * any other fields out of the Rx descriptor until
       4436                  * we know the status of DescOwn
       4437                  */
       4438                 dma_rmb();
       4439
       4440                 if (unlikely(status & RxRES)) {
       4441                         if (net_ratelimit())
       4442                                 netdev_warn(dev, "Rx ERROR. status = %08x\n",
    
    Marco Elver explained that dma_rmb() doesn't prevent the compiler to tear up the access to
    desc->opts1 which can be written to concurrently. READ_ONCE() should prevent that from
    happening:
    
       4429
     → 4430                 status = le32_to_cpu(READ_ONCE(desc->opts1));
       4431                 if (status & DescOwn)
       4432                         break;
       4433
    
    As the consequence of this fix, this KCSAN warning was eliminated.
    
    Fixes: 6202806e7c03a ("r8169: drop member opts1_mask from struct rtl8169_private")
    Suggested-by: Marco Elver <[email protected]>
    Cc: Heiner Kallweit <[email protected]>
    Cc: [email protected]
    Cc: "David S. Miller" <[email protected]>
    Cc: Eric Dumazet <[email protected]>
    Cc: Jakub Kicinski <[email protected]>
    Cc: Paolo Abeni <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Mirsad Goran Todorovac <[email protected]>
    Acked-by: Marco Elver <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

r8169: fix the KCSAN reported data-race in rtl_tx while reading TxDescArray[entry].opts1 [+ + +]
Author: Mirsad Goran Todorovac <[email protected]>
Date:   Wed Oct 18 21:34:36 2023 +0200

    r8169: fix the KCSAN reported data-race in rtl_tx while reading TxDescArray[entry].opts1
    
    [ Upstream commit dcf75a0f6bc136de94e88178ae5f51b7f879abc9 ]
    
    KCSAN reported the following data-race:
    
    ==================================================================
    BUG: KCSAN: data-race in rtl8169_poll (drivers/net/ethernet/realtek/r8169_main.c:4368 drivers/net/ethernet/realtek/r8169_main.c:4581) r8169
    
    race at unknown origin, with read to 0xffff888140d37570 of 4 bytes by interrupt on cpu 21:
    rtl8169_poll (drivers/net/ethernet/realtek/r8169_main.c:4368 drivers/net/ethernet/realtek/r8169_main.c:4581) r8169
    __napi_poll (net/core/dev.c:6527)
    net_rx_action (net/core/dev.c:6596 net/core/dev.c:6727)
    __do_softirq (kernel/softirq.c:553)
    __irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632)
    irq_exit_rcu (kernel/softirq.c:647)
    sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1074 (discriminator 14))
    asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:645)
    cpuidle_enter_state (drivers/cpuidle/cpuidle.c:291)
    cpuidle_enter (drivers/cpuidle/cpuidle.c:390)
    call_cpuidle (kernel/sched/idle.c:135)
    do_idle (kernel/sched/idle.c:219 kernel/sched/idle.c:282)
    cpu_startup_entry (kernel/sched/idle.c:378 (discriminator 1))
    start_secondary (arch/x86/kernel/smpboot.c:210 arch/x86/kernel/smpboot.c:294)
    secondary_startup_64_no_verify (arch/x86/kernel/head_64.S:433)
    
    value changed: 0xb0000042 -> 0x00000000
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 21 PID: 0 Comm: swapper/21 Tainted: G             L     6.6.0-rc2-kcsan-00143-gb5cbe7c00aa0 #41
    Hardware name: ASRock X670E PG Lightning/X670E PG Lightning, BIOS 1.21 04/26/2023
    ==================================================================
    
    The read side is in
    
    drivers/net/ethernet/realtek/r8169_main.c
    =========================================
       4355 static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp,
       4356                    int budget)
       4357 {
       4358         unsigned int dirty_tx, bytes_compl = 0, pkts_compl = 0;
       4359         struct sk_buff *skb;
       4360
       4361         dirty_tx = tp->dirty_tx;
       4362
       4363         while (READ_ONCE(tp->cur_tx) != dirty_tx) {
       4364                 unsigned int entry = dirty_tx % NUM_TX_DESC;
       4365                 u32 status;
       4366
     → 4367                 status = le32_to_cpu(tp->TxDescArray[entry].opts1);
       4368                 if (status & DescOwn)
       4369                         break;
       4370
       4371                 skb = tp->tx_skb[entry].skb;
       4372                 rtl8169_unmap_tx_skb(tp, entry);
       4373
       4374                 if (skb) {
       4375                         pkts_compl++;
       4376                         bytes_compl += skb->len;
       4377                         napi_consume_skb(skb, budget);
       4378                 }
       4379                 dirty_tx++;
       4380         }
       4381
       4382         if (tp->dirty_tx != dirty_tx) {
       4383                 dev_sw_netstats_tx_add(dev, pkts_compl, bytes_compl);
       4384                 WRITE_ONCE(tp->dirty_tx, dirty_tx);
       4385
       4386                 netif_subqueue_completed_wake(dev, 0, pkts_compl, bytes_compl,
       4387                                               rtl_tx_slots_avail(tp),
       4388                                               R8169_TX_START_THRS);
       4389                 /*
       4390                  * 8168 hack: TxPoll requests are lost when the Tx packets are
       4391                  * too close. Let's kick an extra TxPoll request when a burst
       4392                  * of start_xmit activity is detected (if it is not detected,
       4393                  * it is slow enough). -- FR
       4394                  * If skb is NULL then we come here again once a tx irq is
       4395                  * triggered after the last fragment is marked transmitted.
       4396                  */
       4397                 if (READ_ONCE(tp->cur_tx) != dirty_tx && skb)
       4398                         rtl8169_doorbell(tp);
       4399         }
       4400 }
    
    tp->TxDescArray[entry].opts1 is reported to have a data-race and READ_ONCE() fixes
    this KCSAN warning.
    
       4366
     → 4367                 status = le32_to_cpu(READ_ONCE(tp->TxDescArray[entry].opts1));
       4368                 if (status & DescOwn)
       4369                         break;
       4370
    
    Cc: Heiner Kallweit <[email protected]>
    Cc: [email protected]
    Cc: "David S. Miller" <[email protected]>
    Cc: Eric Dumazet <[email protected]>
    Cc: Jakub Kicinski <[email protected]>
    Cc: Paolo Abeni <[email protected]>
    Cc: Marco Elver <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Mirsad Goran Todorovac <[email protected]>
    Acked-by: Marco Elver <[email protected]>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: remove the sx8 block driver [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Thu Jul 21 08:41:02 2022 +0200

    remove the sx8 block driver
    
    commit d13bc4d84a8e91060d3797fc95c1a0202bfd1499 upstream.
    
    This driver is for fairly obscure hardware, and has only seen random
    drive-by changes after the maintainer stopped working on it in 2005
    (about a year and a half after it was introduced).  It has some
    "interesting" block layer interactions, so let's just drop it unless
    anyone complains.
    
    Signed-off-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [axboe: fix date typo, it was in 2005, not 2015]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "ARM: dts: Move am33xx and am43xx mmc nodes to sdhci-omap driver" [+ + +]
Author: Matthias Schiffer <[email protected]>
Date:   Mon Nov 6 10:50:48 2023 +0100

    Revert "ARM: dts: Move am33xx and am43xx mmc nodes to sdhci-omap driver"
    
    This reverts commit d0c69c722ff16ce2481a5e0932c6d5b172109f21 which is
    commit 0b4edf111870b83ea77b1d7e16b8ceac29f9f388 upstream.
    
    The reverted commit completely breaks MMC on the AM33xx/AM437x for
    multiple reasons:
    
    - The changed compatible strings ti,am335-sdhci and ti,am437-sdhci
      aren't supported on Linux 5.4 at all, so no driver is found
    - Even when additionally backporting the support for these compatible
      strings in the sdhci-omap driver, I could not the the MMC interfaces
      to work on our TQMa335x SoM - the interface would time out during card
      initialization for both an eMMC and an SD card.
    
    I did not investigate the cause of the timeouts further, and instead
    just reverted the commit - switching to a different MMC driver in a stable
    kernel seems like a rather risky change unless it's thoroughly tested,
    which has obviously not happened in this case.
    
    The reverted commit is also given as a Stable-dep-of commit 2eb502f496f7
    ("ARM: dts: am33xx: Fix MMCHS0 dma properties"), however the conflict
    resulting when only the one commit is reverted is trivial to resolve,
    which leads to working MMC controllers again.
    
    Signed-off-by: Matthias Schiffer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
rpmsg: Constify local variable in field store macro [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Oct 31 11:37:44 2023 +0000

    rpmsg: Constify local variable in field store macro
    
    commit e5f89131a06142e91073b6959d91cea73861d40e upstream.
    
    Memory pointed by variable 'old' in field store macro is not modified,
    so it can be made a pointer to const.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

rpmsg: Fix calling device_lock() on non-initialized device [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Oct 31 11:37:46 2023 +0000

    rpmsg: Fix calling device_lock() on non-initialized device
    
    commit bb17d110cbf270d5247a6e261c5ad50e362d1675 upstream.
    
    driver_set_override() helper uses device_lock() so it should not be
    called before rpmsg_register_device() (which calls device_register()).
    Effect can be seen with CONFIG_DEBUG_MUTEXES:
    
      DEBUG_LOCKS_WARN_ON(lock->magic != lock)
      WARNING: CPU: 3 PID: 57 at kernel/locking/mutex.c:582 __mutex_lock+0x1ec/0x430
      ...
      Call trace:
       __mutex_lock+0x1ec/0x430
       mutex_lock_nested+0x44/0x50
       driver_set_override+0x124/0x150
       qcom_glink_native_probe+0x30c/0x3b0
       glink_rpm_probe+0x274/0x350
       platform_probe+0x6c/0xe0
       really_probe+0x17c/0x3d0
       __driver_probe_device+0x114/0x190
       driver_probe_device+0x3c/0xf0
       ...
    
    Refactor the rpmsg_register_device() function to use two-step device
    registering (initialization + add) and call driver_set_override() in
    proper moment.
    
    This moves the code around, so while at it also NULL-ify the
    rpdev->driver_override in error path to be sure it won't be kfree()
    second time.
    
    Fixes: 42cd402b8fd4 ("rpmsg: Fix kfree() of static memory on setting driver_override")
    Reported-by: Marek Szyprowski <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Tested-by: Marek Szyprowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

rpmsg: Fix kfree() of static memory on setting driver_override [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Oct 31 11:37:45 2023 +0000

    rpmsg: Fix kfree() of static memory on setting driver_override
    
    commit 42cd402b8fd4672b692400fe5f9eecd55d2794ac upstream.
    
    The driver_override field from platform driver should not be initialized
    from static memory (string literal) because the core later kfree() it,
    for example when driver_override is set via sysfs.
    
    Use dedicated helper to set driver_override properly.
    
    Fixes: 950a7388f02b ("rpmsg: Turn name service into a stand alone driver")
    Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface")
    Reviewed-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <greg[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

rpmsg: Fix possible refcount leak in rpmsg_register_device_override() [+ + +]
Author: Hangyu Hua <[email protected]>
Date:   Tue Oct 31 11:37:48 2023 +0000

    rpmsg: Fix possible refcount leak in rpmsg_register_device_override()
    
    commit d7bd416d35121c95fe47330e09a5c04adbc5f928 upstream.
    
    rpmsg_register_device_override need to call put_device to free vch when
    driver_set_override fails.
    
    Fix this by adding a put_device() to the error path.
    
    Fixes: bb17d110cbf2 ("rpmsg: Fix calling device_lock() on non-initialized device")
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Hangyu Hua <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

rpmsg: glink: Release driver_override [+ + +]
Author: Bjorn Andersson <[email protected]>
Date:   Tue Oct 31 11:37:47 2023 +0000

    rpmsg: glink: Release driver_override
    
    commit fb80ef67e8ff6a00d3faad4cb348dafdb8eccfd8 upstream.
    
    Upon termination of the rpmsg_device, driver_override needs to be freed
    to avoid leaking the potentially assigned string.
    
    Fixes: 42cd402b8fd4 ("rpmsg: Fix kfree() of static memory on setting driver_override")
    Fixes: 39e47767ec9b ("rpmsg: Add driver_override device attribute for rpmsg_device")
    Reviewed-by: Chris Lew <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
scsi: mpt3sas: Fix in error path [+ + +]
Author: Tomas Henzl <[email protected]>
Date:   Sun Oct 15 13:45:29 2023 +0200

    scsi: mpt3sas: Fix in error path
    
    [ Upstream commit e40c04ade0e2f3916b78211d747317843b11ce10 ]
    
    The driver should be deregistered as misc driver after PCI registration
    failure.
    
    Signed-off-by: Tomas Henzl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/ftrace: Add new test case which checks non unique symbol [+ + +]
Author: Francis Laniel <[email protected]>
Date:   Fri Oct 20 13:42:50 2023 +0300

    selftests/ftrace: Add new test case which checks non unique symbol
    
    [ Upstream commit 03b80ff8023adae6780e491f66e932df8165e3a0 ]
    
    If name_show() is non unique, this test will try to install a kprobe on this
    function which should fail returning EADDRNOTAVAIL.
    On kernel where name_show() is not unique, this test is skipped.
    
    Link: https://lore.kernel.org/all/[email protected]/
    
    Cc: [email protected]
    Signed-off-by: Francis Laniel <[email protected]>
    Acked-by: Masami Hiramatsu (Google) <[email protected]>
    Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
smbdirect: missing rc checks while waiting for rdma events [+ + +]
Author: Steve French <[email protected]>
Date:   Mon Jun 21 16:25:20 2021 -0500

    smbdirect: missing rc checks while waiting for rdma events
    
    commit 0555b221528e9cb11f5766dcdee19c809187e42e upstream.
    
    There were two places where we weren't checking for error
    (e.g. ERESTARTSYS) while waiting for rdma resolution.
    
    Addresses-Coverity: 1462165 ("Unchecked return value")
    Reviewed-by: Tom Talpey <[email protected]>
    Reviewed-by: Long Li <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Anastasia Belova <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
spi: npcm-fiu: Fix UMA reads when dummy.nbytes == 0 [+ + +]
Author: William A. Kennington III <[email protected]>
Date:   Fri Sep 22 11:28:12 2023 -0700

    spi: npcm-fiu: Fix UMA reads when dummy.nbytes == 0
    
    [ Upstream commit 2ec8b010979036c2fe79a64adb6ecc0bd11e91d1 ]
    
    We don't want to use the value of ilog2(0) as dummy.buswidth is 0 when
    dummy.nbytes is 0. Since we have no dummy bytes, we don't need to
    configure the dummy byte bits per clock register value anyway.
    
    Signed-off-by: "William A. Kennington III" <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tcp: fix wrong RTO timeout when received SACK reneging [+ + +]
Author: Fred Chen <[email protected]>
Date:   Sat Oct 21 08:19:47 2023 +0800

    tcp: fix wrong RTO timeout when received SACK reneging
    
    [ Upstream commit d2a0fc372aca561556e765d0a9ec365c7c12f0ad ]
    
    This commit fix wrong RTO timeout when received SACK reneging.
    
    When an ACK arrived pointing to a SACK reneging, tcp_check_sack_reneging()
    will rearm the RTO timer for min(1/2*srtt, 10ms) into to the future.
    
    But since the commit 62d9f1a6945b ("tcp: fix TLP timer not set when
    CA_STATE changes from DISORDER to OPEN") merged, the tcp_set_xmit_timer()
    is moved after tcp_fastretrans_alert()(which do the SACK reneging check),
    so the RTO timeout will be overwrited by tcp_set_xmit_timer() with
    icsk_rto instead of 1/2*srtt.
    
    Here is a packetdrill script to check this bug:
    0     socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
    +0    bind(3, ..., ...) = 0
    +0    listen(3, 1) = 0
    
    // simulate srtt to 100ms
    +0    < S 0:0(0) win 32792 <mss 1000, sackOK,nop,nop,nop,wscale 7>
    +0    > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7>
    +.1    < . 1:1(0) ack 1 win 1024
    
    +0    accept(3, ..., ...) = 4
    
    +0    write(4, ..., 10000) = 10000
    +0    > P. 1:10001(10000) ack 1
    
    // inject sack
    +.1    < . 1:1(0) ack 1 win 257 <sack 1001:10001,nop,nop>
    +0    > . 1:1001(1000) ack 1
    
    // inject sack reneging
    +.1    < . 1:1(0) ack 1001 win 257 <sack 9001:10001,nop,nop>
    
    // we expect rto fired in 1/2*srtt (50ms)
    +.05    > . 1001:2001(1000) ack 1
    
    This fix remove the FLAG_SET_XMIT_TIMER from ack_flag when
    tcp_check_sack_reneging() set RTO timer with 1/2*srtt to avoid
    being overwrited later.
    
    Fixes: 62d9f1a6945b ("tcp: fix TLP timer not set when CA_STATE changes from DISORDER to OPEN")
    Signed-off-by: Fred Chen <[email protected]>
    Reviewed-by: Neal Cardwell <[email protected]>
    Tested-by: Neal Cardwell <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
treewide: Spelling fix in comment [+ + +]
Author: Kunwu Chan <[email protected]>
Date:   Fri Oct 20 17:31:56 2023 +0800

    treewide: Spelling fix in comment
    
    [ Upstream commit fb71ba0ed8be9534493c80ba00142a64d9972a72 ]
    
    reques -> request
    
    Fixes: 09dde54c6a69 ("PS3: gelic: Add wireless support for PS3")
    Signed-off-by: Kunwu Chan <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tty: 8250: Add support for additional Brainboxes UC cards [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:09 2023 +0100

    tty: 8250: Add support for additional Brainboxes UC cards
    
    commit c563db486db7d245c0e2f319443417ae8e692f7f upstream.
    
    Add device IDs for some more Brainboxes UC cards, namely
    UC-235/UC-246, UC-253/UC-734, UC-302, UC-313, UC-346, UC-357,
    UC-607 and UC-836.
    
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB789969998A6C3FAFCD95C85DC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Add support for Brainboxes UP cards [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:10 2023 +0100

    tty: 8250: Add support for Brainboxes UP cards
    
    commit 2c6fec1e1532f15350be7e14ba6b88a39d289fe4 upstream.
    
    Add support for the Brainboxes UP (powered PCI) range of
    cards, namely UP-189, UP-200, UP-869 and UP-880.
    
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB7899B5B59FF3D8587E88C117C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Add support for Intashield IS-100 [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:11 2023 +0100

    tty: 8250: Add support for Intashield IS-100
    
    commit 4d994e3cf1b541ff32dfb03fbbc60eea68f9645b upstream.
    
    Add support for the Intashield IS-100 1 port serial card.
    
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB7899A0E0CDAA505AF5A874CDC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Remove UC-257 and UC-431 [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:08 2023 +0100

    tty: 8250: Remove UC-257 and UC-431
    
    commit 33092fb3af51deb80849e90a17bada44bbcde6b3 upstream.
    
    The UC-257 is a serial + LPT card, so remove it from this driver.
    A patch has been submitted to add it to parport_serial instead.
    
    Additionaly, the UC-431 does not use this card ID, only the UC-420
    does. The 431 is a 3-port card and there is no generic 3-port configuration
    available, so remove reference to it from this driver.
    
    Fixes: 152d1afa834c ("tty: Add support for Brainboxes UC cards.")
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB78995ADF7394C74AD4CF3357C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: storage: set 1.50 as the lower bcdDevice for older "Super Top" compatibility [+ + +]
Author: LihaSika <[email protected]>
Date:   Fri Oct 27 20:28:04 2023 +0300

    usb: storage: set 1.50 as the lower bcdDevice for older "Super Top" compatibility
    
    commit 0e3139e6543b241b3e65956a55c712333bef48ac upstream.
    
    Change lower bcdDevice value for "Super Top USB 2.0  SATA BRIDGE" to match
    1.50. I have such an older device with bcdDevice=1.50 and it will not work
    otherwise.
    
    Cc: [email protected]
    Signed-off-by: Liha Sikanen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
virtio-mmio: fix memory leak of vm_dev [+ + +]
Author: Maximilian Heyne <[email protected]>
Date:   Mon Sep 11 09:03:29 2023 +0000

    virtio-mmio: fix memory leak of vm_dev
    
    commit fab7f259227b8f70aa6d54e1de1a1f5f4729041c upstream.
    
    With the recent removal of vm_dev from devres its memory is only freed
    via the callback virtio_mmio_release_dev. However, this only takes
    effect after device_add is called by register_virtio_device. Until then
    it's an unmanaged resource and must be explicitly freed on error exit.
    
    This bug was discovered and resolved using Coverity Static Analysis
    Security Testing (SAST) by Synopsys, Inc.
    
    Cc: [email protected]
    Fixes: 55c91fedd03d ("virtio-mmio: don't break lifecycle of vm_dev")
    Signed-off-by: Maximilian Heyne <[email protected]>
    Reviewed-by: Catalin Marinas <[email protected]>
    Tested-by: Catalin Marinas <[email protected]>
    Reviewed-by: Xuan Zhuo <xuanzh[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Reviewed-by: Wolfram Sang <[email protected]>

 
virtio_balloon: Fix endless deflation and inflation on arm64 [+ + +]
Author: Gavin Shan <[email protected]>
Date:   Thu Aug 31 11:10:07 2023 +1000

    virtio_balloon: Fix endless deflation and inflation on arm64
    
    commit 07622bd415639e9709579f400afd19e7e9866e5e upstream.
    
    The deflation request to the target, which isn't unaligned to the
    guest page size causes endless deflation and inflation actions. For
    example, we receive the flooding QMP events for the changes on memory
    balloon's size after a deflation request to the unaligned target is
    sent for the ARM64 guest, where we have 64KB base page size.
    
      /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64      \
      -accel kvm -machine virt,gic-version=host -cpu host          \
      -smp maxcpus=8,cpus=8,sockets=2,clusters=2,cores=2,threads=1 \
      -m 1024M,slots=16,maxmem=64G                                 \
      -object memory-backend-ram,id=mem0,size=512M                 \
      -object memory-backend-ram,id=mem1,size=512M                 \
      -numa node,nodeid=0,memdev=mem0,cpus=0-3                     \
      -numa node,nodeid=1,memdev=mem1,cpus=4-7                     \
        :                                                          \
      -device virtio-balloon-pci,id=balloon0,bus=pcie.10
    
      { "execute" : "balloon", "arguments": { "value" : 1073672192 } }
      {"return": {}}
      {"timestamp": {"seconds": 1693272173, "microseconds": 88667},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
      {"timestamp": {"seconds": 1693272174, "microseconds": 89704},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
      {"timestamp": {"seconds": 1693272175, "microseconds": 90819},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
      {"timestamp": {"seconds": 1693272176, "microseconds": 91961},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
      {"timestamp": {"seconds": 1693272177, "microseconds": 93040},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
      {"timestamp": {"seconds": 1693272178, "microseconds": 94117},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
      {"timestamp": {"seconds": 1693272179, "microseconds": 95337},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
      {"timestamp": {"seconds": 1693272180, "microseconds": 96615},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
      {"timestamp": {"seconds": 1693272181, "microseconds": 97626},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
      {"timestamp": {"seconds": 1693272182, "microseconds": 98693},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
      {"timestamp": {"seconds": 1693272183, "microseconds": 99698},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
      {"timestamp": {"seconds": 1693272184, "microseconds": 100727},  \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
      {"timestamp": {"seconds": 1693272185, "microseconds": 90430},   \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
      {"timestamp": {"seconds": 1693272186, "microseconds": 102999},  \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
         :
      <The similar QMP events repeat>
    
    Fix it by aligning the target up to the guest page size, 64KB in this
    specific case. With this applied, no flooding QMP events are observed
    and the memory balloon's size can be stablizied to 0x3ffe0000 soon
    after the deflation request is sent.
    
      { "execute" : "balloon", "arguments": { "value" : 1073672192 } }
      {"return": {}}
      {"timestamp": {"seconds": 1693273328, "microseconds": 793075},  \
       "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
      { "execute" : "query-balloon" }
      {"return": {"actual": 1073610752}}
    
    Cc: [email protected]
    Signed-off-by: Gavin Shan <[email protected]>
    Tested-by: Zhenyu Zhang <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Reviewed-by: David Hildenbrand <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/i8259: Skip probing when ACPI/MADT advertises PCAT compatibility [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Wed Oct 25 23:04:15 2023 +0200

    x86/i8259: Skip probing when ACPI/MADT advertises PCAT compatibility
    
    commit 128b0c9781c9f2651bea163cb85e52a6c7be0f9e upstream.
    
    David and a few others reported that on certain newer systems some legacy
    interrupts fail to work correctly.
    
    Debugging revealed that the BIOS of these systems leaves the legacy PIC in
    uninitialized state which makes the PIC detection fail and the kernel
    switches to a dummy implementation.
    
    Unfortunately this fallback causes quite some code to fail as it depends on
    checks for the number of legacy PIC interrupts or the availability of the
    real PIC.
    
    In theory there is no reason to use the PIC on any modern system when
    IO/APIC is available, but the dependencies on the related checks cannot be
    resolved trivially and on short notice. This needs lots of analysis and
    rework.
    
    The PIC detection has been added to avoid quirky checks and force selection
    of the dummy implementation all over the place, especially in VM guest
    scenarios. So it's not an option to revert the relevant commit as that
    would break a lot of other scenarios.
    
    One solution would be to try to initialize the PIC on detection fail and
    retry the detection, but that puts the burden on everything which does not
    have a PIC.
    
    Fortunately the ACPI/MADT table header has a flag field, which advertises
    in bit 0 that the system is PCAT compatible, which means it has a legacy
    8259 PIC.
    
    Evaluate that bit and if set avoid the detection routine and keep the real
    PIC installed, which then gets initialized (for nothing) and makes the rest
    of the code with all the dependencies work again.
    
    Fixes: e179f6914152 ("x86, irq, pic: Probe for legacy PIC and set legacy_pic appropriately")
    Reported-by: David Lazar <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: David Lazar <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Reviewed-by: Mario Limonciello <[email protected]>
    Cc: [email protected]
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218003
    Link: https://lore.kernel.org/r/875y2u5s8g.ffs@tglx
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/mm: Fix RESERVE_BRK() for older binutils [+ + +]
Author: Josh Poimboeuf <[email protected]>
Date:   Thu Jun 9 00:17:32 2022 -0700

    x86/mm: Fix RESERVE_BRK() for older binutils
    
    commit e32683c6f7d22ba624e0bfc58b02cf3348bdca63 upstream.
    
    With binutils 2.26, RESERVE_BRK() causes a build failure:
    
      /tmp/ccnGOKZ5.s: Assembler messages:
      /tmp/ccnGOKZ5.s:98: Error: missing ')'
      /tmp/ccnGOKZ5.s:98: Error: missing ')'
      /tmp/ccnGOKZ5.s:98: Error: missing ')'
      /tmp/ccnGOKZ5.s:98: Error: junk at end of line, first unrecognized
      character is `U'
    
    The problem is this line:
    
      RESERVE_BRK(early_pgt_alloc, INIT_PGT_BUF_SIZE)
    
    Specifically, the INIT_PGT_BUF_SIZE macro which (via PAGE_SIZE's use
    _AC()) has a "1UL", which makes older versions of the assembler unhappy.
    Unfortunately the _AC() macro doesn't work for inline asm.
    
    Inline asm was only needed here to convince the toolchain to add the
    STT_NOBITS flag.  However, if a C variable is placed in a section whose
    name is prefixed with ".bss", GCC and Clang automatically set
    STT_NOBITS.  In fact, ".bss..page_aligned" already relies on this trick.
    
    So fix the build failure (and simplify the macro) by allocating the
    variable in C.
    
    Also, add NOLOAD to the ".brk" output section clause in the linker
    script.  This is a failsafe in case the ".bss" prefix magic trick ever
    stops working somehow.  If there's a section type mismatch, the GNU
    linker will force the ".brk" output section to be STT_NOBITS.  The LLVM
    linker will fail with a "section type mismatch" error.
    
    Note this also changes the name of the variable from .brk.##name to
    __brk_##name.  The variable names aren't actually used anywhere, so it's
    harmless.
    
    Fixes: a1e2c031ec39 ("x86/mm: Simplify RESERVE_BRK()")
    Reported-by: Joe Damato <[email protected]>
    Reported-by: Byungchul Park <[email protected]>
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Tested-by: Joe Damato <[email protected]>
    Link: https://lore.kernel.org/r/22d07a44c80d8e8e1e82b9a806ddc8c6bbb2606e.1654759036.git.jpoimboe@kernel.org
    [nathan: Fix conflict due to lack of 360db4ace311 and resolve silent
             conflict with 360db4ace3117]
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

x86/mm: Simplify RESERVE_BRK() [+ + +]
Author: Josh Poimboeuf <[email protected]>
Date:   Fri May 6 14:14:32 2022 +0200

    x86/mm: Simplify RESERVE_BRK()
    
    commit a1e2c031ec3949b8c039b739c0b5bf9c30007b00 upstream.
    
    RESERVE_BRK() reserves data in the .brk_reservation section.  The data
    is initialized to zero, like BSS, so the macro specifies 'nobits' to
    prevent the data from taking up space in the vmlinux binary.  The only
    way to get the compiler to do that (without putting the variable in .bss
    proper) is to use inline asm.
    
    The macro also has a hack which encloses the inline asm in a discarded
    function, which allows the size to be passed (global inline asm doesn't
    allow inputs).
    
    Remove the need for the discarded function hack by just stringifying the
    size rather than supplying it as an input to the inline asm.
    
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Signed-off-by: Borislav Petkov <[email protected]>
    Reviewed-by: Borislav Petkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [nathan: Fix conflict due to lack of 2b6ff7dea670 and 33def8498fdd]
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86: Fix .brk attribute in linker script [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Thu Jun 30 09:14:41 2022 +0200

    x86: Fix .brk attribute in linker script
    
    commit 7e09ac27f43b382f5fe9bb7c7f4c465ece1f8a23 upstream.
    
    Commit in Fixes added the "NOLOAD" attribute to the .brk section as a
    "failsafe" measure.
    
    Unfortunately, this leads to the linker no longer covering the .brk
    section in a program header, resulting in the kernel loader not knowing
    that the memory for the .brk section must be reserved.
    
    This has led to crashes when loading the kernel as PV dom0 under Xen,
    but other scenarios could be hit by the same problem (e.g. in case an
    uncompressed kernel is used and the initrd is placed directly behind
    it).
    
    So drop the "NOLOAD" attribute. This has been verified to correctly
    cover the .brk section by a program header of the resulting ELF file.
    
    Fixes: e32683c6f7d2 ("x86/mm: Fix RESERVE_BRK() for older binutils")
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Borislav Petkov <[email protected]>
    Reviewed-by: Josh Poimboeuf <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>