Linux 5.15.138

 
ALSA: hda: intel-dsp-config: Fix JSL Chromebook quirk detection [+ + +]
Author: Mark Hasemeyer <[email protected]>
Date:   Wed Oct 18 17:59:31 2023 -0600

    ALSA: hda: intel-dsp-config: Fix JSL Chromebook quirk detection
    
    commit 7c05b44e1a50d9cbfc4f731dddc436a24ddc129a upstream.
    
    Some Jasperlake Chromebooks overwrite the system vendor DMI value to the
    name of the OEM that manufactured the device. This breaks Chromebook
    quirk detection as it expects the system vendor to be "Google".
    
    Add another quirk detection entry that looks for "Google" in the BIOS
    version.
    
    Cc: [email protected]
    Signed-off-by: Mark Hasemeyer <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ASoC: codecs: wcd938x: fix resource leaks on bind errors [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Tue Oct 3 17:55:54 2023 +0200

    ASoC: codecs: wcd938x: fix resource leaks on bind errors
    
    commit da29b94ed3547cee9d510d02eca4009f2de476cf upstream.
    
    Add the missing code to release resources on bind errors, including the
    references taken by wcd938x_sdw_device_get() which also need to be
    dropped on unbind().
    
    Fixes: 16572522aece ("ASoC: codecs: wcd938x-sdw: add SoundWire driver")
    Cc: [email protected]      # 5.14
    Cc: Srinivas Kandagatla <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
ASoC: codecs: wcd938x: fix runtime PM imbalance on remove [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Tue Oct 3 17:55:56 2023 +0200

    ASoC: codecs: wcd938x: fix runtime PM imbalance on remove
    
    [ Upstream commit 3ebebb2c1eca92a15107b2d7aeff34196fd9e217 ]
    
    Make sure to balance the runtime PM operations, including the disable
    count, on driver unbind.
    
    Fixes: 16572522aece ("ASoC: codecs: wcd938x-sdw: add SoundWire driver")
    Cc: [email protected]      # 5.14
    Cc: Srinivas Kandagatla <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[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]>

ASoC: simple-card: fixup asoc_simple_probe() error handling [+ + +]
Author: Kuninori Morimoto <[email protected]>
Date:   Tue Sep 19 05:34:18 2023 +0000

    ASoC: simple-card: fixup asoc_simple_probe() error handling
    
    [ Upstream commit 41bae58df411f9accf01ea660730649b2fab1dab ]
    
    asoc_simple_probe() is used for both "DT probe" (A) and "platform probe"
    (B). It uses "goto err" when error case, but it is not needed for
    "platform probe" case (B). Thus it is using "return" directly there.
    
            static int asoc_simple_probe(...)
            {
     ^              if (...) {
     |                      ...
    (A)                     if (ret < 0)
     |                              goto err;
     v              } else {
     ^                      ...
     |                      if (ret < 0)
    (B)                             return -Exxx;
     v              }
    
                    ...
     ^              if (ret < 0)
    (C)                     goto err;
     v              ...
    
            err:
    (D)             simple_util_clean_reference(card);
    
                    return ret;
            }
    
    Both case are using (C) part, and it calls (D) when err case.
    But (D) will do nothing for (B) case.
    Because of these behavior, current code itself is not wrong,
    but is confusable, and more, static analyzing tool will warning on
    (B) part (should use goto err).
    
    To avoid static analyzing tool warning, this patch uses "goto err"
    on (B) part.
    
    Reported-by: kernel test robot <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Signed-off-by: Kuninori Morimoto <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
can: isotp: add local echo tx processing and tx without FC [+ + +]
Author: Oliver Hartkopp <[email protected]>
Date:   Tue Oct 31 10:30:23 2023 +0100

    can: isotp: add local echo tx processing and tx without FC
    
    commit 4b7fe92c06901f4563af0e36d25223a5ab343782 upstream
    commit 9f39d36530e5678d092d53c5c2c60d82b4dcc169 upstream
    commit 051737439eaee5bdd03d3c2ef5510d54a478fd05 upstream
    
    Due to the existing patch order applied to isotp.c in the stable kernel the
    original order of depending patches the three original patches
    4b7fe92c0690 ("can: isotp: add local echo tx processing for consecutive frames")
    9f39d36530e5 ("can: isotp: add support for transmission without flow control")
    051737439eae ("can: isotp: fix race between isotp_sendsmg() and isotp_release()")
    can not be split into different patches that can be applied in working steps
    to the stable tree.
    
    Signed-off-by: Oliver Hartkopp <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: isotp: check CAN address family in isotp_bind() [+ + +]
Author: Oliver Hartkopp <[email protected]>
Date:   Tue Oct 31 10:30:21 2023 +0100

    can: isotp: check CAN address family in isotp_bind()
    
    commit c6adf659a8ba85913e16a571d5a9bcd17d3d1234 upstream
    
    Add missing check to block non-AF_CAN binds.
    
    Syzbot created some code which matched the right sockaddr struct size
    but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family
    field:
    
    bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10)
                                    ^^^^
    This has no funtional impact but the userspace should be notified about
    the wrong address family field content.
    
    Link: https://syzkaller.appspot.com/text?tag=CrashLog&x=11ff9d8c480000
    Reported-by: [email protected]
    Signed-off-by: Oliver Hartkopp <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: isotp: handle wait_event_interruptible() return values [+ + +]
Author: Oliver Hartkopp <[email protected]>
Date:   Tue Oct 31 10:30:22 2023 +0100

    can: isotp: handle wait_event_interruptible() return values
    
    commit 823b2e42720f96f277940c37ea438b7c5ead51a4 upstream
    
    When wait_event_interruptible() has been interrupted by a signal the
    tx.state value might not be ISOTP_IDLE. Force the state machines
    into idle state to inhibit the timer handlers to continue working.
    
    Fixes: 866337865f37 ("can: isotp: fix tx state handling for echo tx processing")
    Cc: [email protected]
    Signed-off-by: Oliver Hartkopp <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: isotp: isotp_bind(): do not validate unused address information [+ + +]
Author: Oliver Hartkopp <[email protected]>
Date:   Tue Oct 31 10:30:24 2023 +0100

    can: isotp: isotp_bind(): do not validate unused address information
    
    commit b76b163f46b661499921a0049982764a6659bfe7 upstream
    
    With commit 2aa39889c463 ("can: isotp: isotp_bind(): return -EINVAL on
    incorrect CAN ID formatting") the bind() syscall returns -EINVAL when
    the given CAN ID needed to be sanitized. But in the case of an unconfirmed
    broadcast mode the rx CAN ID is not needed and may be uninitialized from
    the caller - which is ok.
    
    This patch makes sure the result of an inproper CAN ID format is only
    provided when the address information is needed.
    
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Oliver Hartkopp <[email protected]>
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: isotp: isotp_bind(): return -EINVAL on incorrect CAN ID formatting [+ + +]
Author: Oliver Hartkopp <[email protected]>
Date:   Tue Oct 31 10:30:20 2023 +0100

    can: isotp: isotp_bind(): return -EINVAL on incorrect CAN ID formatting
    
    commit 2aa39889c463195a0dfe2aff9fad413139c32a4f upstream
    
    Commit 3ea566422cbd ("can: isotp: sanitize CAN ID checks in
    isotp_bind()") checks the given CAN ID address information by
    sanitizing the input values.
    
    This check (silently) removes obsolete bits by masking the given CAN
    IDs.
    
    Derek Will suggested to give a feedback to the application programmer
    when the 'sanitizing' was actually needed which means the programmer
    provided CAN ID content in a wrong format (e.g. SFF CAN IDs with a CAN
    ID > 0x7FF).
    
    Link: https://lore.kernel.org/all/[email protected]
    Suggested-by: Derek Will <[email protected]>
    Signed-off-by: Oliver Hartkopp <[email protected]>
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: isotp: isotp_sendmsg(): fix TX state detection and wait behavior [+ + +]
Author: Oliver Hartkopp <[email protected]>
Date:   Tue Oct 31 10:30:25 2023 +0100

    can: isotp: isotp_sendmsg(): fix TX state detection and wait behavior
    
    From: Lukas Magel <[email protected]>
    
    [ Upstream commit d9c2ba65e651467de739324d978b04ed8729f483 ]
    
    With patch [1], isotp_poll was updated to also queue the poller in the
    so->wait queue, which is used for send state changes. Since the queue
    now also contains polling tasks that are not interested in sending, the
    queue fill state can no longer be used as an indication of send
    readiness. As a consequence, nonblocking writes can lead to a race and
    lock-up of the socket if there is a second task polling the socket in
    parallel.
    
    With this patch, isotp_sendmsg does not consult wq_has_sleepers but
    instead tries to atomically set so->tx.state and waits on so->wait if it
    is unable to do so. This behavior is in alignment with isotp_poll, which
    also checks so->tx.state to determine send readiness.
    
    V2:
    - Revert direct exit to goto err_event_drop
    
    [1] https://lore.kernel.org/all/[email protected]
    
    Reported-by: Maxime Jayat <[email protected]>
    Closes: https://lore.kernel.org/linux-can/[email protected]/
    Signed-off-by: Lukas Magel <[email protected]>
    Reviewed-by: Oliver Hartkopp <[email protected]>
    Fixes: 79e19fa79cb5 ("can: isotp: isotp_ops: fix poll() to not report false EPOLLOUT events")
    Link: https://github.com/pylessard/python-udsoncan/issues/178#issuecomment-1743786590
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: isotp: set max PDU size to 64 kByte [+ + +]
Author: Oliver Hartkopp <[email protected]>
Date:   Tue Oct 31 10:30:19 2023 +0100

    can: isotp: set max PDU size to 64 kByte
    
    commit 9c0c191d82a1de964ac953a1df8b5744ec670b07 upstream
    
    The reason to extend the max PDU size from 4095 Byte (12 bit length value)
    to a 32 bit value (up to 4 GByte) was to be able to flash 64 kByte
    bootloaders with a single ISO-TP PDU. The max PDU size in the Linux kernel
    implementation was set to 8200 Bytes to be able to test the length
    information escape sequence.
    
    It turns out that the demand for 64 kByte PDUs is real so the value for
    MAX_MSG_LENGTH is set to 66000 to be able to potentially add some checksums
    to the 65.536 Byte block.
    
    Link: https://github.com/linux-can/can-utils/issues/347#issuecomment-1056142301
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Oliver Hartkopp <[email protected]>
    Signed-off-by: Marc Kleine-Budde <[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:25:35 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/amd: Disable ASPM for VI w/ all Intel systems [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Fri Oct 20 10:26:29 2023 -0500

    drm/amd: Disable ASPM for VI w/ all Intel systems
    
    commit 64ffd2f1d00c6235dabe9704bbb0d9ce3e28147f upstream.
    
    Originally we were quirking ASPM disabled specifically for VI when
    used with Alder Lake, but it appears to have problems with Rocket
    Lake as well.
    
    Like we've done in the case of dpm for newer platforms, disable
    ASPM for all Intel systems.
    
    Cc: [email protected] # 5.15+
    Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
    Reported-and-tested-by: Paolo Gentili <[email protected]>
    Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2036742
    Signed-off-by: Mario Limonciello <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd: Move helper for dynamic speed switch check out of smu13 [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Fri Jul 7 21:26:08 2023 -0500

    drm/amd: Move helper for dynamic speed switch check out of smu13
    
    commit 188623076d0f1a500583d392b6187056bf7cc71a upstream.
    
    This helper is used for checking if the connected host supports
    the feature, it can be moved into generic code to be used by other
    smu implementations as well.
    
    Signed-off-by: Mario Limonciello <[email protected]>
    Reviewed-by: Evan Quan <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # 6.1.x
    Signed-off-by: Mario Limonciello <[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()
    
    [ Upstream commit 3d887d512494d678b17c57b835c32f4e48d34f26 ]
    
    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: Sasha Levin <[email protected]>

 
drm/i915/pmu: Check if pmu is closed before stopping event [+ + +]
Author: Umesh Nerlige Ramappa <[email protected]>
Date:   Fri Oct 20 08:24:41 2023 -0700

    drm/i915/pmu: Check if pmu is closed before stopping event
    
    commit 4cbed7702eb775cca22fff6827a549092cb59f61 upstream.
    
    When the driver unbinds, pmu is unregistered and i915->uabi_engines is
    set to RB_ROOT. Due to this, when i915 PMU tries to stop the engine
    events, it issues a warn_on because engine lookup fails.
    
    All perf hooks are taking care of this using a pmu->closed flag that is
    set when PMU unregisters. The stop event seems to have been left out.
    
    Check for pmu->closed in pmu_event_stop as well.
    
    Based on discussion here -
    https://patchwork.freedesktop.org/patch/492079/?series=105790&rev=2
    
    v2: s/is/if/ in commit title
    v3: Add fixes tag and cc stable
    
    Cc: <[email protected]> # v5.11+
    Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind")
    Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
    Reviewed-by: Tvrtko Ursulin <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 31f6a06f0c543b43a38fab10f39e5fc45ad62aa2)
    Signed-off-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/ttm: Reorder sys manager cleanup step [+ + +]
Author: Karolina Stolarek <[email protected]>
Date:   Mon Oct 16 14:15:25 2023 +0200

    drm/ttm: Reorder sys manager cleanup step
    
    [ Upstream commit 3b401e30c249849d803de6c332dad2a595a58658 ]
    
    With the current cleanup flow, we could trigger a NULL pointer
    dereference if there is a delayed destruction of a BO with a
    system resource that gets executed on drain_workqueue() call,
    as we attempt to free a resource using an already released
    resource manager.
    
    Remove the device from the device list and drain its workqueue
    before releasing the system domain manager in ttm_device_fini().
    
    Signed-off-by: Karolina Stolarek <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Christian König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ext4: add two helper functions extent_logical_end() and pa_logical_end() [+ + +]
Author: Baokun Li <[email protected]>
Date:   Sat Oct 28 14:47:47 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:47:49 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:47:48 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]>

 
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]>

 
firmware/imx-dsp: Fix use_after_free in imx_dsp_setup_channels() [+ + +]
Author: Hao Ge <[email protected]>
Date:   Sun Oct 8 11:29:08 2023 +0800

    firmware/imx-dsp: Fix use_after_free in imx_dsp_setup_channels()
    
    [ Upstream commit 1558b1a8dd388f5fcc3abc1e24de854a295044c3 ]
    
    dsp_chan->name and chan_name points to same block of memory,
    because dev_err still needs to be used it,so we need free
    it's memory after use to avoid use_after_free.
    
    Fixes: e527adfb9b7d ("firmware: imx-dsp: Fix an error handling path in imx_dsp_setup_channels()")
    Signed-off-by: Hao Ge <[email protected]>
    Reviewed-by: Daniel Baluta <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fs/ntfs3: Add ckeck in ni_update_parent() [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Fri Jun 30 15:52:19 2023 +0400

    fs/ntfs3: Add ckeck in ni_update_parent()
    
    [ Upstream commit 87d1888aa40f25773fa0b948bcb2545f97e2cb15 ]
    
    Check simple case when parent inode equals current inode.
    
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Avoid possible memory leak [+ + +]
Author: Su Hui <[email protected]>
Date:   Mon Sep 25 12:48:07 2023 +0800

    fs/ntfs3: Avoid possible memory leak
    
    [ Upstream commit e4494770a5cad3c9d1d2a65ed15d07656c0d9b82 ]
    
    smatch warn:
    fs/ntfs3/fslog.c:2172 last_log_lsn() warn: possible memory leak of 'page_bufs'
    Jump to label 'out' to free 'page_bufs' and is more consistent with
    other code.
    
    Signed-off-by: Su Hui <[email protected]>
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Fix directory element type detection [+ + +]
Author: Gabriel Marcano <[email protected]>
Date:   Tue Sep 12 21:50:32 2023 -0700

    fs/ntfs3: Fix directory element type detection
    
    [ Upstream commit 85a4780dc96ed9dd643bbadf236552b3320fae26 ]
    
    Calling stat() from userspace correctly identified junctions in an NTFS
    partition as symlinks, but using readdir() and iterating through the
    directory containing the same junction did not identify the junction
    as a symlink.
    
    When emitting directory contents, check FILE_ATTRIBUTE_REPARSE_POINT
    attribute to detect junctions and report them as links.
    
    Signed-off-by: Gabriel Marcano <[email protected]>
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Fix NULL pointer dereference on error in attr_allocate_frame() [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Tue Sep 26 11:28:11 2023 +0300

    fs/ntfs3: Fix NULL pointer dereference on error in attr_allocate_frame()
    
    [ Upstream commit 9c689c8dc86f8ca99bf91c05f24c8bab38fe7d5f ]
    
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Fix possible NULL-ptr-deref in ni_readpage_cmpr() [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Tue Sep 26 11:19:08 2023 +0300

    fs/ntfs3: Fix possible NULL-ptr-deref in ni_readpage_cmpr()
    
    [ Upstream commit 32e9212256b88f35466642f9c939bb40cfb2c2de ]
    
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Use kvmalloc instead of kmalloc(... __GFP_NOWARN) [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Fri Jun 30 16:12:58 2023 +0400

    fs/ntfs3: Use kvmalloc instead of kmalloc(... __GFP_NOWARN)
    
    [ Upstream commit fc471e39e38fea6677017cbdd6d928088a59fc67 ]
    
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Write immediately updated ntfs state [+ + +]
Author: Konstantin Komarov <[email protected]>
Date:   Fri Jun 30 15:57:19 2023 +0400

    fs/ntfs3: Write immediately updated ntfs state
    
    [ Upstream commit 06ccfb00645990a9fcc14249e6d1c25921ecb836 ]
    
    Signed-off-by: Konstantin Komarov <[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]>

 
gve: Fix GFP flags when allocing pages [+ + +]
Author: Shailend Chand <[email protected]>
Date:   Mon Sep 12 17:09:01 2022 -0700

    gve: Fix GFP flags when allocing pages
    
    [ Upstream commit a92f7a6feeb3884c69c1c7c1f13bccecb2228ad0 ]
    
    Use GFP_ATOMIC when allocating pages out of the hotpath,
    continue to use GFP_KERNEL when allocating pages during setup.
    
    GFP_KERNEL will allow blocking which allows it to succeed
    more often in a low memory enviornment but in the hotpath we do
    not want to allow the allocation to block.
    
    Fixes: f5cedc84a30d2 ("gve: Add transmit and receive support")
    Signed-off-by: Catherine Sullivan <[email protected]>
    Signed-off-by: David Awogbemila <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[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 <[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 I40E_FLAG_VF_VLAN_PRUNING value [+ + +]
Author: Ivan Vecera <[email protected]>
Date:   Thu Oct 19 18:37:20 2023 +0200

    i40e: Fix I40E_FLAG_VF_VLAN_PRUNING value
    
    [ Upstream commit 665e7d83c5386f9abdc67b2e4b6e6d9579aadfcb ]
    
    Commit c87c938f62d8f1 ("i40e: Add VF VLAN pruning") added new
    PF flag I40E_FLAG_VF_VLAN_PRUNING but its value collides with
    existing I40E_FLAG_TOTAL_PORT_SHUTDOWN_ENABLED flag.
    
    Move the affected flag at the end of the flags and fix its value.
    
    Reproducer:
    [root@cnb-03 ~]# ethtool --set-priv-flags enp2s0f0np0 link-down-on-close on
    [root@cnb-03 ~]# ethtool --set-priv-flags enp2s0f0np0 vf-vlan-pruning on
    [root@cnb-03 ~]# ethtool --set-priv-flags enp2s0f0np0 link-down-on-close off
    [ 6323.142585] i40e 0000:02:00.0: Setting link-down-on-close not supported on this port (because total-port-shutdown is enabled)
    netlink error: Operation not supported
    [root@cnb-03 ~]# ethtool --set-priv-flags enp2s0f0np0 vf-vlan-pruning off
    [root@cnb-03 ~]# ethtool --set-priv-flags enp2s0f0np0 link-down-on-close off
    
    The link-down-on-close flag cannot be modified after setting vf-vlan-pruning
    because vf-vlan-pruning shares the same bit with total-port-shutdown flag
    that prevents any modification of link-down-on-close flag.
    
    Fixes: c87c938f62d8 ("i40e: Add VF VLAN pruning")
    Cc: Mateusz Palczewski <[email protected]>
    Cc: Simon Horman <[email protected]>
    Signed-off-by: Ivan Vecera <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[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: adc: xilinx-xadc: Correct temperature offset/scale for UltraScale [+ + +]
Author: Robert Hancock <[email protected]>
Date:   Thu Sep 14 18:10:19 2023 -0600

    iio: adc: xilinx-xadc: Correct temperature offset/scale for UltraScale
    
    commit e2bd8c28b9bd835077eb65715d416d667694a80d upstream.
    
    The driver was previously using offset and scale values for the
    temperature sensor readings which were only valid for 7-series devices.
    Add per-device-type values for offset and scale and set them appropriately
    for each device type.
    
    Note that the values used for the UltraScale family are for UltraScale+
    (i.e. the SYSMONE4 primitive) using the internal reference, as that seems
    to be the most common configuration and the device tree values Xilinx's
    device tree generator produces don't seem to give us anything to tell us
    which configuration is used. However, the differences within the UltraScale
    family seem fairly minor and it's closer than using the 7-series values
    instead in any case.
    
    Fixes: c2b7720a7905 ("iio: xilinx-xadc: Add basic support for Ultrascale System Monitor")
    Signed-off-by: Robert Hancock <[email protected]>
    Acked-by: O'Griofa, Conall <[email protected]>
    Tested-by: O'Griofa, Conall <[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]>

iio: adc: xilinx-xadc: Don't clobber preset voltage/temperature thresholds [+ + +]
Author: Robert Hancock <[email protected]>
Date:   Thu Sep 14 18:10:18 2023 -0600

    iio: adc: xilinx-xadc: Don't clobber preset voltage/temperature thresholds
    
    commit 8d6b3ea4d9eaca80982442b68a292ce50ce0a135 upstream.
    
    In the probe function, the driver was reading out the thresholds already
    set in the core, which can be configured by the user in the Vivado tools
    when the FPGA image is built. However, it later clobbered those values
    with zero or maximum values. In particular, the overtemperature shutdown
    threshold register was overwritten with the max value, which effectively
    prevents the FPGA from shutting down when the desired threshold was
    eached, potentially risking hardware damage in that case.
    
    Remove this code to leave the preconfigured default threshold values
    intact.
    
    The code was also disabling all alarms regardless of what enable state
    they were left in by the FPGA image, including the overtemperature
    shutdown feature. Leave these bits in their original state so they are
    not unconditionally disabled.
    
    Fixes: bdc8cda1d010 ("iio:adc: Add Xilinx XADC driver")
    Signed-off-by: Robert Hancock <[email protected]>
    Acked-by: O'Griofa, Conall <[email protected]>
    Tested-by: O'Griofa, Conall <[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]>

iio: afe: rescale: Accept only offset channels [+ + +]
Author: Linus Walleij <[email protected]>
Date:   Sat Sep 2 21:46:20 2023 +0200

    iio: afe: rescale: Accept only offset channels
    
    [ Upstream commit bee448390e5166d019e9e037194d487ee94399d9 ]
    
    As noted by Jonathan Cameron: it is perfectly legal for a channel
    to have an offset but no scale in addition to the raw interface.
    The conversion will imply that scale is 1:1.
    
    Make rescale_configure_channel() accept just scale, or just offset
    to process a channel.
    
    When a user asks for IIO_CHAN_INFO_OFFSET in rescale_read_raw()
    we now have to deal with the fact that OFFSET could be present
    but SCALE missing. Add code to simply scale 1:1 in this case.
    
    Link: https://lore.kernel.org/linux-iio/CACRpkdZXBjHU4t-GVOCFxRO-AHGxKnxMeHD2s4Y4PuC29gBq6g@mail.gmail.com/
    Fixes: 53ebee949980 ("iio: afe: iio-rescale: Support processed channels")
    Fixes: 9decacd8b3a4 ("iio: afe: rescale: Fix boolean logic bug")
    Reported-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Reviewed-by: Peter Rosin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: afe: rescale: add offset support [+ + +]
Author: Liam Beguin <[email protected]>
Date:   Sat Feb 12 21:57:32 2022 -0500

    iio: afe: rescale: add offset support
    
    [ Upstream commit a29c3283653b80b916c5ca5292c5d36415e38e92 ]
    
    This is a preparatory change required for the addition of temperature
    sensing front ends.
    
    Signed-off-by: Liam Beguin <[email protected]>
    Reviewed-by: Peter Rosin <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Stable-dep-of: bee448390e51 ("iio: afe: rescale: Accept only offset channels")
    Signed-off-by: Sasha Levin <[email protected]>

iio: afe: rescale: expose scale processing function [+ + +]
Author: Liam Beguin <[email protected]>
Date:   Sat Feb 12 21:57:30 2022 -0500

    iio: afe: rescale: expose scale processing function
    
    [ Upstream commit bc437f7515f5e14aec9f2801412d9ea48116a97d ]
    
    In preparation for the addition of kunit tests, expose the logic
    responsible for combining channel scales.
    
    Signed-off-by: Liam Beguin <[email protected]>
    Reviewed-by: Peter Rosin <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Stable-dep-of: bee448390e51 ("iio: afe: rescale: Accept only offset channels")
    Signed-off-by: Sasha Levin <[email protected]>

iio: afe: rescale: reorder includes [+ + +]
Author: Liam Beguin <[email protected]>
Date:   Sat Jan 8 15:53:08 2022 -0500

    iio: afe: rescale: reorder includes
    
    [ Upstream commit cd717ac6f69db4953ca701c6220c7cb58e17f35a ]
    
    Includes should be ordered alphabetically which is already the case,
    but follow what is done in other drivers by separation IIO specific
    headers with a blank line.
    
    Signed-off-by: Liam Beguin <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Stable-dep-of: bee448390e51 ("iio: afe: rescale: Accept only offset channels")
    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: 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/riscv-intc: Mark all INTC nodes as initialized [+ + +]
Author: Anup Patel <[email protected]>
Date:   Tue Oct 3 10:13:51 2023 +0530

    irqchip/riscv-intc: Mark all INTC nodes as initialized
    
    [ Upstream commit e13cd66bd821be417c498a34928652db4ac6b436 ]
    
    The RISC-V INTC local interrupts are per-HART (or per-CPU) so we
    create INTC IRQ domain only for the INTC node belonging to the boot
    HART. This means only the boot HART INTC node will be marked as
    initialized and other INTC nodes won't be marked which results
    downstream interrupt controllers (such as PLIC, IMSIC and APLIC
    direct-mode) not being probed due to missing device suppliers.
    
    To address this issue, we mark all INTC node for which we don't
    create IRQ domain as initialized.
    
    Reported-by: Dmitry Dunaev <[email protected]>
    Signed-off-by: Anup Patel <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/r/2[email protected]
    Link: https://lore.kernel.org/r/[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]>

 
kasan: print the original fault addr when access invalid shadow [+ + +]
Author: Haibo Li <[email protected]>
Date:   Mon Oct 9 15:37:48 2023 +0800

    kasan: print the original fault addr when access invalid shadow
    
    commit babddbfb7d7d70ae7f10fedd75a45d8ad75fdddf upstream.
    
    when the checked address is illegal,the corresponding shadow address from
    kasan_mem_to_shadow may have no mapping in mmu table.  Access such shadow
    address causes kernel oops.  Here is a sample about oops on arm64(VA
    39bit) with KASAN_SW_TAGS and KASAN_OUTLINE on:
    
    [ffffffb80aaaaaaa] pgd=000000005d3ce003, p4d=000000005d3ce003,
        pud=000000005d3ce003, pmd=0000000000000000
    Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 3 PID: 100 Comm: sh Not tainted 6.6.0-rc1-dirty #43
    Hardware name: linux,dummy-virt (DT)
    pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : __hwasan_load8_noabort+0x5c/0x90
    lr : do_ib_ob+0xf4/0x110
    ffffffb80aaaaaaa is the shadow address for efffff80aaaaaaaa.
    The problem is reading invalid shadow in kasan_check_range.
    
    The generic kasan also has similar oops.
    
    It only reports the shadow address which causes oops but not
    the original address.
    
    Commit 2f004eea0fc8("x86/kasan: Print original address on #GP")
    introduce to kasan_non_canonical_hook but limit it to KASAN_INLINE.
    
    This patch extends it to KASAN_OUTLINE mode.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 2f004eea0fc8("x86/kasan: Print original address on #GP")
    Signed-off-by: Haibo Li <[email protected]>
    Reviewed-by: Andrey Konovalov <[email protected]>
    Cc: Alexander Potapenko <[email protected]>
    Cc: Andrey Ryabinin <[email protected]>
    Cc: AngeloGioacchino Del Regno <[email protected]>
    Cc: Dmitry Vyukov <[email protected]>
    Cc: Haibo Li <[email protected]>
    Cc: Matthias Brugger <[email protected]>
    Cc: Vincenzo Frascino <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Kees Cook <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 5.15.138 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed Nov 8 17:26:52 2023 +0100

    Linux 5.15.138
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: SeongJae Park <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Harshit Mogalapalli <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Ricardo B. Marliere <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Pavel Machek (CIP) <[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]>

 
misc: fastrpc: Clean buffers on remote invocation failures [+ + +]
Author: Ekansh Gupta <[email protected]>
Date:   Fri Oct 13 13:20:06 2023 +0100

    misc: fastrpc: Clean buffers on remote invocation failures
    
    commit 1c8093591d1e372d700fe65423e7315a8ecf721b upstream.
    
    With current design, buffers and dma handles are not freed in case
    of remote invocation failures returned from DSP. This could result
    in buffer leakings and dma handle pointing to wrong memory in the
    fastrpc kernel. Adding changes to clean buffers and dma handles
    even when remote invocation to DSP returns failures.
    
    Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
    Cc: stable <[email protected]>
    Signed-off-by: Ekansh Gupta <[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]>

misc: pci_endpoint_test: Add deviceID for J721S2 PCIe EP device support [+ + +]
Author: Siddharth Vadapalli <[email protected]>
Date:   Fri Oct 20 17:32:48 2023 +0530

    misc: pci_endpoint_test: Add deviceID for J721S2 PCIe EP device support
    
    commit 8293703a492ae97c86af27c75b76e6239ec86483 upstream.
    
    Add DEVICE_ID for J721S2 and enable support for endpoints configured
    with this DEVICE_ID in the pci_endpoint_test driver.
    
    Signed-off-by: Siddharth Vadapalli <[email protected]>
    Cc: stable <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/migrate: fix do_pages_move for compat pointers [+ + +]
Author: Gregory Price <[email protected]>
Date:   Tue Oct 3 10:48:56 2023 -0400

    mm/migrate: fix do_pages_move for compat pointers
    
    commit 229e2253766c7cdfe024f1fe280020cc4711087c upstream.
    
    do_pages_move does not handle compat pointers for the page list.
    correctly.  Add in_compat_syscall check and appropriate get_user fetch
    when iterating the page list.
    
    It makes the syscall in compat mode (32-bit userspace, 64-bit kernel)
    work the same way as the native 32-bit syscall again, restoring the
    behavior before my broken commit 5b1b561ba73c ("mm: simplify
    compat_sys_move_pages").
    
    More specifically, my patch moved the parsing of the 'pages' array from
    the main entry point into do_pages_stat(), which left the syscall
    working correctly for the 'stat' operation (nodes = NULL), while the
    'move' operation (nodes != NULL) is now missing the conversion and
    interprets 'pages' as an array of 64-bit pointers instead of the
    intended 32-bit userspace pointers.
    
    It is possible that nobody noticed this bug because the few
    applications that actually call move_pages are unlikely to run in
    compat mode because of their large memory requirements, but this
    clearly fixes a user-visible regression and should have been caught by
    ltp.
    
    Link: https://lkml.kernel.org/r/20231003144857.752952-1-gregory.pr[email protected]
    Fixes: 5b1b561ba73c ("mm: simplify compat_sys_move_pages")
    Signed-off-by: Gregory Price <[email protected]>
    Reported-by: Arnd Bergmann <[email protected]>
    Co-developed-by: Arnd Bergmann <[email protected]>
    Cc: Jonathan Cameron <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/page_alloc: correct start page when guard page debug is enabled [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Wed Sep 27 17:44:01 2023 +0800

    mm/page_alloc: correct start page when guard page debug is enabled
    
    commit 61e21cf2d2c3cc5e60e8d0a62a77e250fccda62c upstream.
    
    When guard page debug is enabled and set_page_guard returns success, we
    miss to forward page to point to start of next split range and we will do
    split unexpectedly in page range without target page.  Move start page
    update before set_page_guard to fix this.
    
    As we split to wrong target page, then splited pages are not able to merge
    back to original order when target page is put back and splited pages
    except target page is not usable.  To be specific:
    
    Consider target page is the third page in buddy page with order 2.
    | buddy-2 | Page | Target | Page |
    
    After break down to target page, we will only set first page to Guard
    because of bug.
    | Guard   | Page | Target | Page |
    
    When we try put_page_back_buddy with target page, the buddy page of target
    if neither guard nor buddy, Then it's not able to construct original page
    with order 2
    | Guard | Page | buddy-0 | Page |
    
    All pages except target page is not in free list and is not usable.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 06be6ff3d2ec ("mm,hwpoison: rework soft offline for free pages")
    Signed-off-by: Kemeng Shi <[email protected]>
    Acked-by: Naoya Horiguchi <[email protected]>
    Cc: Matthew Wilcox (Oracle) <[email protected]>
    Cc: Oscar Salvador <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mptcp: more conservative check for zero probes [+ + +]
Author: Paolo Abeni <[email protected]>
Date:   Wed Oct 18 11:23:54 2023 -0700

    mptcp: more conservative check for zero probes
    
    [ Upstream commit 72377ab2d671befd6390a1d5677f5cca61235b65 ]
    
    Christoph reported that the MPTCP protocol can find the subflow-level
    write queue unexpectedly not empty while crafting a zero-window probe,
    hitting a warning:
    
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
    Modules linked in:
    CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
    Workqueue: events mptcp_worker
    RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
    RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
    RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
    RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
    R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
    R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
    FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
    Call Trace:
     <TASK>
     __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
     __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
     mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
     release_sock+0xf6/0x100 net/core/sock.c:3521
     mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
     process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
     worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
     kthread+0x143/0x180 kernel/kthread.c:388
     ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
     </TASK>
    
    The root cause of the issue is that expectations are wrong: e.g. due
    to MPTCP-level re-injection we can hit the critical condition.
    
    Explicitly avoid the zero-window probe when the subflow write queue
    is not empty and drop the related warnings.
    
    Reported-by: Christoph Paasch <[email protected]>
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/444
    Fixes: f70cad1085d1 ("mptcp: stop relying on tcp_tx_skb_cache")
    Cc: [email protected]
    Reviewed-by: Mat Martineau <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Mat Martineau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[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]>

net: sched: cls_u32: Fix allocation size in u32_init() [+ + +]
Author: Gustavo A. R. Silva <[email protected]>
Date:   Wed Oct 4 15:19:37 2023 +0200

    net: sched: cls_u32: Fix allocation size in u32_init()
    
    [ Upstream commit c4d49196ceec80e30e8d981410d73331b49b7850 ]
    
    commit d61491a51f7e ("net/sched: cls_u32: Replace one-element array
    with flexible-array member") incorrecly replaced an instance of
    `sizeof(*tp_c)` with `struct_size(tp_c, hlist->ht, 1)`. This results
    in a an over-allocation of 8 bytes.
    
    This change is wrong because `hlist` in `struct tc_u_common` is a
    pointer:
    
    net/sched/cls_u32.c:
    struct tc_u_common {
            struct tc_u_hnode __rcu *hlist;
            void                    *ptr;
            int                     refcnt;
            struct idr              handle_idr;
            struct hlist_node       hnode;
            long                    knodes;
    };
    
    So, the use of `struct_size()` makes no sense: we don't need to allocate
    any extra space for a flexible-array member. `sizeof(*tp_c)` is just fine.
    
    So, `struct_size(tp_c, hlist->ht, 1)` translates to:
    
    sizeof(*tp_c) + sizeof(tp_c->hlist->ht) ==
    sizeof(struct tc_u_common) + sizeof(struct tc_u_knode *) ==
                                                    144 + 8  == 0x98 (byes)
                                                         ^^^
                                                          |
                                                    unnecessary extra
                                                    allocation size
    
    $ pahole -C tc_u_common net/sched/cls_u32.o
    struct tc_u_common {
            struct tc_u_hnode *        hlist;                /*     0     8 */
            void *                     ptr;                  /*     8     8 */
            int                        refcnt;               /*    16     4 */
    
            /* XXX 4 bytes hole, try to pack */
    
            struct idr                 handle_idr;           /*    24    96 */
            /* --- cacheline 1 boundary (64 bytes) was 56 bytes ago --- */
            struct hlist_node          hnode;                /*   120    16 */
            /* --- cacheline 2 boundary (128 bytes) was 8 bytes ago --- */
            long int                   knodes;               /*   136     8 */
    
            /* size: 144, cachelines: 3, members: 6 */
            /* sum members: 140, holes: 1, sum holes: 4 */
            /* last cacheline: 16 bytes */
    };
    
    And with `sizeof(*tp_c)`, we have:
    
            sizeof(*tp_c) == sizeof(struct tc_u_common) == 144 == 0x90 (bytes)
    
    which is the correct and original allocation size.
    
    Fix this issue by replacing `struct_size(tp_c, hlist->ht, 1)` with
    `sizeof(*tp_c)`, and avoid allocating 8 too many bytes.
    
    The following difference in binary output is expected and reflects the
    desired change:
    
    | net/sched/cls_u32.o
    | @@ -6148,7 +6148,7 @@
    | include/linux/slab.h:599
    |     2cf5:      mov    0x0(%rip),%rdi        # 2cfc <u32_init+0xfc>
    |                        2cf8: R_X86_64_PC32     kmalloc_caches+0xc
    |-    2cfc:      mov    $0x98,%edx
    |+    2cfc:      mov    $0x90,%edx
    
    Reported-by: Alejandro Colomar <[email protected]>
    Closes: https://lore.kernel.org/lkml/[email protected]/
    Signed-off-by: Gustavo A. R. Silva <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: smsc95xx: Fix uninit-value access in smsc95xx_read_reg [+ + +]
Author: Shigeru Yoshida <[email protected]>
Date:   Sat Oct 21 02:03:44 2023 +0900

    net: usb: smsc95xx: Fix uninit-value access in smsc95xx_read_reg
    
    [ Upstream commit 51a32e828109b4a209efde44505baa356b37a4ce ]
    
    syzbot reported the following uninit-value access issue [1]:
    
    smsc95xx 1-1:0.0 (unnamed net_device) (uninitialized): Failed to read reg index 0x00000030: -32
    smsc95xx 1-1:0.0 (unnamed net_device) (uninitialized): Error reading E2P_CMD
    =====================================================
    BUG: KMSAN: uninit-value in smsc95xx_reset+0x409/0x25f0 drivers/net/usb/smsc95xx.c:896
     smsc95xx_reset+0x409/0x25f0 drivers/net/usb/smsc95xx.c:896
     smsc95xx_bind+0x9bc/0x22e0 drivers/net/usb/smsc95xx.c:1131
     usbnet_probe+0x100b/0x4060 drivers/net/usb/usbnet.c:1750
     usb_probe_interface+0xc75/0x1210 drivers/usb/core/driver.c:396
     really_probe+0x506/0xf40 drivers/base/dd.c:658
     __driver_probe_device+0x2a7/0x5d0 drivers/base/dd.c:800
     driver_probe_device+0x72/0x7b0 drivers/base/dd.c:830
     __device_attach_driver+0x55a/0x8f0 drivers/base/dd.c:958
     bus_for_each_drv+0x3ff/0x620 drivers/base/bus.c:457
     __device_attach+0x3bd/0x640 drivers/base/dd.c:1030
     device_initial_probe+0x32/0x40 drivers/base/dd.c:1079
     bus_probe_device+0x3d8/0x5a0 drivers/base/bus.c:532
     device_add+0x16ae/0x1f20 drivers/base/core.c:3622
     usb_set_configuration+0x31c9/0x38c0 drivers/usb/core/message.c:2207
     usb_generic_driver_probe+0x109/0x2a0 drivers/usb/core/generic.c:238
     usb_probe_device+0x290/0x4a0 drivers/usb/core/driver.c:293
     really_probe+0x506/0xf40 drivers/base/dd.c:658
     __driver_probe_device+0x2a7/0x5d0 drivers/base/dd.c:800
     driver_probe_device+0x72/0x7b0 drivers/base/dd.c:830
     __device_attach_driver+0x55a/0x8f0 drivers/base/dd.c:958
     bus_for_each_drv+0x3ff/0x620 drivers/base/bus.c:457
     __device_attach+0x3bd/0x640 drivers/base/dd.c:1030
     device_initial_probe+0x32/0x40 drivers/base/dd.c:1079
     bus_probe_device+0x3d8/0x5a0 drivers/base/bus.c:532
     device_add+0x16ae/0x1f20 drivers/base/core.c:3622
     usb_new_device+0x15f6/0x22f0 drivers/usb/core/hub.c:2589
     hub_port_connect drivers/usb/core/hub.c:5440 [inline]
     hub_port_connect_change drivers/usb/core/hub.c:5580 [inline]
     port_event drivers/usb/core/hub.c:5740 [inline]
     hub_event+0x53bc/0x7290 drivers/usb/core/hub.c:5822
     process_one_work kernel/workqueue.c:2630 [inline]
     process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2703
     worker_thread+0xf45/0x1490 kernel/workqueue.c:2784
     kthread+0x3e8/0x540 kernel/kthread.c:388
     ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
    
    Local variable buf.i225 created at:
     smsc95xx_read_reg drivers/net/usb/smsc95xx.c:90 [inline]
     smsc95xx_reset+0x203/0x25f0 drivers/net/usb/smsc95xx.c:892
     smsc95xx_bind+0x9bc/0x22e0 drivers/net/usb/smsc95xx.c:1131
    
    CPU: 1 PID: 773 Comm: kworker/1:2 Not tainted 6.6.0-rc1-syzkaller-00125-ge42bebf6db29 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
    Workqueue: usb_hub_wq hub_event
    =====================================================
    
    Similar to e9c65989920f ("net: usb: smsc75xx: Fix uninit-value access in
    __smsc75xx_read_reg"), this issue is caused because usbnet_read_cmd() reads
    less bytes than requested (zero byte in the reproducer). In this case,
    'buf' is not properly filled.
    
    This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
    less bytes than requested.
    
    sysbot reported similar uninit-value access issue [2]. The root cause is
    the same as mentioned above, and this patch addresses it as well.
    
    Fixes: 2f7ca802bdae ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
    Reported-and-tested-by: [email protected]
    Reported-and-tested-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=c74c24b43c9ae534f0e0 [1]
    Closes: https://syzkaller.appspot.com/bug?extid=2c97a98a5ba9ea9c23bd [2]
    Signed-off-by: Shigeru Yoshida <[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]>

 
objtool/x86: add missing embedded_insn check [+ + +]
Author: John Sperbeck <[email protected]>
Date:   Sat Oct 28 18:41:31 2023 +0000

    objtool/x86: add missing embedded_insn check
    
    When dbf460087755 ("objtool/x86: Fixup frame-pointer vs rethunk")
    was backported to some stable branches, the check for dest->embedded_insn
    in is_special_call() was missed.  The result is that the warning it
    was intended to suppress still appears.  For example on 6.1 (on kernels
    before 6.1, the '-s' argument would instead be 'check'):
    
    $ tools/objtool/objtool -s arch/x86/lib/retpoline.o
    arch/x86/lib/retpoline.o: warning: objtool: srso_untrain_ret+0xd:
        call without frame pointer save/setup
    
    With this patch, the warning is correctly suppressed, and the
    kernel still passes the normal Google kernel developer tests.
    
    Signed-off-by: John Sperbeck <[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]>

 
pinctrl: qcom: lpass-lpi: fix concurrent register updates [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Oct 13 16:57:05 2023 +0200

    pinctrl: qcom: lpass-lpi: fix concurrent register updates
    
    [ Upstream commit c8befdc411e5fd1bf95a13e8744c8ca79b412bee ]
    
    The Qualcomm LPASS LPI pin controller driver uses one lock for guarding
    Read-Modify-Write code for slew rate registers.  However the pin
    configuration and muxing registers have exactly the same RMW code but
    are not protected.
    
    Pin controller framework does not provide locking here, thus it is
    possible to trigger simultaneous change of pin configuration registers
    resulting in non-atomic changes.
    
    Protect from concurrent access by re-using the same lock used to cover
    the slew rate register.  Using the same lock instead of adding second
    one will make more sense, once we add support for newer Qualcomm SoC,
    where slew rate is configured in the same register as pin
    configuration/muxing.
    
    Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver")
    Cc: [email protected]
    Reviewed-by: Linus Walleij <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[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]>

 
powerpc/85xx: Fix math emulation exception [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Mon Sep 25 17:55:51 2023 +0200

    powerpc/85xx: Fix math emulation exception
    
    [ Upstream commit 8e8a12ecbc86700b5e1a3596ce2b3c43dafad336 ]
    
    Booting mpc85xx_defconfig kernel on QEMU leads to:
    
    Bad trap at PC: fe9bab0, SR: 2d000, vector=800
    awk[82]: unhandled trap (5) at 0 nip fe9bab0 lr fe9e01c code 5 in libc-2.27.so[fe5a000+17a000]
    awk[82]: code: 3aa00000 3a800010 4bffe03c 9421fff0 7ca62b78 38a00000 93c10008 83c10008
    awk[82]: code: 38210010 4bffdec8 9421ffc0 7c0802a6 <fc00048e> d8010008 4815190d 93810030
    Trace/breakpoint trap
    WARNING: no useful console
    
    This is because allthough CONFIG_MATH_EMULATION is selected,
    Exception 800 calls unknown_exception().
    
    Call emulation_assist_interrupt() instead.
    
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/066caa6d9480365da9b8ed83692d7101e10ac5f8.1695657339.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/mm: Fix boot crash with FLATMEM [+ + +]
Author: Michael Ellerman <[email protected]>
Date:   Mon Oct 23 22:25:00 2023 +1100

    powerpc/mm: Fix boot crash with FLATMEM
    
    [ Upstream commit daa9ada2093ed23d52b4c1fe6e13cf78f55cc85f ]
    
    Erhard reported that his G5 was crashing with v6.6-rc kernels:
    
      mpic: Setting up HT PICs workarounds for U3/U4
      BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe
      Faulting instruction address: 0xc00000000005dc40
      Oops: Kernel access of bad area, sig: 11 [#1]
      BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G                T  6.6.0-rc3-PMacGS #1
      Hardware name: PowerMac11,2 PPC970MP 0x440101 PowerMac
      NIP:  c00000000005dc40 LR: c000000000066660 CTR: c000000000007730
      REGS: c0000000022bf510 TRAP: 0380   Tainted: G                T (6.6.0-rc3-PMacGS)
      MSR:  9000000000001032 <SF,HV,ME,IR,DR,RI>  CR: 44004242  XER: 00000000
      IRQMASK: 3
      GPR00: 0000000000000000 c0000000022bf7b0 c0000000010c0b00 00000000000001ac
      GPR04: 0000000003c80000 0000000000000300 c0000000f20001ae 0000000000000300
      GPR08: 0000000000000006 feffbb62ffec65ff 0000000000000001 0000000000000000
      GPR12: 9000000000001032 c000000002362000 c000000000f76b80 000000000349ecd8
      GPR16: 0000000002367ba8 0000000002367f08 0000000000000006 0000000000000000
      GPR20: 00000000000001ac c000000000f6f920 c0000000022cd985 000000000000000c
      GPR24: 0000000000000300 00000003b0a3691d c0003e008030000e 0000000000000000
      GPR28: c00000000000000c c0000000f20001ee feffbb62ffec65fe 00000000000001ac
      NIP hash_page_do_lazy_icache+0x50/0x100
      LR  __hash_page_4K+0x420/0x590
      Call Trace:
        hash_page_mm+0x364/0x6f0
        do_hash_fault+0x114/0x2b0
        data_access_common_virt+0x198/0x1f0
      --- interrupt: 300 at mpic_init+0x4bc/0x10c4
      NIP:  c000000002020a5c LR: c000000002020a04 CTR: 0000000000000000
      REGS: c0000000022bf9f0 TRAP: 0300   Tainted: G                T (6.6.0-rc3-PMacGS)
      MSR:  9000000000001032 <SF,HV,ME,IR,DR,RI>  CR: 24004248  XER: 00000000
      DAR: c0003e008030000e DSISR: 40000000 IRQMASK: 1
      ...
      NIP mpic_init+0x4bc/0x10c4
      LR  mpic_init+0x464/0x10c4
      --- interrupt: 300
        pmac_setup_one_mpic+0x258/0x2dc
        pmac_pic_init+0x28c/0x3d8
        init_IRQ+0x90/0x140
        start_kernel+0x57c/0x78c
        start_here_common+0x1c/0x20
    
    A bisect pointed to the breakage beginning with commit 9fee28baa601 ("powerpc:
    implement the new page table range API").
    
    Analysis of the oops pointed to a struct page with a corrupted
    compound_head being loaded via page_folio() -> _compound_head() in
    hash_page_do_lazy_icache().
    
    The access by the mpic code is to an MMIO address, so the expectation
    is that the struct page for that address would be initialised by
    init_unavailable_range(), as pointed out by Aneesh.
    
    Instrumentation showed that was not the case, which eventually lead to
    the realisation that pfn_valid() was returning false for that address,
    causing the struct page to not be initialised.
    
    Because the system is using FLATMEM, the version of pfn_valid() in
    memory_model.h is used:
    
    static inline int pfn_valid(unsigned long pfn)
    {
            ...
            return pfn >= pfn_offset && (pfn - pfn_offset) < max_mapnr;
    }
    
    Which relies on max_mapnr being initialised. Early in boot max_mapnr is
    zero meaning no PFNs are valid.
    
    max_mapnr is initialised in mem_init() called via:
    
      start_kernel()
        mm_core_init()  # init/main.c:928
          mem_init()
    
    But that is too late for the usage in init_unavailable_range() called via:
    
      start_kernel()
        setup_arch()    # init/main.c:893
          paging_init()
            free_area_init()
              init_unavailable_range()
    
    Although max_mapnr is currently set in mem_init(), the value is actually
    already available much earlier, as soon as mem_topology_setup() has
    completed, which is also before paging_init() is called. So move the
    initialisation there, which causes paging_init() to correctly initialise
    the struct page and fixes the bug.
    
    This bug seems to have been lurking for years, but went unnoticed
    because the pre-folio code was inspecting the uninitialised page->flags
    but not dereferencing it.
    
    Thanks to Erhard and Aneesh for help debugging.
    
    Reported-by: Erhard Furtner <[email protected]>
    Closes: https://lore.kernel.org/all/20230929132750.3cd98452@yea/
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[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: Check for unplug in r8153b_ups_en() / r8153c_ups_en() [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Fri Oct 20 14:06:57 2023 -0700

    r8152: Check for unplug in r8153b_ups_en() / r8153c_ups_en()
    
    [ Upstream commit bc65cc42af737a5a35f83842408ef2c6c79ba025 ]
    
    If the adapter is unplugged while we're looping in r8153b_ups_en() /
    r8153c_ups_en() we could end up looping for 10 seconds (20 ms * 500
    loops). Add code similar to what's done in other places in the driver
    to check for unplug and bail.
    
    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: Check for unplug in rtl_phy_patch_request() [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Fri Oct 20 14:06:56 2023 -0700

    r8152: Check for unplug in rtl_phy_patch_request()
    
    [ Upstream commit dc90ba37a8c37042407fa6970b9830890cfe6047 ]
    
    If the adapter is unplugged while we're looping in
    rtl_phy_patch_request() we could end up looping for 10 seconds (2 ms *
    5000 loops). Add code similar to what's done in other places in the
    driver to check for unplug and bail.
    
    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: Release firmware if we have an error in probe [+ + +]
Author: Douglas Anderson <[email protected]>
Date:   Fri Oct 20 14:06:55 2023 -0700

    r8152: Release firmware if we have an error in probe
    
    [ Upstream commit b8d35024d4059ca550cba11ac9ab23a6c238d929 ]
    
    The error handling in rtl8152_probe() is missing a call to release
    firmware. Add it in to match what's in the cleanup code in
    rtl8152_disconnect().
    
    Fixes: 9370f2d05a2a ("r8152: support request_firmware for RTL8153")
    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]>

r8169: fix the KCSAN reported data-race in rtl_tx() while reading tp->cur_tx [+ + +]
Author: Mirsad Goran Todorovac <[email protected]>
Date:   Wed Oct 18 21:34:34 2023 +0200

    r8169: fix the KCSAN reported data-race in rtl_tx() while reading tp->cur_tx
    
    [ Upstream commit c1c0ce31b2420d5c173228a2132a492ede03d81f ]
    
    KCSAN reported the following data-race:
    
    ==================================================================
    BUG: KCSAN: data-race in rtl8169_poll [r8169] / rtl8169_start_xmit [r8169]
    
    write (marked) to 0xffff888102474b74 of 4 bytes by task 5358 on cpu 29:
    rtl8169_start_xmit (drivers/net/ethernet/realtek/r8169_main.c:4254) r8169
    dev_hard_start_xmit (./include/linux/netdevice.h:4889 ./include/linux/netdevice.h:4903 net/core/dev.c:3544 net/core/dev.c:3560)
    sch_direct_xmit (net/sched/sch_generic.c:342)
    __dev_queue_xmit (net/core/dev.c:3817 net/core/dev.c:4306)
    ip_finish_output2 (./include/linux/netdevice.h:3082 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv4/ip_output.c:233)
    __ip_finish_output (net/ipv4/ip_output.c:311 net/ipv4/ip_output.c:293)
    ip_finish_output (net/ipv4/ip_output.c:328)
    ip_output (net/ipv4/ip_output.c:435)
    ip_send_skb (./include/net/dst.h:458 net/ipv4/ip_output.c:127 net/ipv4/ip_output.c:1486)
    udp_send_skb (net/ipv4/udp.c:963)
    udp_sendmsg (net/ipv4/udp.c:1246)
    inet_sendmsg (net/ipv4/af_inet.c:840 (discriminator 4))
    sock_sendmsg (net/socket.c:730 net/socket.c:753)
    __sys_sendto (net/socket.c:2177)
    __x64_sys_sendto (net/socket.c:2185)
    do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
    
    read to 0xffff888102474b74 of 4 bytes by interrupt on cpu 21:
    rtl8169_poll (drivers/net/ethernet/realtek/r8169_main.c:4397 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)
    common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14))
    asm_common_interrupt (./arch/x86/include/asm/idtentry.h:636)
    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: 0x002f4815 -> 0x002f4816
    
    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 write side of drivers/net/ethernet/realtek/r8169_main.c is:
    ==================
       4251         /* rtl_tx needs to see descriptor changes before updated tp->cur_tx */
       4252         smp_wmb();
       4253
     → 4254         WRITE_ONCE(tp->cur_tx, tp->cur_tx + frags + 1);
       4255
       4256         stop_queue = !netif_subqueue_maybe_stop(dev, 0, rtl_tx_slots_avail(tp),
       4257                                                 R8169_TX_STOP_THRS,
       4258                                                 R8169_TX_START_THRS);
    
    The read side is the function rtl_tx():
    
       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 (tp->cur_tx != dirty_tx && skb)
       4398                         rtl8169_doorbell(tp);
       4399         }
       4400 }
    
    Obviously from the code, an earlier detected data-race for tp->cur_tx was fixed in the
    line 4363:
    
       4363         while (READ_ONCE(tp->cur_tx) != dirty_tx) {
    
    but the same solution is required for protecting the other access to tp->cur_tx:
    
     → 4397                 if (READ_ONCE(tp->cur_tx) != dirty_tx && skb)
       4398                         rtl8169_doorbell(tp);
    
    The write in the line 4254 is protected with WRITE_ONCE(), but the read in the line 4397
    might have suffered read tearing under some compiler optimisations.
    
    The fix eliminated the KCSAN data-race report for this bug.
    
    It is yet to be evaluated what happens if tp->cur_tx changes between the test in line 4363
    and line 4397. This test should certainly not be cached by the compiler in some register
    for such a long time, while asynchronous writes to tp->cur_tx might have occurred in line
    4254 in the meantime.
    
    Fixes: 94d8a98e6235c ("r8169: reduce number of workaround doorbell rings")
    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]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
rpmsg: Constify local variable in field store macro [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Oct 31 11:25:36 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:25:38 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 <krzysztof.k[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:25:37 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:25:40 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:25:39 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/20230109223931.1706429-1-quic_bjorande@quicinc.com
    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/20231015114529[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sparc32: fix a braino in fault handling in csum_and_copy_..._user() [+ + +]
Author: Al Viro <[email protected]>
Date:   Sun Oct 22 19:34:28 2023 -0400

    sparc32: fix a braino in fault handling in csum_and_copy_..._user()
    
    commit 1f36cd05e0081f2c75769a551d584c4ffb2a5660 upstream.
    
    Fault handler used to make non-trivial calls, so it needed
    to set a stack frame up.  Used to be
            save ... - grab a stack frame, old %o... become %i...
            ....
            ret     - go back to address originally in %o7, currently %i7
             restore - switch to previous stack frame, in delay slot
    Non-trivial calls had been gone since ab5e8b331244 and that code should
    have become
            retl    - go back to address in %o7
             clr %o0 - have return value set to 0
    What it had become instead was
            ret     - go back to address in %i7 - return address of *caller*
             clr %o0 - have return value set to 0
    which is not good, to put it mildly - we forcibly return 0 from
    csum_and_copy_{from,to}_iter() (which is what the call of that
    thing had been inlined into) and do that without dropping the
    stack frame of said csum_and_copy_..._iter().  Confuses the
    hell out of the caller of csum_and_copy_..._iter(), obviously...
    
    Reviewed-by: Sam Ravnborg <[email protected]>
    Fixes: ab5e8b331244 "sparc32: propagate the calling conventions change down to __csum_partial_copy_sparc_generic()"
    Signed-off-by: Al Viro <[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: cleanup tcp_remove_empty_skb() use [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed Oct 27 13:19:18 2021 -0700

    tcp: cleanup tcp_remove_empty_skb() use
    
    [ Upstream commit 27728ba80f1eb279b209bbd5922fdeebe52d9e30 ]
    
    All tcp_remove_empty_skb() callers now use tcp_write_queue_tail()
    for the skb argument, we can therefore factorize code.
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 72377ab2d671 ("mptcp: more conservative check for zero probes")
    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]>

tcp: remove dead code from tcp_sendmsg_locked() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed Oct 27 13:19:17 2021 -0700

    tcp: remove dead code from tcp_sendmsg_locked()
    
    [ Upstream commit 3ded97bc41a1e76e1e72eeb192331c01ceacc4bc ]
    
    TCP sendmsg() no longer puts payload in skb head, we can remove
    dead code.
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 72377ab2d671 ("mptcp: more conservative check for zero probes")
    Signed-off-by: Sasha Levin <[email protected]>

 
tracing/kprobes: Fix the description of variable length arguments [+ + +]
Author: Yujie Liu <[email protected]>
Date:   Fri Oct 27 12:13:14 2023 +0800

    tracing/kprobes: Fix the description of variable length arguments
    
    commit e0f831836cead677fb07d54bd6bf499df35640c2 upstream.
    
    Fix the following kernel-doc warnings:
    
    kernel/trace/trace_kprobe.c:1029: warning: Excess function parameter 'args' description in '__kprobe_event_gen_cmd_start'
    kernel/trace/trace_kprobe.c:1097: warning: Excess function parameter 'args' description in '__kprobe_event_add_fields'
    
    Refer to the usage of variable length arguments elsewhere in the kernel
    code, "@..." is the proper way to express it in the description.
    
    Link: https://lore.kernel.org/all/[email protected]/
    
    Fixes: 2a588dd1d5d6 ("tracing: Add kprobe event command generation functions")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Yujie Liu <[email protected]>
    Reviewed-by: Mukesh Ojha <[email protected]>
    Acked-by: Masami Hiramatsu (Google) <[email protected]>
    Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[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 Brainboxes Oxford Semiconductor-based quirks [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:17 2023 +0100

    tty: 8250: Add Brainboxes Oxford Semiconductor-based quirks
    
    commit e4876dacaca46a1b09f9b417480924ab12019a5b upstream.
    
    Some of the later revisions of the Brainboxes PX cards are based
    on the Oxford Semiconductor chipset. Due to the chip's unique setup
    these cards need to be initialised.
    Previously these were tested against a reference card with the same broken
    baudrate on another PC, cancelling out the effect. With this patch they
    work and can transfer/receive find against an FTDI-based device.
    
    Add all of the cards which require this setup to the quirks table.
    Thanks to Maciej W. Rozycki for clarification on this chip.
    
    Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.")
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB7899D222A4AB2A4E8C57108FC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

    tty: 8250: Add support for additional Brainboxes PX cards
    
    commit 9604884e592cd04ead024c9737c67a77f175cab9 upstream.
    
    Add support for some more of the Brainboxes PX (PCIe) range
    of serial cards, namely
    PX-275/PX-279, PX-475 (serial port, not LPT), PX-820,
    PX-803/PX-857 (additional ID).
    
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB78996BEC353FB346FC35444BC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[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: Add support for Intashield IX cards [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:16 2023 +0100

    tty: 8250: Add support for Intashield IX cards
    
    commit 62d2ec2ded278c7512d91ca7bf8eb9bac46baf90 upstream.
    
    Add support for the IX-100, IX-200 and IX-400 serial cards.
    
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB7899614E5837E82A03272A4BC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Fix port count of PX-257 [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:12 2023 +0100

    tty: 8250: Fix port count of PX-257
    
    commit d0ff5b24c2f112f29dea4c38b3bac9597b1be9ba upstream.
    
    The port count of the PX-257 Rev3 is actually 2, not 4.
    
    Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.")
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB7899C804D9F04E727B5A0E8FC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: 8250: Fix up PX-803/PX-857 [+ + +]
Author: Cameron Williams <[email protected]>
Date:   Fri Oct 20 17:03:13 2023 +0100

    tty: 8250: Fix up PX-803/PX-857
    
    commit ee61337b934c99c2611e0a945d592019b2e00c82 upstream.
    
    The PX-803/PX-857 are variants of each other, add a note.
    Additionally fix up the port counts for the card (2, not 1).
    
    Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.")
    Cc: [email protected]
    Signed-off-by: Cameron Williams <[email protected]>
    Link: https://lore.kernel.org/r/DU0PR02MB789978C8ED872FB4B014E132C4DBA@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]>

tty: n_gsm: fix race condition in status line change on dead connections [+ + +]
Author: Daniel Starke <[email protected]>
Date:   Thu Oct 26 07:58:43 2023 +0200

    tty: n_gsm: fix race condition in status line change on dead connections
    
    commit 3a75b205de43365f80a33b98ec9289785da56243 upstream.
    
    gsm_cleanup_mux() cleans up the gsm by closing all DLCIs, stopping all
    timers, removing the virtual tty devices and clearing the data queues.
    This procedure, however, may cause subsequent changes of the virtual modem
    status lines of a DLCI. More data is being added the outgoing data queue
    and the deleted kick timer is restarted to handle this. At this point many
    resources have already been removed by the cleanup procedure. Thus, a
    kernel panic occurs.
    
    Fix this by proving in gsm_modem_update() that the cleanup procedure has
    not been started and the mux is still alive.
    
    Note that writing to a virtual tty is already protected by checks against
    the DLCI specific connection state.
    
    Fixes: c568f7086c6e ("tty: n_gsm: fix missing timer to handle stalled links")
    Cc: stable <[email protected]>
    Signed-off-by: Daniel Starke <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: raw-gadget: properly handle interrupted requests [+ + +]
Author: Andrey Konovalov <[email protected]>
Date:   Thu Oct 26 22:01:12 2023 +0200

    usb: raw-gadget: properly handle interrupted requests
    
    commit e8033bde451eddfb9b1bbd6e2d848c1b5c277222 upstream.
    
    Currently, if a USB request that was queued by Raw Gadget is interrupted
    (via a signal), wait_for_completion_interruptible returns -ERESTARTSYS.
    Raw Gadget then attempts to propagate this value to userspace as a return
    value from its ioctls. However, when -ERESTARTSYS is returned by a syscall
    handler, the kernel internally restarts the syscall.
    
    This doesn't allow userspace applications to interrupt requests queued by
    Raw Gadget (which is required when the emulated device is asked to switch
    altsettings). It also violates the implied interface of Raw Gadget that a
    single ioctl must only queue a single USB request.
    
    Instead, make Raw Gadget do what GadgetFS does: check whether the request
    was interrupted (dequeued with status == -ECONNRESET) and report -EINTR to
    userspace.
    
    Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
    Cc: stable <[email protected]>
    Signed-off-by: Andrey Konovalov <[email protected]>
    Link: https://lore.kernel.org/r/0db45b1d7cc466e3d4d1ab353f61d63c977fbbc5.1698350424.git.andreyknvl@gmail.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]>

usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm() [+ + +]
Author: Jimmy Hu <[email protected]>
Date:   Fri Oct 20 01:21:32 2023 +0000

    usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm()
    
    commit 4987daf86c152ff882d51572d154ad12e4ff3a4b upstream.
    
    It is possible that typec_register_partner() returns ERR_PTR on failure.
    When port->partner is an error, a NULL pointer dereference may occur as
    shown below.
    
    [91222.095236][  T319] typec port0: failed to register partner (-17)
    ...
    [91225.061491][  T319] Unable to handle kernel NULL pointer dereference
    at virtual address 000000000000039f
    [91225.274642][  T319] pc : tcpm_pd_data_request+0x310/0x13fc
    [91225.274646][  T319] lr : tcpm_pd_data_request+0x298/0x13fc
    [91225.308067][  T319] Call trace:
    [91225.308070][  T319]  tcpm_pd_data_request+0x310/0x13fc
    [91225.308073][  T319]  tcpm_pd_rx_handler+0x100/0x9e8
    [91225.355900][  T319]  kthread_worker_fn+0x178/0x58c
    [91225.355902][  T319]  kthread+0x150/0x200
    [91225.355905][  T319]  ret_from_fork+0x10/0x30
    
    Add a check for port->partner to avoid dereferencing a NULL pointer.
    
    Fixes: 5e1d4c49fbc8 ("usb: typec: tcpm: Determine common SVDM Version")
    Cc: [email protected]
    Signed-off-by: Jimmy Hu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
vhost: Allow null msg.size on VHOST_IOTLB_INVALIDATE [+ + +]
Author: Eric Auger <[email protected]>
Date:   Wed Sep 27 16:05:44 2023 +0200

    vhost: Allow null msg.size on VHOST_IOTLB_INVALIDATE
    
    commit ca50ec377c2e94b0a9f8735de2856cd0f13beab4 upstream.
    
    Commit e2ae38cf3d91 ("vhost: fix hung thread due to erroneous iotlb
    entries") Forbade vhost iotlb msg with null size to prevent entries
    with size = start = 0 and last = ULONG_MAX to end up in the iotlb.
    
    Then commit 95932ab2ea07 ("vhost: allow batching hint without size")
    only applied the check for VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE
    message types to fix a regression observed with batching hit.
    
    Still, the introduction of that check introduced a regression for
    some users attempting to invalidate the whole ULONG_MAX range by
    setting the size to 0. This is the case with qemu/smmuv3/vhost
    integration which does not work anymore. It Looks safe to partially
    revert the original commit and allow VHOST_IOTLB_INVALIDATE messages
    with null size. vhost_iotlb_del_range() will compute a correct end
    iova. Same for vhost_vdpa_iotlb_unmap().
    
    Signed-off-by: Eric Auger <[email protected]>
    Fixes: e2ae38cf3d91 ("vhost: fix hung thread due to erroneous iotlb entries")
    Cc: [email protected] # v5.17+
    Acked-by: Jason Wang <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[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]>

 
vsock/virtio: add support for device suspend/resume [+ + +]
Author: Stefano Garzarella <[email protected]>
Date:   Thu Apr 28 15:22:41 2022 +0200

    vsock/virtio: add support for device suspend/resume
    
    [ Upstream commit bd50c5dc182b0a52599f87b429f9a5a9cbfc9b1c ]
    
    Implement .freeze and .restore callbacks of struct virtio_driver
    to support device suspend/resume.
    
    During suspension all connected sockets are reset and VQs deleted.
    During resume the VQs are re-initialized.
    
    Reported by: Vilas R K <[email protected]>
    Signed-off-by: Stefano Garzarella <[email protected]>
    Acked-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 53b08c498515 ("vsock/virtio: initialize the_virtio_vsock before using VQs")
    Signed-off-by: Sasha Levin <[email protected]>

vsock/virtio: factor our the code to initialize and delete VQs [+ + +]
Author: Stefano Garzarella <[email protected]>
Date:   Thu Apr 28 15:22:40 2022 +0200

    vsock/virtio: factor our the code to initialize and delete VQs
    
    [ Upstream commit a103209886264a3289f7e53e7ed389d0391fb23f ]
    
    Add virtio_vsock_vqs_init() and virtio_vsock_vqs_del() with the code
    that was in virtio_vsock_probe() and virtio_vsock_remove to initialize
    and delete VQs.
    
    These new functions will be used in the next commit to support device
    suspend/resume
    
    Signed-off-by: Stefano Garzarella <[email protected]>
    Acked-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 53b08c498515 ("vsock/virtio: initialize the_virtio_vsock before using VQs")
    Signed-off-by: Sasha Levin <[email protected]>

vsock/virtio: initialize the_virtio_vsock before using VQs [+ + +]
Author: Alexandru Matei <[email protected]>
Date:   Tue Oct 24 22:17:42 2023 +0300

    vsock/virtio: initialize the_virtio_vsock before using VQs
    
    [ Upstream commit 53b08c4985158430fd6d035fb49443bada535210 ]
    
    Once VQs are filled with empty buffers and we kick the host, it can send
    connection requests. If the_virtio_vsock is not initialized before,
    replies are silently dropped and do not reach the host.
    
    virtio_transport_send_pkt() can queue packets once the_virtio_vsock is
    set, but they won't be processed until vsock->tx_run is set to true. We
    queue vsock->send_pkt_work when initialization finishes to send those
    packets queued earlier.
    
    Fixes: 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock")
    Signed-off-by: Alexandru Matei <[email protected]>
    Reviewed-by: Stefano Garzarella <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[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
    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: Resolve conflict due to lack of 2b6ff7dea670]
    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]>