Linux 6.1.79

 
ALSA: hda/conexant: Add quirk for SWS JS201D [+ + +]
Author: bo liu <bo.liu@senarytech.com>
Date:   Mon Feb 5 09:38:02 2024 +0800

    ALSA: hda/conexant: Add quirk for SWS JS201D
    
    commit 4639c5021029d49fd2f97fa8d74731f167f98919 upstream.
    
    The SWS JS201D need a different pinconfig from windows driver.
    Add a quirk to use a specific pinconfig to SWS JS201D.
    
    Signed-off-by: bo liu <bo.liu@senarytech.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240205013802.51907-1-bo.liu@senarytech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/cs8409: Suppress vmaster control for Dolphin models [+ + +]
Author: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
Date:   Mon Jan 22 18:47:10 2024 +0000

    ALSA: hda/cs8409: Suppress vmaster control for Dolphin models
    
    commit a2ed0a44d637ef9deca595054c206da7d6cbdcbc upstream.
    
    Customer has reported an issue with specific desktop platform
    where two CS42L42 codecs are connected to CS8409 HDA bridge.
    If "Master Volume Control" is created then on Ubuntu OS UCM
    left/right balance slider in UI audio settings has no effect.
    This patch will fix this issue for a target paltform.
    
    Fixes: 20e507724113 ("ALSA: hda/cs8409: Add support for dolphin")
    Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240122184710.5802-1-vitalyr@opensource.cirrus.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Apply headset jack quirk for non-bass alc287 thinkpads [+ + +]
Author: José Relvas <josemonsantorelvas@gmail.com>
Date:   Wed Jan 31 11:34:09 2024 +0000

    ALSA: hda/realtek: Apply headset jack quirk for non-bass alc287 thinkpads
    
    commit 2468e8922d2f6da81a6192b73023eff67e3fefdd upstream.
    
    There currently exists two thinkpad headset jack fixups:
    ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK
    ALC285_FIXUP_THINKPAD_HEADSET_JACK
    
    The latter is applied to alc285 and alc287 thinkpads which contain
    bass speakers.
    However, the former was only being applied to alc285 thinkpads,
    leaving non-bass alc287 thinkpads with no headset button controls.
    This patch fixes that by adding ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK
    to the alc287 chains, allowing the detection of headset buttons.
    
    Signed-off-by: José Relvas <josemonsantorelvas@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240131113407.34698-3-josemonsantorelvas@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Enable headset mic on Vaio VJFE-ADL [+ + +]
Author: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Date:   Thu Feb 1 09:21:14 2024 -0300

    ALSA: hda/realtek: Enable headset mic on Vaio VJFE-ADL
    
    commit c7de2d9bb68a5fc71c25ff96705a80a76c8436eb upstream.
    
    Vaio VJFE-ADL is equipped with ALC269VC, and it needs
    ALC298_FIXUP_SPK_VOLUME quirk to make its headset mic work.
    
    Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240201122114.30080-1-edson.drosdeck@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Enable Mute LED on HP Laptop 14-fq0xxx [+ + +]
Author: Luka Guzenko <l.guzenko@web.de>
Date:   Sun Jan 28 16:57:04 2024 +0100

    ALSA: hda/realtek: Enable Mute LED on HP Laptop 14-fq0xxx
    
    commit f0d78972f27dc1d1d51fbace2713ad3cdc60a877 upstream.
    
    This HP Laptop uses ALC236 codec with COEF 0x07 controlling the
    mute LED. Enable existing quirk for this device.
    
    Signed-off-by: Luka Guzenko <l.guzenko@web.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240128155704.2333812-1-l.guzenko@web.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: fix mute/micmute LED For HP mt645 [+ + +]
Author: Eniac Zhang <eniac-xw.zhang@hp.com>
Date:   Thu Feb 15 15:49:22 2024 +0000

    ALSA: hda/realtek: fix mute/micmute LED For HP mt645
    
    commit 32f03f4002c5df837fb920eb23fcd2f4af9b0b23 upstream.
    
    The HP mt645 G7 Thin Client uses an ALC236 codec and needs the
    ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to make the mute and
    micmute LEDs work.
    
    There are two variants of the USB-C PD chip on this device. Each uses
    a different BIOS and board ID, hence the two entries.
    
    Signed-off-by: Eniac Zhang <eniac-xw.zhang@hp.com>
    Signed-off-by: Alexandru Gagniuc <alexandru.gagniuc@hp.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240215154922.778394-1-alexandru.gagniuc@hp.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: fix mute/micmute LEDs for HP ZBook Power [+ + +]
Author: Andy Chi <andy.chi@canonical.com>
Date:   Mon Jan 22 15:48:24 2024 +0800

    ALSA: hda/realtek: fix mute/micmute LEDs for HP ZBook Power
    
    commit 1513664f340289cf10402753110f3cff12a738aa upstream.
    
    The HP ZBook Power using ALC236 codec which using 0x02 to
    control mute LED and 0x01 to control micmute LED.
    Therefore, add a quirk to make it works.
    
    Signed-off-by: Andy Chi <andy.chi@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240122074826.1020964-1-andy.chi@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Fix the external mic not being recognised for Acer Swift 1 SF114-32 [+ + +]
Author: David Senoner <seda18@rolmail.net>
Date:   Fri Jan 26 16:56:26 2024 +0100

    ALSA: hda/realtek: Fix the external mic not being recognised for Acer Swift 1 SF114-32
    
    commit efb56d84dd9c3de3c99fc396abb57c6d330038b5 upstream.
    
    If you connect an external headset/microphone to the 3.5mm jack on the
    Acer Swift 1 SF114-32 it does not recognize the microphone. This fixes
    that and gives the user the ability to choose between internal and
    headset mic.
    
    Signed-off-by: David Senoner <seda18@rolmail.net>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240126155626.2304465-1-seda18@rolmail.net
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
apparmor: Free up __cleanup() name [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jun 9 09:48:59 2023 +0200

    apparmor: Free up __cleanup() name
    
    commit 9a1f37ebcfe061721564042254719dc8fd5c9fa0 upstream.
    
    In order to use __cleanup for __attribute__((__cleanup__(func))) the
    name must not be used for anything else. Avoid the conflict.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: John Johansen <john.johansen@canonical.com>
    Link: https://lkml.kernel.org/r/20230612093537.536441207%40infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arm64: dts: qcom: msm8916: Enable blsp_dma by default [+ + +]
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Sat Jan 7 12:09:57 2023 +0100

    arm64: dts: qcom: msm8916: Enable blsp_dma by default
    
    [ Upstream commit 0154d3594af3c198532ac7b4ab70f50fb5207a15 ]
    
    Adding the "dmas" to the I2C controllers prevents probing them if
    blsp_dma is disabled (infinite probe deferral). Avoid this by enabling
    blsp_dma by default - it's an integral part of the SoC that is almost
    always used (even if just for UART).
    
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230107110958.5762-2-stephan@gerhold.net
    Stable-dep-of: 7c45b6ddbcff ("arm64: dts: qcom: msm8916: Make blsp_dma controlled-remotely")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8916: Make blsp_dma controlled-remotely [+ + +]
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Mon Dec 4 11:21:20 2023 +0100

    arm64: dts: qcom: msm8916: Make blsp_dma controlled-remotely
    
    [ Upstream commit 7c45b6ddbcff01f9934d11802010cfeb0879e693 ]
    
    The blsp_dma controller is shared between the different subsystems,
    which is why it is already initialized by the firmware. We should not
    reinitialize it from Linux to avoid potential other users of the DMA
    engine to misbehave.
    
    In mainline this can be described using the "qcom,controlled-remotely"
    property. In the downstream/vendor kernel from Qualcomm there is an
    opposite "qcom,managed-locally" property. This property is *not* set
    for the qcom,sps-dma@7884000 [1] so adding "qcom,controlled-remotely"
    upstream matches the behavior of the downstream/vendor kernel.
    
    Adding this seems to fix some weird issues with UART where both
    input/output becomes garbled with certain obscure firmware versions on
    some devices.
    
    [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blob/LA.BR.1.2.9.1-02310-8x16.0/arch/arm/boot/dts/qcom/msm8916.dtsi#L1466-1472
    
    Cc: stable@vger.kernel.org # 6.5
    Fixes: a0e5fb103150 ("arm64: dts: qcom: Add msm8916 BLSP device nodes")
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Link: https://lore.kernel.org/r/20231204-msm8916-blsp-dma-remote-v1-1-3e49c8838c8d@gerhold.net
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm845: fix USB SS wakeup [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed Dec 13 18:34:01 2023 +0100

    arm64: dts: qcom: sdm845: fix USB SS wakeup
    
    [ Upstream commit 971f5d8b0618d09db75184ddd8cca0767514db5d ]
    
    The USB SS PHY interrupts need to be provided by the PDC interrupt
    controller in order to be able to wake the system up from low-power
    states.
    
    Fixes: ca4db2b538a1 ("arm64: dts: qcom: sdm845: Add USB-related nodes")
    Cc: stable@vger.kernel.org      # 4.20
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20231213173403.29544-4-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8150: fix USB SS wakeup [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed Dec 13 18:34:03 2023 +0100

    arm64: dts: qcom: sm8150: fix USB SS wakeup
    
    [ Upstream commit cc4e1da491b84ca05339a19893884cda78f74aef ]
    
    The USB SS PHY interrupts need to be provided by the PDC interrupt
    controller in order to be able to wake the system up from low-power
    states.
    
    Fixes: 0c9dde0d2015 ("arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes")
    Fixes: b33d2868e8d3 ("arm64: dts: qcom: sm8150: Add USB and PHY device nodes")
    Cc: stable@vger.kernel.org      # 5.10
    Cc: Jack Pham <quic_jackp@quicinc.com>
    Cc: Jonathan Marek <jonathan@marek.ca>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20231213173403.29544-6-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata [+ + +]
Author: Easwar Hariharan <eahariha@linux.microsoft.com>
Date:   Wed Feb 14 17:55:18 2024 +0000

    arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata
    
    commit fb091ff394792c018527b3211bbdfae93ea4ac02 upstream.
    
    Add the MIDR value of Microsoft Azure Cobalt 100, which is a Microsoft
    implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and therefore
    suffers from all the same errata.
    
    CC: stable@vger.kernel.org # 5.15+
    Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
    Link: https://lore.kernel.org/r/20240214175522.2457857-1-eahariha@linux.microsoft.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ARM: dts: imx6q-apalis: add can power-up delay on ixora board [+ + +]
Author: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Date:   Fri Oct 20 17:30:22 2023 +0200

    ARM: dts: imx6q-apalis: add can power-up delay on ixora board
    
    [ Upstream commit b76bbf835d8945080b22b52fc1e6f41cde06865d ]
    
    Newer variants of Ixora boards require a power-up delay when powering up
    the CAN transceiver of up to 1ms.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: amd: yc: Add DMI quirk for Lenovo Ideapad Pro 5 16ARP8 [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Mon Feb 5 15:48:53 2024 -0600

    ASoC: amd: yc: Add DMI quirk for Lenovo Ideapad Pro 5 16ARP8
    
    commit 610010737f74482a61896596a0116876ecf9e65c upstream.
    
    The laptop requires a quirk ID to enable its internal microphone. Add
    it to the DMI quirk table.
    
    Reported-by: Stanislav Petrov <stanislav.i.petrov@gmail.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=216925
    Cc: stable@vger.kernel.org
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20240205214853.2689-1-mario.limonciello@amd.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: amd: yc: Add DMI quirk for MSI Bravo 15 C7VF [+ + +]
Author: Techno Mooney <techno.mooney@gmail.com>
Date:   Mon Jan 29 15:11:47 2024 +0700

    ASoC: amd: yc: Add DMI quirk for MSI Bravo 15 C7VF
    
    commit c6dce23ec993f7da7790a9eadb36864ceb60e942 upstream.
    
    The laptop requires a quirk ID to enable its internal microphone. Add
    it to the DMI quirk table.
    
    Reported-by: Techno Mooney <techno.mooney@gmail.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218402
    Cc: stable@vger.kernel.org
    Signed-off-by: Techno Mooney <techno.mooney@gmail.com>
    Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Link: https://msgid.link/r/20240129081148.1044891-1-bagasdotme@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: codecs: wcd938x: handle deferred probe [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Jan 17 16:12:06 2024 +0100

    ASoC: codecs: wcd938x: handle deferred probe
    
    commit 086df711d9b886194481b4fbe525eb43e9ae7403 upstream.
    
    WCD938x sound codec driver ignores return status of getting regulators
    and returns EINVAL instead of EPROBE_DEFER.  If regulator provider
    probes after the codec, system is left without probed audio:
    
      wcd938x_codec audio-codec: wcd938x_probe: Fail to obtain platform data
      wcd938x_codec: probe of audio-codec failed with error -22
    
    Fixes: 16572522aece ("ASoC: codecs: wcd938x-sdw: add SoundWire driver")
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://msgid.link/r/20240117151208.1219755-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work() [+ + +]
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Sun Feb 11 12:58:34 2024 +0300

    ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work()
    
    [ Upstream commit 6ef5d5b92f7117b324efaac72b3db27ae8bb3082 ]
    
    There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex
    is left locked forever. That may lead to deadlock
    when rt5645_jack_detect_work() is called for the second time.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: cdba4301adda ("ASoC: rt5650: add mutex to avoid the jack detection failure")
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Link: https://lore.kernel.org/r/1707645514-21196-1-git-send-email-khoroshilov@ispras.ru
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
binder: signal epoll threads of self-work [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Wed Jan 31 21:53:46 2024 +0000

    binder: signal epoll threads of self-work
    
    commit 97830f3c3088638ff90b20dfba2eb4d487bf14d7 upstream.
    
    In (e)poll mode, threads often depend on I/O events to determine when
    data is ready for consumption. Within binder, a thread may initiate a
    command via BINDER_WRITE_READ without a read buffer and then make use
    of epoll_wait() or similar to consume any responses afterwards.
    
    It is then crucial that epoll threads are signaled via wakeup when they
    queue their own work. Otherwise, they risk waiting indefinitely for an
    event leaving their work unhandled. What is worse, subsequent commands
    won't trigger a wakeup either as the thread has pending work.
    
    Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
    Cc: Arve Hjønnevåg <arve@android.com>
    Cc: Martijn Coenen <maco@android.com>
    Cc: Alice Ryhl <aliceryhl@google.com>
    Cc: Steven Moreland <smoreland@google.com>
    Cc: stable@vger.kernel.org # v4.19+
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20240131215347.1808751-1-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
block: fix partial zone append completion handling in req_bio_endio() [+ + +]
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Wed Jan 10 18:29:42 2024 +0900

    block: fix partial zone append completion handling in req_bio_endio()
    
    [ Upstream commit 748dc0b65ec2b4b7b3dbd7befcc4a54fdcac7988 ]
    
    Partial completions of zone append request is not allowed but if a zone
    append completion indicates a number of completed bytes different from
    the original BIO size, only the BIO status is set to error. This leads
    to bio_advance() not setting the BIO size to 0 and thus to not call
    bio_endio() at the end of req_bio_endio().
    
    Make sure a partially completed zone append is failed and completed
    immediately by forcing the completed number of bytes (nbytes) to be
    equal to the BIO size, thus ensuring that bio_endio() is called.
    
    Fixes: 297db731847e ("block: fix req_bio_endio append error handling")
    Cc: stable@kernel.vger.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Link: https://lore.kernel.org/r/20240110092942.442334-1-dlemoal@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Add struct for bin_args arg in bpf_bprintf_prepare [+ + +]
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Thu Dec 15 22:44:28 2022 +0100

    bpf: Add struct for bin_args arg in bpf_bprintf_prepare
    
    commit 78aa1cc9404399a15d2a1205329c6a06236f5378 upstream.
    
    Adding struct bpf_bprintf_data to hold bin_args argument for
    bpf_bprintf_prepare function.
    
    We will add another return argument to bpf_bprintf_prepare and
    pass the struct to bpf_bprintf_cleanup for proper cleanup in
    following changes.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20221215214430.1336195-2-jolsa@kernel.org
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bpf: Do cleanup in bpf_bprintf_cleanup only when needed [+ + +]
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Thu Dec 15 22:44:29 2022 +0100

    bpf: Do cleanup in bpf_bprintf_cleanup only when needed
    
    commit f19a4050455aad847fb93f18dc1fe502eb60f989 upstream.
    
    Currently we always cleanup/decrement bpf_bprintf_nest_level variable
    in bpf_bprintf_cleanup if it's > 0.
    
    There's possible scenario where this could cause a problem, when
    bpf_bprintf_prepare does not get bin_args buffer (because num_args is 0)
    and following bpf_bprintf_cleanup call decrements bpf_bprintf_nest_level
    variable, like:
    
      in task context:
        bpf_bprintf_prepare(num_args != 0) increments 'bpf_bprintf_nest_level = 1'
        -> first irq :
           bpf_bprintf_prepare(num_args == 0)
           bpf_bprintf_cleanup decrements 'bpf_bprintf_nest_level = 0'
        -> second irq:
           bpf_bprintf_prepare(num_args != 0) bpf_bprintf_nest_level = 1
           gets same buffer as task context above
    
    Adding check to bpf_bprintf_cleanup and doing the real cleanup only if we
    got bin_args data in the first place.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20221215214430.1336195-3-jolsa@kernel.org
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bpf: Remove trace_printk_lock [+ + +]
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Thu Dec 15 22:44:30 2022 +0100

    bpf: Remove trace_printk_lock
    
    commit e2bb9e01d589f7fa82573aedd2765ff9b277816a upstream.
    
    Both bpf_trace_printk and bpf_trace_vprintk helpers use static buffer guarded
    with trace_printk_lock spin lock.
    
    The spin lock contention causes issues with bpf programs attached to
    contention_begin tracepoint [1][2].
    
    Andrii suggested we could get rid of the contention by using trylock, but we
    could actually get rid of the spinlock completely by using percpu buffers the
    same way as for bin_args in bpf_bprintf_prepare function.
    
    Adding new return 'buf' argument to struct bpf_bprintf_data and making
    bpf_bprintf_prepare to return also the buffer for printk helpers.
    
      [1] https://lore.kernel.org/bpf/CACkBjsakT_yWxnSWr4r-0TpPvbKm9-OBmVUhJb7hV3hY8fdCkw@mail.gmail.com/
      [2] https://lore.kernel.org/bpf/CACkBjsaCsTovQHFfkqJKto6S4Z8d02ud1D7MPESrHa1cVNNTrw@mail.gmail.com/
    
    Reported-by: Hao Sun <sunhao.th@gmail.com>
    Suggested-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20221215214430.1336195-4-jolsa@kernel.org
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
btrfs: add and use helper to check if block group is used [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jan 25 09:53:06 2024 +0000

    btrfs: add and use helper to check if block group is used
    
    commit 1693d5442c458ae8d5b0d58463b873cd879569ed upstream.
    
    Add a helper function to determine if a block group is being used and make
    use of it at btrfs_delete_unused_bgs(). This helper will also be used in
    future code changes.
    
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Boris Burkov <boris@bur.io>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: do not ASSERT() if the newly created subvolume already got read [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Sat Jan 20 19:41:28 2024 +1030

    btrfs: do not ASSERT() if the newly created subvolume already got read
    
    commit e03ee2fe873eb68c1f9ba5112fee70303ebf9dfb upstream.
    
    [BUG]
    There is a syzbot crash, triggered by the ASSERT() during subvolume
    creation:
    
     assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319
     ------------[ cut here ]------------
     kernel BUG at fs/btrfs/disk-io.c:1319!
     invalid opcode: 0000 [#1] PREEMPT SMP KASAN
     RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60
      <TASK>
      btrfs_get_new_fs_root+0xd3/0xf0
      create_subvol+0xd02/0x1650
      btrfs_mksubvol+0xe95/0x12b0
      __btrfs_ioctl_snap_create+0x2f9/0x4f0
      btrfs_ioctl_snap_create+0x16b/0x200
      btrfs_ioctl+0x35f0/0x5cf0
      __x64_sys_ioctl+0x19d/0x210
      do_syscall_64+0x3f/0xe0
      entry_SYSCALL_64_after_hwframe+0x63/0x6b
     ---[ end trace 0000000000000000 ]---
    
    [CAUSE]
    During create_subvol(), after inserting root item for the newly created
    subvolume, we would trigger btrfs_get_new_fs_root() to get the
    btrfs_root of that subvolume.
    
    The idea here is, we have preallocated an anonymous device number for
    the subvolume, thus we can assign it to the new subvolume.
    
    But there is really nothing preventing things like backref walk to read
    the new subvolume.
    If that happens before we call btrfs_get_new_fs_root(), the subvolume
    would be read out, with a new anonymous device number assigned already.
    
    In that case, we would trigger ASSERT(), as we really expect no one to
    read out that subvolume (which is not yet accessible from the fs).
    But things like backref walk is still possible to trigger the read on
    the subvolume.
    
    Thus our assumption on the ASSERT() is not correct in the first place.
    
    [FIX]
    Fix it by removing the ASSERT(), and just free the @anon_dev, reset it
    to 0, and continue.
    
    If the subvolume tree is read out by something else, it should have
    already get a new anon_dev assigned thus we only need to free the
    preallocated one.
    
    Reported-by: Chenyuan Yang <chenyuan0y@gmail.com>
    Fixes: 2dfb1e43f57d ("btrfs: preallocate anon block device at first phase of snapshot creation")
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: do not delete unused block group if it may be used soon [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jan 25 09:53:14 2024 +0000

    btrfs: do not delete unused block group if it may be used soon
    
    commit f4a9f219411f318ae60d6ff7f129082a75686c6c upstream.
    
    Before deleting a block group that is in the list of unused block groups
    (fs_info->unused_bgs), we check if the block group became used before
    deleting it, as extents from it may have been allocated after it was added
    to the list.
    
    However even if the block group was not yet used, there may be tasks that
    have only reserved space and have not yet allocated extents, and they
    might be relying on the availability of the unused block group in order
    to allocate extents. The reservation works first by increasing the
    "bytes_may_use" field of the corresponding space_info object (which may
    first require flushing delayed items, allocating a new block group, etc),
    and only later a task does the actual allocation of extents.
    
    For metadata we usually don't end up using all reserved space, as we are
    pessimistic and typically account for the worst cases (need to COW every
    single node in a path of a tree at maximum possible height, etc). For
    data we usually reserve the exact amount of space we're going to allocate
    later, except when using compression where we always reserve space based
    on the uncompressed size, as compression is only triggered when writeback
    starts so we don't know in advance how much space we'll actually need, or
    if the data is compressible.
    
    So don't delete an unused block group if the total size of its space_info
    object minus the block group's size is less then the sum of used space and
    space that may be used (space_info->bytes_may_use), as that means we have
    tasks that reserved space and may need to allocate extents from the block
    group. In this case, besides skipping the deletion, re-add the block group
    to the list of unused block groups so that it may be reconsidered later,
    in case the tasks that reserved space end up not needing to allocate
    extents from it.
    
    Allowing the deletion of the block group while we have reserved space, can
    result in tasks failing to allocate metadata extents (-ENOSPC) while under
    a transaction handle, resulting in a transaction abort, or failure during
    writeback for the case of data extents.
    
    CC: stable@vger.kernel.org # 6.0+
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Boris Burkov <boris@bur.io>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: don't drop extent_map for free space inode on write error [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Jan 31 14:27:25 2024 -0500

    btrfs: don't drop extent_map for free space inode on write error
    
    commit 5571e41ec6e56e35f34ae9f5b3a335ef510e0ade upstream.
    
    While running the CI for an unrelated change I hit the following panic
    with generic/648 on btrfs_holes_spacecache.
    
    assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
    ------------[ cut here ]------------
    kernel BUG at fs/btrfs/extent_io.c:1385!
    invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G        W          6.8.0-rc2+ #1
    RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
    Call Trace:
     <TASK>
     extent_write_cache_pages+0x2ac/0x8f0
     extent_writepages+0x87/0x110
     do_writepages+0xd5/0x1f0
     filemap_fdatawrite_wbc+0x63/0x90
     __filemap_fdatawrite_range+0x5c/0x80
     btrfs_fdatawrite_range+0x1f/0x50
     btrfs_write_out_cache+0x507/0x560
     btrfs_write_dirty_block_groups+0x32a/0x420
     commit_cowonly_roots+0x21b/0x290
     btrfs_commit_transaction+0x813/0x1360
     btrfs_sync_file+0x51a/0x640
     __x64_sys_fdatasync+0x52/0x90
     do_syscall_64+0x9c/0x190
     entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    This happens because we fail to write out the free space cache in one
    instance, come back around and attempt to write it again.  However on
    the second pass through we go to call btrfs_get_extent() on the inode to
    get the extent mapping.  Because this is a new block group, and with the
    free space inode we always search the commit root to avoid deadlocking
    with the tree, we find nothing and return a EXTENT_MAP_HOLE for the
    requested range.
    
    This happens because the first time we try to write the space cache out
    we hit an error, and on an error we drop the extent mapping.  This is
    normal for normal files, but the free space cache inode is special.  We
    always expect the extent map to be correct.  Thus the second time
    through we end up with a bogus extent map.
    
    Since we're deprecating this feature, the most straightforward way to
    fix this is to simply skip dropping the extent map range for this failed
    range.
    
    I shortened the test by using error injection to stress the area to make
    it easier to reproduce.  With this patch in place we no longer panic
    with my error injection test.
    
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: don't reserve space for checksums when writing to nocow files [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Jan 31 17:18:04 2024 +0000

    btrfs: don't reserve space for checksums when writing to nocow files
    
    commit feefe1f49d26bad9d8997096e3a200280fa7b1c5 upstream.
    
    Currently when doing a write to a file we always reserve metadata space
    for inserting data checksums. However we don't need to do it if we have
    a nodatacow file (-o nodatacow mount option or chattr +C) or if checksums
    are disabled (-o nodatasum mount option), as in that case we are only
    adding unnecessary pressure to metadata reservations.
    
    For example on x86_64, with the default node size of 16K, a 4K buffered
    write into a nodatacow file is reserving 655360 bytes of metadata space,
    as it's accounting for checksums. After this change, which stops reserving
    space for checksums if we have a nodatacow file or checksums are disabled,
    we only need to reserve 393216 bytes of metadata.
    
    CC: stable@vger.kernel.org # 6.1+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: forbid creating subvol qgroups [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Wed Jan 10 17:51:26 2024 -0800

    btrfs: forbid creating subvol qgroups
    
    commit 0c309d66dacddf8ce939b891d9ead4a8e21ad6f0 upstream.
    
    Creating a qgroup 0/subvolid leads to various races and it isn't
    helpful, because you can't specify a subvol id when creating a subvol,
    so you can't be sure it will be the right one. Any requirements on the
    automatic subvol can be gratified by using a higher level qgroup and the
    inheritance parameters of subvol creation.
    
    Fixes: cecbb533b5fc ("btrfs: record simple quota deltas in delayed refs")
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: forbid deleting live subvol qgroup [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Wed Jan 10 17:30:00 2024 -0800

    btrfs: forbid deleting live subvol qgroup
    
    commit a8df35619948bd8363d330c20a90c9a7fbff28c0 upstream.
    
    If a subvolume still exists, forbid deleting its qgroup 0/subvolid.
    This behavior generally leads to incorrect behavior in squotas and
    doesn't have a legitimate purpose.
    
    Fixes: cecbb533b5fc ("btrfs: record simple quota deltas in delayed refs")
    CC: stable@vger.kernel.org # 5.4+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: reject encoded write if inode has nodatasum flag set [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Feb 2 12:09:22 2024 +0000

    btrfs: reject encoded write if inode has nodatasum flag set
    
    commit 1bd96c92c6a0a4d43815eb685c15aa4b78879dc9 upstream.
    
    Currently we allow an encoded write against inodes that have the NODATASUM
    flag set, either because they are NOCOW files or they were created while
    the filesystem was mounted with "-o nodatasum". This results in having
    compressed extents without corresponding checksums, which is a filesystem
    inconsistency reported by 'btrfs check'.
    
    For example, running btrfs/281 with MOUNT_OPTIONS="-o nodatacow" triggers
    this and 'btrfs check' errors out with:
    
       [1/7] checking root items
       [2/7] checking extents
       [3/7] checking free space tree
       [4/7] checking fs roots
       root 256 inode 257 errors 1040, bad file extent, some csum missing
       root 256 inode 258 errors 1040, bad file extent, some csum missing
       ERROR: errors found in fs roots
       (...)
    
    So reject encoded writes if the target inode has NODATASUM set.
    
    CC: stable@vger.kernel.org # 6.1+
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: send: return EOPNOTSUPP on unknown flags [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Wed Jan 10 17:48:44 2024 +0100

    btrfs: send: return EOPNOTSUPP on unknown flags
    
    commit f884a9f9e59206a2d41f265e7e403f080d10b493 upstream.
    
    When some ioctl flags are checked we return EOPNOTSUPP, like for
    BTRFS_SCRUB_SUPPORTED_FLAGS, BTRFS_SUBVOL_CREATE_ARGS_MASK or fallocate
    modes. The EINVAL is supposed to be for a supported but invalid
    values or combination of options. Fix that when checking send flags so
    it's consistent with the rest.
    
    CC: stable@vger.kernel.org # 4.14+
    Link: https://lore.kernel.org/linux-btrfs/CAL3q7H5rryOLzp3EKq8RTbjMHMHeaJubfpsVLF6H4qJnKCUR1w@mail.gmail.com/
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bus: moxtet: Add spi device table [+ + +]
Author: Sjoerd Simons <sjoerd@collabora.com>
Date:   Tue Nov 28 22:35:05 2023 +0100

    bus: moxtet: Add spi device table
    
    [ Upstream commit aaafe88d5500ba18b33be72458439367ef878788 ]
    
    The moxtet module fails to auto-load on. Add a SPI id table to
    allow it to do so.
    
    Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
    Cc:  <stable@vger.kernel.org>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) [+ + +]
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Fri Oct 20 15:38:14 2023 +0200

    can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
    
    commit efe7cf828039aedb297c1f9920b638fffee6aabc upstream.
    
    Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)
    modifies jsk->filters while receiving packets.
    
    Following trace was seen on affected system:
     ==================================================================
     BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
     Read of size 4 at addr ffff888012144014 by task j1939/350
    
     CPU: 0 PID: 350 Comm: j1939 Tainted: G        W  OE      6.5.0-rc5 #1
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
     Call Trace:
      print_report+0xd3/0x620
      ? kasan_complete_mode_report_info+0x7d/0x200
      ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
      kasan_report+0xc2/0x100
      ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
      __asan_load4+0x84/0xb0
      j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
      j1939_sk_recv+0x20b/0x320 [can_j1939]
      ? __kasan_check_write+0x18/0x20
      ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
      ? j1939_simple_recv+0x69/0x280 [can_j1939]
      ? j1939_ac_recv+0x5e/0x310 [can_j1939]
      j1939_can_recv+0x43f/0x580 [can_j1939]
      ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
      ? raw_rcv+0x42/0x3c0 [can_raw]
      ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
      can_rcv_filter+0x11f/0x350 [can]
      can_receive+0x12f/0x190 [can]
      ? __pfx_can_rcv+0x10/0x10 [can]
      can_rcv+0xdd/0x130 [can]
      ? __pfx_can_rcv+0x10/0x10 [can]
      __netif_receive_skb_one_core+0x13d/0x150
      ? __pfx___netif_receive_skb_one_core+0x10/0x10
      ? __kasan_check_write+0x18/0x20
      ? _raw_spin_lock_irq+0x8c/0xe0
      __netif_receive_skb+0x23/0xb0
      process_backlog+0x107/0x260
      __napi_poll+0x69/0x310
      net_rx_action+0x2a1/0x580
      ? __pfx_net_rx_action+0x10/0x10
      ? __pfx__raw_spin_lock+0x10/0x10
      ? handle_irq_event+0x7d/0xa0
      __do_softirq+0xf3/0x3f8
      do_softirq+0x53/0x80
      </IRQ>
      <TASK>
      __local_bh_enable_ip+0x6e/0x70
      netif_rx+0x16b/0x180
      can_send+0x32b/0x520 [can]
      ? __pfx_can_send+0x10/0x10 [can]
      ? __check_object_size+0x299/0x410
      raw_sendmsg+0x572/0x6d0 [can_raw]
      ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
      ? apparmor_socket_sendmsg+0x2f/0x40
      ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
      sock_sendmsg+0xef/0x100
      sock_write_iter+0x162/0x220
      ? __pfx_sock_write_iter+0x10/0x10
      ? __rtnl_unlock+0x47/0x80
      ? security_file_permission+0x54/0x320
      vfs_write+0x6ba/0x750
      ? __pfx_vfs_write+0x10/0x10
      ? __fget_light+0x1ca/0x1f0
      ? __rcu_read_unlock+0x5b/0x280
      ksys_write+0x143/0x170
      ? __pfx_ksys_write+0x10/0x10
      ? __kasan_check_read+0x15/0x20
      ? fpregs_assert_state_consistent+0x62/0x70
      __x64_sys_write+0x47/0x60
      do_syscall_64+0x60/0x90
      ? do_syscall_64+0x6d/0x90
      ? irqentry_exit+0x3f/0x50
      ? exc_page_fault+0x79/0xf0
      entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    
     Allocated by task 348:
      kasan_save_stack+0x2a/0x50
      kasan_set_track+0x29/0x40
      kasan_save_alloc_info+0x1f/0x30
      __kasan_kmalloc+0xb5/0xc0
      __kmalloc_node_track_caller+0x67/0x160
      j1939_sk_setsockopt+0x284/0x450 [can_j1939]
      __sys_setsockopt+0x15c/0x2f0
      __x64_sys_setsockopt+0x6b/0x80
      do_syscall_64+0x60/0x90
      entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    
     Freed by task 349:
      kasan_save_stack+0x2a/0x50
      kasan_set_track+0x29/0x40
      kasan_save_free_info+0x2f/0x50
      __kasan_slab_free+0x12e/0x1c0
      __kmem_cache_free+0x1b9/0x380
      kfree+0x7a/0x120
      j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
      __sys_setsockopt+0x15c/0x2f0
      __x64_sys_setsockopt+0x6b/0x80
      do_syscall_64+0x60/0x90
      entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    
    Fixes: 9d71dd0c70099 ("can: add support of SAE J1939 protocol")
    Reported-by: Sili Luo <rootlab@huawei.com>
    Suggested-by: Sili Luo <rootlab@huawei.com>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/all/20231020133814.383996-1-o.rempel@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock [+ + +]
Author: Ziqi Zhao <astrajoan@yahoo.com>
Date:   Fri Jul 21 09:22:26 2023 -0700

    can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock
    
    commit 6cdedc18ba7b9dacc36466e27e3267d201948c8d upstream.
    
    The following 3 locks would race against each other, causing the
    deadlock situation in the Syzbot bug report:
    
    - j1939_socks_lock
    - active_session_list_lock
    - sk_session_queue_lock
    
    A reasonable fix is to change j1939_socks_lock to an rwlock, since in
    the rare situations where a write lock is required for the linked list
    that j1939_socks_lock is protecting, the code does not attempt to
    acquire any more locks. This would break the circular lock dependency,
    where, for example, the current thread already locks j1939_socks_lock
    and attempts to acquire sk_session_queue_lock, and at the same time,
    another thread attempts to acquire j1939_socks_lock while holding
    sk_session_queue_lock.
    
    NOTE: This patch along does not fix the unregister_netdevice bug
    reported by Syzbot; instead, it solves a deadlock situation to prepare
    for one or more further patches to actually fix the Syzbot bug, which
    appears to be a reference counting problem within the j1939 codebase.
    
    Reported-by: <syzbot+1591462f226d9cbf0564@syzkaller.appspotmail.com>
    Signed-off-by: Ziqi Zhao <astrajoan@yahoo.com>
    Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/all/20230721162226.8639-1-astrajoan@yahoo.com
    [mkl: remove unrelated newline change]
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: netlink: Fix TDCO calculation using the old data bittiming [+ + +]
Author: Maxime Jayat <maxime.jayat@mobile-devices.fr>
Date:   Mon Nov 6 19:01:58 2023 +0100

    can: netlink: Fix TDCO calculation using the old data bittiming
    
    commit 2aa0a5e65eae27dbd96faca92c84ecbf6f492d42 upstream.
    
    The TDCO calculation was done using the currently applied data bittiming,
    instead of the newly computed data bittiming, which means that the TDCO
    had an invalid value unless setting the same data bittiming twice.
    
    Fixes: d99755f71a80 ("can: netlink: add interface for CAN-FD Transmitter Delay Compensation (TDC)")
    Signed-off-by: Maxime Jayat <maxime.jayat@mobile-devices.fr>
    Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Link: https://lore.kernel.org/all/40579c18-63c0-43a4-8d4c-f3a6c1c0b417@munic.io
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ceph: prevent use-after-free in encode_cap_msg() [+ + +]
Author: Rishabh Dave <ridave@redhat.com>
Date:   Thu Feb 1 17:07:16 2024 +0530

    ceph: prevent use-after-free in encode_cap_msg()
    
    commit cda4672da1c26835dcbd7aec2bfed954eda9b5ef upstream.
    
    In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
    caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This
    implies before the refcount could be increment here, it was freed.
    
    In same file, in "handle_cap_grant()" refcount is decremented by this
    line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race
    occurred and resource was freed by the latter line before the former
    line could increment it.
    
    encode_cap_msg() is called by __send_cap() and __send_cap() is called by
    ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
    arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where
    the refcount must be increased to prevent "use after free" error.
    
    Cc: stable@vger.kernel.org
    Link: https://tracker.ceph.com/issues/59259
    Signed-off-by: Rishabh Dave <ridave@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cifs: fix underflow in parse_server_interfaces() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Feb 8 13:18:46 2024 +0300

    cifs: fix underflow in parse_server_interfaces()
    
    [ Upstream commit cffe487026be13eaf37ea28b783d9638ab147204 ]
    
    In this loop, we step through the buffer and after each item we check
    if the size_left is greater than the minimum size we need.  However,
    the problem is that "bytes_left" is type ssize_t while sizeof() is type
    size_t.  That means that because of type promotion, the comparison is
    done as an unsigned and if we have negative bytes left the loop
    continues instead of ending.
    
    Fixes: fe856be475f7 ("CIFS: parse and store info on iface queries")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked [+ + +]
Author: Kim Phillips <kim.phillips@amd.com>
Date:   Thu Jan 25 17:12:53 2024 -0600

    crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked
    
    commit ccb88e9549e7cfd8bcd511c538f437e20026e983 upstream.
    
    The SEV platform device can be shutdown with a null psp_master,
    e.g., using DEBUG_TEST_DRIVER_REMOVE.  Found using KASAN:
    
    [  137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002)
    [  137.162647] ccp 0000:23:00.1: no command queues available
    [  137.170598] ccp 0000:23:00.1: sev enabled
    [  137.174645] ccp 0000:23:00.1: psp enabled
    [  137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI
    [  137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7]
    [  137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311
    [  137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180
    [  137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c
    [  137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216
    [  137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e
    [  137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0
    [  137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66
    [  137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28
    [  137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8
    [  137.182693] FS:  0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000
    [  137.182693] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0
    [  137.182693] Call Trace:
    [  137.182693]  <TASK>
    [  137.182693]  ? show_regs+0x6c/0x80
    [  137.182693]  ? __die_body+0x24/0x70
    [  137.182693]  ? die_addr+0x4b/0x80
    [  137.182693]  ? exc_general_protection+0x126/0x230
    [  137.182693]  ? asm_exc_general_protection+0x2b/0x30
    [  137.182693]  ? __sev_platform_shutdown_locked+0x51/0x180
    [  137.182693]  sev_firmware_shutdown.isra.0+0x1e/0x80
    [  137.182693]  sev_dev_destroy+0x49/0x100
    [  137.182693]  psp_dev_destroy+0x47/0xb0
    [  137.182693]  sp_destroy+0xbb/0x240
    [  137.182693]  sp_pci_remove+0x45/0x60
    [  137.182693]  pci_device_remove+0xaa/0x1d0
    [  137.182693]  device_remove+0xc7/0x170
    [  137.182693]  really_probe+0x374/0xbe0
    [  137.182693]  ? srso_return_thunk+0x5/0x5f
    [  137.182693]  __driver_probe_device+0x199/0x460
    [  137.182693]  driver_probe_device+0x4e/0xd0
    [  137.182693]  __driver_attach+0x191/0x3d0
    [  137.182693]  ? __pfx___driver_attach+0x10/0x10
    [  137.182693]  bus_for_each_dev+0x100/0x190
    [  137.182693]  ? __pfx_bus_for_each_dev+0x10/0x10
    [  137.182693]  ? __kasan_check_read+0x15/0x20
    [  137.182693]  ? srso_return_thunk+0x5/0x5f
    [  137.182693]  ? _raw_spin_unlock+0x27/0x50
    [  137.182693]  driver_attach+0x41/0x60
    [  137.182693]  bus_add_driver+0x2a8/0x580
    [  137.182693]  driver_register+0x141/0x480
    [  137.182693]  __pci_register_driver+0x1d6/0x2a0
    [  137.182693]  ? srso_return_thunk+0x5/0x5f
    [  137.182693]  ? esrt_sysfs_init+0x1cd/0x5d0
    [  137.182693]  ? __pfx_sp_mod_init+0x10/0x10
    [  137.182693]  sp_pci_init+0x22/0x30
    [  137.182693]  sp_mod_init+0x14/0x30
    [  137.182693]  ? __pfx_sp_mod_init+0x10/0x10
    [  137.182693]  do_one_initcall+0xd1/0x470
    [  137.182693]  ? __pfx_do_one_initcall+0x10/0x10
    [  137.182693]  ? parameq+0x80/0xf0
    [  137.182693]  ? srso_return_thunk+0x5/0x5f
    [  137.182693]  ? __kmalloc+0x3b0/0x4e0
    [  137.182693]  ? kernel_init_freeable+0x92d/0x1050
    [  137.182693]  ? kasan_populate_vmalloc_pte+0x171/0x190
    [  137.182693]  ? srso_return_thunk+0x5/0x5f
    [  137.182693]  kernel_init_freeable+0xa64/0x1050
    [  137.182693]  ? __pfx_kernel_init+0x10/0x10
    [  137.182693]  kernel_init+0x24/0x160
    [  137.182693]  ? __switch_to_asm+0x3e/0x70
    [  137.182693]  ret_from_fork+0x40/0x80
    [  137.182693]  ? __pfx_kernel_init+0x10/0x10
    [  137.182693]  ret_from_fork_asm+0x1b/0x30
    [  137.182693]  </TASK>
    [  137.182693] Modules linked in:
    [  137.538483] ---[ end trace 0000000000000000 ]---
    
    Fixes: 1b05ece0c931 ("crypto: ccp - During shutdown, check SEV data pointer before using")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Kim Phillips <kim.phillips@amd.com>
    Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
    Acked-by: John Allen <john.allen@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init [+ + +]
Author: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Date:   Thu Dec 14 11:08:34 2023 +0800

    crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
    
    [ Upstream commit ba3c5574203034781ac4231acf117da917efcd2a ]
    
    When the mpi_ec_ctx structure is initialized, some fields are not
    cleared, causing a crash when referencing the field when the
    structure was released. Initially, this issue was ignored because
    memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
    For example, this error will be triggered when calculating the
    Za value for SM2 separately.
    
    Fixes: d58bb7e55a8a ("lib/mpi: Introduce ec implementation to MPI library")
    Cc: stable@vger.kernel.org # v6.5
    Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm-crypt, dm-verity: disable tasklets [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Jan 31 21:57:27 2024 +0100

    dm-crypt, dm-verity: disable tasklets
    
    commit 0a9bab391e336489169b95cb0d4553d921302189 upstream.
    
    Tasklets have an inherent problem with memory corruption. The function
    tasklet_action_common calls tasklet_trylock, then it calls the tasklet
    callback and then it calls tasklet_unlock. If the tasklet callback frees
    the structure that contains the tasklet or if it calls some code that may
    free it, tasklet_unlock will write into free memory.
    
    The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but
    it is not a sufficient fix and the data corruption can still happen [1].
    There is no fix for dm-verity and dm-verity will write into free memory
    with every tasklet-processed bio.
    
    There will be atomic workqueues implemented in the kernel 6.9 [2]. They
    will have better interface and they will not suffer from the memory
    corruption problem.
    
    But we need something that stops the memory corruption now and that can be
    backported to the stable kernels. So, I'm proposing this commit that
    disables tasklets in both dm-crypt and dm-verity. This commit doesn't
    remove the tasklet support, because the tasklet code will be reused when
    atomic workqueues will be implemented.
    
    [1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/
    [2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 39d42fa96ba1b ("dm crypt: add flags to optionally bypass kcryptd workqueues")
    Fixes: 5721d4e5a9cdb ("dm verity: Add optional "try_verify_in_tasklet" feature")
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm: limit the number of targets and parameter size area [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Jan 9 15:57:56 2024 +0100

    dm: limit the number of targets and parameter size area
    
    commit bd504bcfec41a503b32054da5472904b404341a4 upstream.
    
    The kvmalloc function fails with a warning if the size is larger than
    INT_MAX. The warning was triggered by a syscall testing robot.
    
    In order to avoid the warning, this commit limits the number of targets to
    1048576 and the size of the parameter area to 1073741824.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dmaengine: ioat: Free up __cleanup() name [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Sep 27 11:32:41 2022 +0200

    dmaengine: ioat: Free up __cleanup() name
    
    commit f62141ac730d6fe73a05750cb4482aabb681cfb9 upstream.
    
    In order to use __cleanup for __attribute__((__cleanup__(func))) the
    name must not be used for anything else. Avoid the conflict.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lkml.kernel.org/r/20230612093537.467120754%40infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
driver core: Fix device_link_flag_is_sync_state_only() [+ + +]
Author: Saravana Kannan <saravanak@google.com>
Date:   Fri Feb 2 01:56:33 2024 -0800

    driver core: Fix device_link_flag_is_sync_state_only()
    
    commit 7fddac12c38237252431d5b8af7b6d5771b6d125 upstream.
    
    device_link_flag_is_sync_state_only() correctly returns true on the flags
    of an existing device link that only implements sync_state() functionality.
    However, it incorrectly and confusingly returns false if it's called with
    DL_FLAG_SYNC_STATE_ONLY.
    
    This bug doesn't manifest in any of the existing calls to this function,
    but fix this confusing behavior to avoid future bugs.
    
    Fixes: 67cad5c67019 ("driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links")
    Signed-off-by: Saravana Kannan <saravanak@google.com>
    Tested-by: Xu Yang <xu.yang_2@nxp.com>
    Link: https://lore.kernel.org/r/20240202095636.868578-2-saravanak@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

driver core: fw_devlink: Improve detection of overlapping cycles [+ + +]
Author: Saravana Kannan <saravanak@google.com>
Date:   Fri Feb 2 01:56:34 2024 -0800

    driver core: fw_devlink: Improve detection of overlapping cycles
    
    [ Upstream commit 6442d79d880cf7a2fff18779265d657fef0cce4c ]
    
    fw_devlink can detect most overlapping/intersecting cycles. However it was
    missing a few corner cases because of an incorrect optimization logic that
    tries to avoid repeating cycle detection for devices that are already
    marked as part of a cycle.
    
    Here's an example provided by Xu Yang (edited for clarity):
    
                        usb
                      +-----+
       tcpc           |     |
      +-----+         |  +--|
      |     |----------->|EP|
      |--+  |         |  +--|
      |EP|<-----------|     |
      |--+  |         |  B  |
      |     |         +-----+
      |  A  |            |
      +-----+            |
         ^     +-----+   |
         |     |     |   |
         +-----|  C  |<--+
               |     |
               +-----+
               usb-phy
    
    Node A (tcpc) will be populated as device 1-0050.
    Node B (usb) will be populated as device 38100000.usb.
    Node C (usb-phy) will be populated as device 381f0040.usb-phy.
    
    The description below uses the notation:
    consumer --> supplier
    child ==> parent
    
    1. Node C is populated as device C. No cycles detected because cycle
       detection is only run when a fwnode link is converted to a device link.
    
    2. Node B is populated as device B. As we convert B --> C into a device
       link we run cycle detection and find and mark the device link/fwnode
       link cycle:
       C--> A --> B.EP ==> B --> C
    
    3. Node A is populated as device A. As we convert C --> A into a device
       link, we see it's already part of a cycle (from step 2) and don't run
       cycle detection. Thus we miss detecting the cycle:
       A --> B.EP ==> B --> A.EP ==> A
    
    Looking at it another way, A depends on B in one way:
    A --> B.EP ==> B
    
    But B depends on A in two ways and we only detect the first:
    B --> C --> A
    B --> A.EP ==> A
    
    To detect both of these, we remove the incorrect optimization attempt in
    step 3 and run cycle detection even if the fwnode link from which the
    device link is being created has already been marked as part of a cycle.
    
    Reported-by: Xu Yang <xu.yang_2@nxp.com>
    Closes: https://lore.kernel.org/lkml/DU2PR04MB8822693748725F85DC0CB86C8C792@DU2PR04MB8822.eurprd04.prod.outlook.com/
    Fixes: 3fb16866b51d ("driver core: fw_devlink: Make cycle detection more robust")
    Signed-off-by: Saravana Kannan <saravanak@google.com>
    Tested-by: Xu Yang <xu.yang_2@nxp.com>
    Link: https://lore.kernel.org/r/20240202095636.868578-3-saravanak@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Increase frame-larger-than for all display_mode_vba files [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon Feb 5 14:54:05 2024 -0700

    drm/amd/display: Increase frame-larger-than for all display_mode_vba files
    
    commit e63e35f0164c43fbc1adb481d6604f253b9f9667 upstream.
    
    After a recent change in LLVM, allmodconfig (which has CONFIG_KCSAN=y
    and CONFIG_WERROR=y enabled) has a few new instances of
    -Wframe-larger-than for the mode support and system configuration
    functions:
    
      drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20v2.c:3393:6: error: stack frame size (2144) exceeds limit (2048) in 'dml20v2_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
       3393 | void dml20v2_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
            |      ^
      1 error generated.
    
      drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:3520:6: error: stack frame size (2192) exceeds limit (2048) in 'dml21_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
       3520 | void dml21_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
            |      ^
      1 error generated.
    
      drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3286:6: error: stack frame size (2128) exceeds limit (2048) in 'dml20_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
       3286 | void dml20_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
            |      ^
      1 error generated.
    
    Without the sanitizers enabled, there are no warnings.
    
    This was the catalyst for commit 6740ec97bcdb ("drm/amd/display:
    Increase frame warning limit with KASAN or KCSAN in dml2") and that same
    change was made to dml in commit 5b750b22530f ("drm/amd/display:
    Increase frame warning limit with KASAN or KCSAN in dml") but the
    frame_warn_flag variable was not applied to all files. Do so now to
    clear up the warnings and make all these files consistent.
    
    Cc: stable@vger.kernel.org
    Closes: https://github.com/ClangBuiltLinux/linux/issue/1990
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Preserve original aspect ratio in create stream [+ + +]
Author: Tom Chung <chiahsuan.chung@amd.com>
Date:   Tue Jan 30 15:34:08 2024 +0800

    drm/amd/display: Preserve original aspect ratio in create stream
    
    commit deb110292180cd501f6fde2a0178d65fcbcabb0c upstream.
    
    [Why]
    The original picture aspect ratio in mode struct may have chance be
    overwritten with wrong aspect ratio data in create_stream_for_sink().
    It will create a different VIC output and cause HDMI compliance test
    failed.
    
    [How]
    Preserve the original picture aspect ratio data during create the
    stream.
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/msm: Wire up tlb ops [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Tue Feb 13 09:23:40 2024 -0800

    drm/msm: Wire up tlb ops
    
    commit 8c7bfd8262319fd3f127a5380f593ea76f1b88a2 upstream.
    
    The brute force iommu_flush_iotlb_all() was good enough for unmap, but
    in some cases a map operation could require removing a table pte entry
    to replace with a block entry.  This also requires tlb invalidation.
    Missing this was resulting an obscure iova fault on what should be a
    valid buffer address.
    
    Thanks to Robin Murphy for helping me understand the cause of the fault.
    
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: stable@vger.kernel.org
    Fixes: b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Patchwork: https://patchwork.freedesktop.org/patch/578117/
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/prime: Support page array >= 4GB [+ + +]
Author: Philip Yang <Philip.Yang@amd.com>
Date:   Mon Aug 21 16:02:01 2023 -0400

    drm/prime: Support page array >= 4GB
    
    commit b671cd3d456315f63171a670769356a196cf7fd0 upstream.
    
    Without unsigned long typecast, the size is passed in as zero if page
    array size >= 4GB, nr_pages >= 0x100000, then sg list converted will
    have the first and the last chunk lost.
    
    Signed-off-by: Philip Yang <Philip.Yang@amd.com>
    Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230821200201.24685-1-Philip.Yang@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/virtio: Set segment size for virtio_gpu device [+ + +]
Author: Sebastian Ott <sebott@redhat.com>
Date:   Tue Jan 23 19:14:14 2024 +0100

    drm/virtio: Set segment size for virtio_gpu device
    
    commit 9c64e749cebd9c2d3d55261530a98bcccb83b950 upstream.
    
    Set the segment size of the virtio_gpu device to the value
    used by the drm helpers when allocating sg lists to fix the
    following complaint from DMA_API debug code:
    
    DMA-API: virtio-pci 0000:07:00.0: mapping sg segment longer than
    device claims to support [len=262144] [max=65536]
    
    Cc: stable@vger.kernel.org
    Tested-by: Zhenyu Zhang <zhenyzha@redhat.com>
    Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
    Signed-off-by: Sebastian Ott <sebott@redhat.com>
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/7258a4cc-da16-5c34-a042-2a23ee396d56@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ext4: avoid bb_free and bb_fragments inconsistency in mb_free_blocks() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:36 2024 +0800

    ext4: avoid bb_free and bb_fragments inconsistency in mb_free_blocks()
    
    commit 2331fd4a49864e1571b4f50aa3aa1536ed6220d0 upstream.
    
    After updating bb_free in mb_free_blocks, it is possible to return without
    updating bb_fragments because the block being freed is found to have
    already been freed, which leads to inconsistency between bb_free and
    bb_fragments.
    
    Since the group may be unlocked in ext4_grp_locked_error(), this can lead
    to problems such as dividing by zero when calculating the average fragment
    length. Hence move the update of bb_free to after the block double-free
    check guarantees that the corresponding statistics are updated only after
    the core block bitmap is modified.
    
    Fixes: eabe0444df90 ("ext4: speed-up releasing blocks on commit")
    CC:  <stable@vger.kernel.org> # 3.10
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-5-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix double-free of blocks due to wrong extents moved_len [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:33 2024 +0800

    ext4: fix double-free of blocks due to wrong extents moved_len
    
    commit 55583e899a5357308274601364741a83e78d6ac4 upstream.
    
    In ext4_move_extents(), moved_len is only updated when all moves are
    successfully executed, and only discards orig_inode and donor_inode
    preallocations when moved_len is not zero. When the loop fails to exit
    after successfully moving some extents, moved_len is not updated and
    remains at 0, so it does not discard the preallocations.
    
    If the moved extents overlap with the preallocated extents, the
    overlapped extents are freed twice in ext4_mb_release_inode_pa() and
    ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:
    Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is
    incremented twice. Hence when trim is executed, a zero-division bug is
    triggered in mb_update_avg_fragment_size() because bb_free is not zero
    and bb_fragments is zero.
    
    Therefore, update move_len after each extent move to avoid the issue.
    
    Reported-by: Wei Chen <harperchen1110@gmail.com>
    Reported-by: xingwei lee <xrivendell7@gmail.com>
    Closes: https://lore.kernel.org/r/CAO4mrferzqBUnCag8R3m2zf897ts9UEuhjFQGPtODT92rYyR2Q@mail.gmail.com
    Fixes: fcf6b1b729bc ("ext4: refactor ext4_move_extents code base")
    CC:  <stable@vger.kernel.org> # 3.18
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-2-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
firewire: core: correct documentation of fw_csr_string() kernel API [+ + +]
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Thu Feb 1 20:53:18 2024 +0900

    firewire: core: correct documentation of fw_csr_string() kernel API
    
    commit 5f9ab17394f831cb7986ec50900fa37507a127f1 upstream.
    
    Against its current description, the kernel API can accepts all types of
    directory entries.
    
    This commit corrects the documentation.
    
    Cc: stable@vger.kernel.org
    Fixes: 3c2c58cb33b3 ("firewire: core: fw_csr_string addendum")
    Link: https://lore.kernel.org/r/20240130100409.30128-2-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super [+ + +]
Author: Oscar Salvador <osalvador@suse.de>
Date:   Tue Jan 30 22:04:18 2024 +0100

    fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
    
    commit 79d72c68c58784a3e1cd2378669d51bfd0cb7498 upstream.
    
    When configuring a hugetlb filesystem via the fsconfig() syscall, there is
    a possible NULL dereference in hugetlbfs_fill_super() caused by assigning
    NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize
    is non valid.
    
    E.g: Taking the following steps:
    
         fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);
         fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);
         fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
    
    Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced
    with NULL, losing its previous value, and we will print an error:
    
     ...
     ...
     case Opt_pagesize:
     ps = memparse(param->string, &rest);
     ctx->hstate = h;
     if (!ctx->hstate) {
             pr_err("Unsupported page size %lu MB\n", ps / SZ_1M);
             return -EINVAL;
     }
     return 0;
     ...
     ...
    
    This is a problem because later on, we will dereference ctxt->hstate in
    hugetlbfs_fill_super()
    
     ...
     ...
     sb->s_blocksize = huge_page_size(ctx->hstate);
     ...
     ...
    
    Causing below Oops.
    
    Fix this by replacing cxt->hstate value only when then pagesize is known
    to be valid.
    
     kernel: hugetlbfs: Unsupported page size 0 MB
     kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028
     kernel: #PF: supervisor read access in kernel mode
     kernel: #PF: error_code(0x0000) - not-present page
     kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0
     kernel: Oops: 0000 [#1] PREEMPT SMP PTI
     kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G            E      6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f
     kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017
     kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0
     kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28
     kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246
     kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004
     kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000
     kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004
     kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000
     kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400
     kernel: FS:  00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000
     kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0
     kernel: Call Trace:
     kernel:  <TASK>
     kernel:  ? __die_body+0x1a/0x60
     kernel:  ? page_fault_oops+0x16f/0x4a0
     kernel:  ? search_bpf_extables+0x65/0x70
     kernel:  ? fixup_exception+0x22/0x310
     kernel:  ? exc_page_fault+0x69/0x150
     kernel:  ? asm_exc_page_fault+0x22/0x30
     kernel:  ? __pfx_hugetlbfs_fill_super+0x10/0x10
     kernel:  ? hugetlbfs_fill_super+0xb4/0x1a0
     kernel:  ? hugetlbfs_fill_super+0x28/0x1a0
     kernel:  ? __pfx_hugetlbfs_fill_super+0x10/0x10
     kernel:  vfs_get_super+0x40/0xa0
     kernel:  ? __pfx_bpf_lsm_capable+0x10/0x10
     kernel:  vfs_get_tree+0x25/0xd0
     kernel:  vfs_cmd_create+0x64/0xe0
     kernel:  __x64_sys_fsconfig+0x395/0x410
     kernel:  do_syscall_64+0x80/0x160
     kernel:  ? syscall_exit_to_user_mode+0x82/0x240
     kernel:  ? do_syscall_64+0x8d/0x160
     kernel:  ? syscall_exit_to_user_mode+0x82/0x240
     kernel:  ? do_syscall_64+0x8d/0x160
     kernel:  ? exc_page_fault+0x69/0x150
     kernel:  entry_SYSCALL_64_after_hwframe+0x6e/0x76
     kernel: RIP: 0033:0x7ffbc0cb87c9
     kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48
     kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af
     kernel: RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffbc0cb87c9
     kernel: RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003
     kernel: RBP: 00007ffc29d2f3b0 R08: 0000000000000000 R09: 0000000000000000
     kernel: R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
     kernel: R13: 00007ffc29d2f4c0 R14: 0000000000000000 R15: 0000000000000000
     kernel:  </TASK>
     kernel: Modules linked in: rpcsec_gss_krb5(E) auth_rpcgss(E) nfsv4(E) dns_resolver(E) nfs(E) lockd(E) grace(E) sunrpc(E) netfs(E) af_packet(E) bridge(E) stp(E) llc(E) iscsi_ibft(E) iscsi_boot_sysfs(E) intel_rapl_msr(E) intel_rapl_common(E) iTCO_wdt(E) intel_pmc_bxt(E) sb_edac(E) iTCO_vendor_support(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) rfkill(E) ipmi_ssif(E) kvm(E) acpi_ipmi(E) irqbypass(E) pcspkr(E) igb(E) ipmi_si(E) mei_me(E) i2c_i801(E) joydev(E) intel_pch_thermal(E) i2c_smbus(E) dca(E) lpc_ich(E) mei(E) ipmi_devintf(E) ipmi_msghandler(E) acpi_pad(E) tiny_power_button(E) button(E) fuse(E) efi_pstore(E) configfs(E) ip_tables(E) x_tables(E) ext4(E) mbcache(E) jbd2(E) hid_generic(E) usbhid(E) sd_mod(E) t10_pi(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) polyval_clmulni(E) ahci(E) xhci_pci(E) polyval_generic(E) gf128mul(E) ghash_clmulni_intel(E) sha512_ssse3(E) sha256_ssse3(E) xhci_pci_renesas(E) libahci(E) ehci_pci(E) sha1_ssse3(E) xhci_hcd(E) ehci_hcd(E) libata(E)
     kernel:  mgag200(E) i2c_algo_bit(E) usbcore(E) wmi(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E) scsi_common(E) aesni_intel(E) crypto_simd(E) cryptd(E)
     kernel: Unloaded tainted modules: acpi_cpufreq(E):1 fjes(E):1
     kernel: CR2: 0000000000000028
     kernel: ---[ end trace 0000000000000000 ]---
     kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0
     kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28
     kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246
     kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004
     kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000
     kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004
     kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000
     kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400
     kernel: FS:  00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000
     kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0
    
    Link: https://lkml.kernel.org/r/20240130210418.3771-1-osalvador@suse.de
    Fixes: 32021982a324 ("hugetlbfs: Convert to fs_context")
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Signed-off-by: Oscar Salvador <osalvador@suse.de>
    Acked-by: Muchun Song <muchun.song@linux.dev>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fs/ntfs3: Add null pointer checks [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Thu Dec 29 15:44:43 2022 +0400

    fs/ntfs3: Add null pointer checks
    
    commit fc4992458e0aa2d2e82a25c922e6ac36c2d91083 upstream.
    
    Added null pointer checks in function ntfs_security_init.
    Also added le32_to_cpu in functions ntfs_security_init and indx_read.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Cc: "Doebel, Bjoern" <doebel@amazon.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fs/proc: do_task_stat: move thread_group_cputime_adjusted() outside of lock_task_sighand() [+ + +]
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Jan 23 16:33:55 2024 +0100

    fs/proc: do_task_stat: move thread_group_cputime_adjusted() outside of lock_task_sighand()
    
    commit 60f92acb60a989b14e4b744501a0df0f82ef30a3 upstream.
    
    Patch series "fs/proc: do_task_stat: use sig->stats_".
    
    do_task_stat() has the same problem as getrusage() had before "getrusage:
    use sig->stats_lock rather than lock_task_sighand()": a hard lockup.  If
    NR_CPUS threads call lock_task_sighand() at the same time and the process
    has NR_THREADS, spin_lock_irq will spin with irqs disabled O(NR_CPUS *
    NR_THREADS) time.
    
    
    This patch (of 3):
    
    thread_group_cputime() does its own locking, we can safely shift
    thread_group_cputime_adjusted() which does another for_each_thread loop
    outside of ->siglock protected section.
    
    Not only this removes for_each_thread() from the critical section with
    irqs disabled, this removes another case when stats_lock is taken with
    siglock held.  We want to remove this dependency, then we can change the
    users of stats_lock to not disable irqs.
    
    Link: https://lkml.kernel.org/r/20240123153313.GA21832@redhat.com
    Link: https://lkml.kernel.org/r/20240123153355.GA21854@redhat.com
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Dylan Hatch <dylanbhatch@google.com>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fs: relax mount_setattr() permission checks [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Tue Feb 6 11:22:09 2024 +0100

    fs: relax mount_setattr() permission checks
    
    commit 46f5ab762d048dad224436978315cbc2fa79c630 upstream.
    
    When we added mount_setattr() I added additional checks compared to the
    legacy do_reconfigure_mnt() and do_change_type() helpers used by regular
    mount(2). If that mount had a parent then verify that the caller and the
    mount namespace the mount is attached to match and if not make sure that
    it's an anonymous mount.
    
    The real rootfs falls into neither category. It is neither an anoymous
    mount because it is obviously attached to the initial mount namespace
    but it also obviously doesn't have a parent mount. So that means legacy
    mount(2) allows changing mount properties on the real rootfs but
    mount_setattr(2) blocks this. I never thought much about this but of
    course someone on this planet of earth changes properties on the real
    rootfs as can be seen in [1].
    
    Since util-linux finally switched to the new mount api in 2.39 not so
    long ago it also relies on mount_setattr() and that surfaced this issue
    when Fedora 39 finally switched to it. Fix this.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2256843
    Link: https://lore.kernel.org/r/20240206-vfs-mount-rootfs-v1-1-19b335eee133@kernel.org
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reported-by: Karel Zak <kzak@redhat.com>
    Cc: stable@vger.kernel.org # v5.12+
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
HID: i2c-hid-of: fix NULL-deref on failed power up [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Jan 26 18:09:01 2024 +0100

    HID: i2c-hid-of: fix NULL-deref on failed power up
    
    commit 00aab7dcb2267f2aef59447602f34501efe1a07f upstream.
    
    A while back the I2C HID implementation was split in an ACPI and OF
    part, but the new OF driver never initialises the client pointer which
    is dereferenced on power-up failures.
    
    Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules")
    Cc: stable@vger.kernel.org      # 5.12
    Cc: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: wacom: Do not register input devices until after hid_hw_start [+ + +]
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Mon Jan 29 14:35:45 2024 -0800

    HID: wacom: Do not register input devices until after hid_hw_start
    
    commit c1d6708bf0d3dd976460d435373cf5abf21ce258 upstream.
    
    If a input device is opened before hid_hw_start is called, events may
    not be received from the hardware. In the case of USB-backed devices,
    for example, the hid_hw_start function is responsible for filling in
    the URB which is submitted when the input device is opened. If a device
    is opened prematurely, polling will never start because the device will
    not have been in the correct state to send the URB.
    
    Because the wacom driver registers its input devices before calling
    hid_hw_start, there is a window of time where a device can be opened
    and end up in an inoperable state. Some ARM-based Chromebooks in particular
    reliably trigger this bug.
    
    This commit splits the wacom_register_inputs function into two pieces.
    One which is responsible for setting up the allocated inputs (and runs
    prior to hid_hw_start so that devices are ready for any input events
    they may end up receiving) and another which only registers the devices
    (and runs after hid_hw_start to ensure devices can be immediately opened
    without issue). Note that the functions to initialize the LEDs and remotes
    are also moved after hid_hw_start to maintain their own dependency chains.
    
    Fixes: 7704ac937345 ("HID: wacom: implement generic HID handling for pen generic devices")
    Cc: stable@vger.kernel.org # v3.18+
    Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Tested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: wacom: generic: Avoid reporting a serial of '0' to userspace [+ + +]
Author: Tatsunosuke Tobita <tatsunosuke.tobita@wacom.com>
Date:   Thu Feb 1 13:40:55 2024 +0900

    HID: wacom: generic: Avoid reporting a serial of '0' to userspace
    
    commit ab41a31dd5e2681803642b6d08590b61867840ec upstream.
    
    The xf86-input-wacom driver does not treat '0' as a valid serial
    number and will drop any input report which contains an
    MSC_SERIAL = 0 event. The kernel driver already takes care to
    avoid sending any MSC_SERIAL event if the value of serial[0] == 0
    (which is the case for devices that don't actually report a
    serial number), but this is not quite sufficient.
    Only the lower 32 bits of the serial get reported to userspace,
    so if this portion of the serial is zero then there can still
    be problems.
    
    This commit allows the driver to report either the lower 32 bits
    if they are non-zero or the upper 32 bits otherwise.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Signed-off-by: Tatsunosuke Tobita <tatsunosuke.tobita@wacom.com>
    Fixes: f85c9dc678a5 ("HID: wacom: generic: Support tool ID and additional tool types")
    CC: stable@vger.kernel.org # v4.10
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hrtimer: Ignore slack time for RT tasks in schedule_hrtimeout_range() [+ + +]
Author: Davidlohr Bueso <dave@stgolabs.net>
Date:   Mon Jan 23 09:32:06 2023 -0800

    hrtimer: Ignore slack time for RT tasks in schedule_hrtimeout_range()
    
    commit 0c52310f260014d95c1310364379772cb74cf82d upstream.
    
    While in theory the timer can be triggered before expires + delta, for the
    cases of RT tasks they really have no business giving any lenience for
    extra slack time, so override any passed value by the user and always use
    zero for schedule_hrtimeout_range() calls. Furthermore, this is similar to
    what the nanosleep(2) family already does with current->timer_slack_ns.
    
    Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20230123173206.6764-3-dave@stgolabs.net
    Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove [+ + +]
Author: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
Date:   Tue Jan 30 23:35:51 2024 -0800

    hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
    
    commit e0526ec5360a48ad3ab2e26e802b0532302a7e11 upstream.
    
    In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the
    VMBus channel"), napi_disable was getting called for all channels,
    including all subchannels without confirming if they are enabled or not.
    
    This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
    has finished running but nvdev->subchan_work has not started yet.
    netvsc_subchan_work() -> rndis_set_subchannel() has not created the
    sub-channels and because of that netvsc_sc_open() is not running.
    netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which
    netvsc_subchan_work did not run.
    
    netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
    cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the
    NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
    opposite.
    
    Now during netvsc_device_remove(), when napi_disable is called for those
    subchannels, napi_disable gets stuck on infinite msleep.
    
    This fix addresses this problem by ensuring that napi_disable() is not
    getting called for non-enabled NAPI struct.
    But netif_napi_del() is still necessary for these non-enabled NAPI struct
    for cleanup purpose.
    
    Call trace:
    [  654.559417] task:modprobe        state:D stack:    0 pid: 2321 ppid:  1091 flags:0x00004002
    [  654.568030] Call Trace:
    [  654.571221]  <TASK>
    [  654.573790]  __schedule+0x2d6/0x960
    [  654.577733]  schedule+0x69/0xf0
    [  654.581214]  schedule_timeout+0x87/0x140
    [  654.585463]  ? __bpf_trace_tick_stop+0x20/0x20
    [  654.590291]  msleep+0x2d/0x40
    [  654.593625]  napi_disable+0x2b/0x80
    [  654.597437]  netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
    [  654.603935]  rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
    [  654.611101]  ? do_wait_intr+0xb0/0xb0
    [  654.615753]  netvsc_remove+0x7c/0x120 [hv_netvsc]
    [  654.621675]  vmbus_remove+0x27/0x40 [hv_vmbus]
    
    Cc: stable@vger.kernel.org
    Fixes: ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel")
    Signed-off-by: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/1706686551-28510-1-git-send-email-schakrabarti@linux.microsoft.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed [+ + +]
Author: Shradha Gupta <shradhagupta@linux.microsoft.com>
Date:   Thu Feb 1 20:40:38 2024 -0800

    hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed
    
    commit 9cae43da9867412f8bd09aee5c8a8dc5e8dc3dc2 upstream.
    
    If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER
    handler cannot perform VF register successfully as the register call
    is received before netvsc_probe is finished. This is because we
    register register_netdevice_notifier() very early( even before
    vmbus_driver_register()).
    To fix this, we try to register each such matching VF( if it is visible
    as a netdevice) at the end of netvsc_probe.
    
    Cc: stable@vger.kernel.org
    Fixes: 85520856466e ("hv_netvsc: Fix race of register_netdevice_notifier and VF register")
    Suggested-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
    Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i2c: i801: Fix block process call transactions [+ + +]
Author: Jean Delvare <jdelvare@suse.de>
Date:   Wed Feb 14 15:59:39 2024 +0100

    i2c: i801: Fix block process call transactions
    
    [ Upstream commit c1c9d0f6f7f1dbf29db996bd8e166242843a5f21 ]
    
    According to the Intel datasheets, software must reset the block
    buffer index twice for block process call transactions: once before
    writing the outgoing data to the buffer, and once again before
    reading the incoming data from the buffer.
    
    The driver is currently missing the second reset, causing the wrong
    portion of the block buffer to be read.
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Reported-by: Piotr Zakowski <piotr.zakowski@intel.com>
    Closes: https://lore.kernel.org/linux-i2c/20240213120553.7b0ab120@endymion.delvare/
    Fixes: 315cd67c9453 ("i2c: i801: Add Block Write-Block Read Process Call support")
    Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: pasemi: split driver into two separate modules [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Feb 12 12:19:04 2024 +0100

    i2c: pasemi: split driver into two separate modules
    
    [ Upstream commit f44bff19268517ee98e80e944cad0f04f1db72e3 ]
    
    On powerpc, it is possible to compile test both the new apple (arm) and
    old pasemi (powerpc) drivers for the i2c hardware at the same time,
    which leads to a warning about linking the same object file twice:
    
    scripts/Makefile.build:244: drivers/i2c/busses/Makefile: i2c-pasemi-core.o is added to multiple modules: i2c-apple i2c-pasemi
    
    Rework the driver to have an explicit helper module, letting Kbuild
    take care of whether this should be built-in or a loadable driver.
    
    Fixes: 9bc5f4f660ff ("i2c: pasemi: Split pci driver to its own file")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Sven Peter <sven@svenpeter.dev>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: qcom-geni: Correct I2C TRE sequence [+ + +]
Author: Viken Dadhaniya <quic_vdadhani@quicinc.com>
Date:   Mon Feb 12 18:22:39 2024 +0530

    i2c: qcom-geni: Correct I2C TRE sequence
    
    [ Upstream commit 83ef106fa732aea8558253641cd98e8a895604d7 ]
    
    For i2c read operation in GSI mode, we are getting timeout
    due to malformed TRE basically incorrect TRE sequence
    in gpi(drivers/dma/qcom/gpi.c) driver.
    
    I2C driver has geni_i2c_gpi(I2C_WRITE) function which generates GO TRE and
    geni_i2c_gpi(I2C_READ)generates DMA TRE. Hence to generate GO TRE before
    DMA TRE, we should move geni_i2c_gpi(I2C_WRITE) before
    geni_i2c_gpi(I2C_READ) inside the I2C GSI mode transfer function
    i.e. geni_i2c_gpi_xfer().
    
    TRE stands for Transfer Ring Element - which is basically an element with
    size of 4 words. It contains all information like slave address,
    clk divider, dma address value data size etc).
    
    Mainly we have 3 TREs(Config, GO and DMA tre).
    - CONFIG TRE : consists of internal register configuration which is
                   required before start of the transfer.
    - DMA TRE :    contains DDR/Memory address, called as DMA descriptor.
    - GO TRE :     contains Transfer directions, slave ID, Delay flags, Length
                   of the transfer.
    
    I2c driver calls GPI driver API to config each TRE depending on the
    protocol.
    
    For read operation tre sequence will be as below which is not aligned
    to hardware programming guide.
    
    - CONFIG tre
    - DMA tre
    - GO tre
    
    As per Qualcomm's internal Hardware Programming Guide, we should configure
    TREs in below sequence for any RX only transfer.
    
    - CONFIG tre
    - GO tre
    - DMA tre
    
    Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA")
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # qrb5165-rb5
    Co-developed-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
    Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
    Signed-off-by: Viken Dadhaniya <quic_vdadhani@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: Do not allow untrusted VF to remove administratively set MAC [+ + +]
Author: Ivan Vecera <ivecera@redhat.com>
Date:   Thu Feb 8 10:03:33 2024 -0800

    i40e: Do not allow untrusted VF to remove administratively set MAC
    
    [ Upstream commit 73d9629e1c8c1982f13688c4d1019c3994647ccc ]
    
    Currently when PF administratively sets VF's MAC address and the VF
    is put down (VF tries to delete all MACs) then the MAC is removed
    from MAC filters and primary VF MAC is zeroed.
    
    Do not allow untrusted VF to remove primary MAC when it was set
    administratively by PF.
    
    Reproducer:
    1) Create VF
    2) Set VF interface up
    3) Administratively set the VF's MAC
    4) Put VF interface down
    
    [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
    [root@host ~]# ip link set enp2s0f0v0 up
    [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d
    [root@host ~]# ip link show enp2s0f0
    23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
        vf 0     link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
    [root@host ~]# ip link set enp2s0f0v0 down
    [root@host ~]# ip link show enp2s0f0
    23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
        vf 0     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
    
    Fixes: 700bbf6c1f9e ("i40e: allow VF to remove any MAC filter")
    Fixes: ceb29474bbbc ("i40e: Add support for VF to specify its primary MAC address")
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://lore.kernel.org/r/20240208180335.1844996-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i40e: Fix waiting for queues of all VSIs to be disabled [+ + +]
Author: Ivan Vecera <ivecera@redhat.com>
Date:   Wed Nov 8 17:01:03 2023 +0100

    i40e: Fix waiting for queues of all VSIs to be disabled
    
    [ Upstream commit c73729b64bb692186da080602cd13612783f52ac ]
    
    The function i40e_pf_wait_queues_disabled() iterates all PF's VSIs
    up to 'pf->hw.func_caps.num_vsis' but this is incorrect because
    the real number of VSIs can be up to 'pf->num_alloc_vsi' that
    can be higher. Fix this loop.
    
    Fixes: 69129dc39fac ("i40e: Modify Tx disable wait flow in case of DCB reconfiguration")
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: accel: bma400: Fix a compilation problem [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed Jan 31 16:52:46 2024 -0600

    iio: accel: bma400: Fix a compilation problem
    
    commit 4cb81840d8f29b66d9d05c6d7f360c9560f7e2f4 upstream.
    
    The kernel fails when compiling without `CONFIG_REGMAP_I2C` but with
    `CONFIG_BMA400`.
    ```
    ld: drivers/iio/accel/bma400_i2c.o: in function `bma400_i2c_probe':
    bma400_i2c.c:(.text+0x23): undefined reference to `__devm_regmap_init_i2c'
    ```
    
    Link: https://download.01.org/0day-ci/archive/20240131/202401311634.FE5CBVwe-lkp@intel.com/config
    Fixes: 465c811f1f20 ("iio: accel: Add driver for the BMA400")
    Fixes: 9bea10642396 ("iio: accel: bma400: add support for bma400 spi")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20240131225246.14169-1-mario.limonciello@amd.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: adc: ad_sigma_delta: ensure proper DMA alignment [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Wed Jan 17 13:41:03 2024 +0100

    iio: adc: ad_sigma_delta: ensure proper DMA alignment
    
    commit 59598510be1d49e1cff7fd7593293bb8e1b2398b upstream.
    
    Aligning the buffer to the L1 cache is not sufficient in some platforms
    as they might have larger cacheline sizes for caches after L1 and thus,
    we can't guarantee DMA safety.
    
    That was the whole reason to introduce IIO_DMA_MINALIGN in [1]. Do the same
    for the sigma_delta ADCs.
    
    [1]: https://lore.kernel.org/linux-iio/20220508175712.647246-2-jic23@kernel.org/
    
    Fixes: 0fb6ee8d0b5e ("iio: ad_sigma_delta: Don't put SPI transfer buffer on the stack")
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240117-dev_sigma_delta_no_irq_flags-v1-1-db39261592cf@analog.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: commom: st_sensors: ensure proper DMA alignment [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Wed Jan 31 10:16:47 2024 +0100

    iio: commom: st_sensors: ensure proper DMA alignment
    
    commit 862cf85fef85becc55a173387527adb4f076fab0 upstream.
    
    Aligning the buffer to the L1 cache is not sufficient in some platforms
    as they might have larger cacheline sizes for caches after L1 and thus,
    we can't guarantee DMA safety.
    
    That was the whole reason to introduce IIO_DMA_MINALIGN in [1]. Do the same
    for st_sensors common buffer.
    
    While at it, moved the odr_lock before buffer_data as we definitely
    don't want any other data to share a cacheline with the buffer.
    
    [1]: https://lore.kernel.org/linux-iio/20220508175712.647246-2-jic23@kernel.org/
    
    Fixes: e031d5f558f1 ("iio:st_sensors: remove buffer allocation at each buffer enable")
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240131-dev_dma_safety_stm-v2-1-580c07fae51b@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: core: fix memleak in iio_device_register_sysfs [+ + +]
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Fri Dec 8 15:31:19 2023 +0800

    iio: core: fix memleak in iio_device_register_sysfs
    
    commit 95a0d596bbd0552a78e13ced43f2be1038883c81 upstream.
    
    When iio_device_register_sysfs_group() fails, we should
    free iio_dev_opaque->chan_attr_group.attrs to prevent
    potential memleak.
    
    Fixes: 32f171724e5c ("iio: core: rework iio device group creation")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Link: https://lore.kernel.org/r/20231208073119.29283-1-dinghao.liu@zju.edu.cn
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: hid-sensor-als: Return 0 for HID_USAGE_SENSOR_TIME_TIMESTAMP [+ + +]
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Sun Feb 4 04:56:17 2024 -0800

    iio: hid-sensor-als: Return 0 for HID_USAGE_SENSOR_TIME_TIMESTAMP
    
    commit 621c6257128149e45b36ffb973a01c3f3461b893 upstream.
    
    When als_capture_sample() is called with usage ID
    HID_USAGE_SENSOR_TIME_TIMESTAMP, return 0. The HID sensor core ignores
    the return value for capture_sample() callback, so return value doesn't
    make difference. But correct the return value to return success instead
    of -EINVAL.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Link: https://lore.kernel.org/r/20240204125617.2635574-1-srinivas.pandruvada@linux.intel.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: imu: adis: ensure proper DMA alignment [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Wed Jan 17 14:10:49 2024 +0100

    iio: imu: adis: ensure proper DMA alignment
    
    commit 8e98b87f515d8c4bae521048a037b2cc431c3fd5 upstream.
    
    Aligning the buffer to the L1 cache is not sufficient in some platforms
    as they might have larger cacheline sizes for caches after L1 and thus,
    we can't guarantee DMA safety.
    
    That was the whole reason to introduce IIO_DMA_MINALIGN in [1]. Do the same
    for the sigma_delta ADCs.
    
    [1]: https://lore.kernel.org/linux-iio/20220508175712.647246-2-jic23@kernel.org/
    
    Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library")
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240117-adis-improv-v1-1-7f90e9fad200@analog.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: imu: bno055: serdev requires REGMAP [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Wed Jan 10 10:56:11 2024 -0800

    iio: imu: bno055: serdev requires REGMAP
    
    commit 35ec2d03b282a939949090bd8c39eb37a5856721 upstream.
    
    There are a ton of build errors when REGMAP is not set, so select
    REGMAP to fix all of them.
    
    Examples (not all of them):
    
    ../drivers/iio/imu/bno055/bno055_ser_core.c:495:15: error: variable 'bno055_ser_regmap_bus' has initializer but incomplete type
      495 | static struct regmap_bus bno055_ser_regmap_bus = {
    ../drivers/iio/imu/bno055/bno055_ser_core.c:496:10: error: 'struct regmap_bus' has no member named 'write'
      496 |         .write = bno055_ser_write_reg,
    ../drivers/iio/imu/bno055/bno055_ser_core.c:497:10: error: 'struct regmap_bus' has no member named 'read'
      497 |         .read = bno055_ser_read_reg,
    ../drivers/iio/imu/bno055/bno055_ser_core.c: In function 'bno055_ser_probe':
    ../drivers/iio/imu/bno055/bno055_ser_core.c:532:18: error: implicit declaration of function 'devm_regmap_init'; did you mean 'vmem_map_init'? [-Werror=implicit-function-declaration]
      532 |         regmap = devm_regmap_init(&serdev->dev, &bno055_ser_regmap_bus,
    ../drivers/iio/imu/bno055/bno055_ser_core.c:532:16: warning: assignment to 'struct regmap *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
      532 |         regmap = devm_regmap_init(&serdev->dev, &bno055_ser_regmap_bus,
    ../drivers/iio/imu/bno055/bno055_ser_core.c: At top level:
    ../drivers/iio/imu/bno055/bno055_ser_core.c:495:26: error: storage size of 'bno055_ser_regmap_bus' isn't known
      495 | static struct regmap_bus bno055_ser_regmap_bus = {
    
    Fixes: 2eef5a9cc643 ("iio: imu: add BNO055 serdev driver")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Andrea Merello <andrea.merello@iit.it>
    Cc: Jonathan Cameron <jic23@kernel.org>
    Cc: Lars-Peter Clausen <lars@metafoo.de>
    Cc: linux-iio@vger.kernel.org
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240110185611.19723-1-rdunlap@infradead.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC [+ + +]
Author: zhili.liu <zhili.liu@ucas.com.cn>
Date:   Tue Jan 2 09:07:11 2024 +0800

    iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC
    
    commit 792595bab4925aa06532a14dd256db523eb4fa5e upstream.
    
    Recently, we encounter kernel crash in function rm3100_common_probe
    caused by out of bound access of array rm3100_samp_rates (because of
    underlying hardware failures). Add boundary check to prevent out of
    bound access.
    
    Fixes: 121354b2eceb ("iio: magnetometer: Add driver support for PNI RM3100")
    Suggested-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
    Signed-off-by: zhili.liu <zhili.liu@ucas.com.cn>
    Link: https://lore.kernel.org/r/1704157631-3814-1-git-send-email-zhouzhouyi@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
interconnect: qcom: sc8180x: Mark CO0 BCM keepalive [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Jan 10 15:16:26 2024 +0200

    interconnect: qcom: sc8180x: Mark CO0 BCM keepalive
    
    [ Upstream commit 85e985a4f46e462a37f1875cb74ed380e7c0c2e0 ]
    
    The CO0 BCM needs to be up at all times, otherwise some hardware (like
    the UFS controller) loses its connection to the rest of the SoC,
    resulting in a hang of the platform, accompanied by a spectacular
    logspam.
    
    Mark it as keepalive to prevent such cases.
    
    Fixes: 9c8c6bac1ae8 ("interconnect: qcom: Add SC8180x providers")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20231214-topic-sc8180_fixes-v1-1-421904863006@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring/net: fix multishot accept overflow handling [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Wed Feb 14 08:23:05 2024 -0700

    io_uring/net: fix multishot accept overflow handling
    
    commit a37ee9e117ef73bbc2f5c0b31911afd52d229861 upstream.
    
    If we hit CQ ring overflow when attempting to post a multishot accept
    completion, we don't properly save the result or return code. This
    results in losing the accepted fd value.
    
    Instead, we return the result from the poll operation that triggered
    the accept retry. This is generally POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND
    which is 0xc3, or 195, which looks like a valid file descriptor, but it
    really has no connection to that.
    
    Handle this like we do for other multishot completions - assign the
    result, and return IOU_STOP_MULTISHOT to cancel any further completions
    from this request when overflow is hit. This preserves the result, as we
    should, and tells the application that the request needs to be re-armed.
    
    Cc: stable@vger.kernel.org
    Fixes: 515e26961295 ("io_uring: revert "io_uring fix multishot accept ordering"")
    Link: https://github.com/axboe/liburing/issues/1062
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
irqchip/gic-v3-its: Fix GICv4.1 VPE affinity update [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Tue Feb 13 10:12:06 2024 +0000

    irqchip/gic-v3-its: Fix GICv4.1 VPE affinity update
    
    commit af9acbfc2c4b72c378d0b9a2ee023ed01055d3e2 upstream.
    
    When updating the affinity of a VPE, the VMOVP command is currently skipped
    if the two CPUs are part of the same VPE affinity.
    
    But this is wrong, as the doorbell corresponding to this VPE is still
    delivered on the 'old' CPU, which screws up the balancing.  Furthermore,
    offlining that 'old' CPU results in doorbell interrupts generated for this
    VPE being discarded.
    
    The harsh reality is that VMOVP cannot be elided when a set_affinity()
    request occurs. It needs to be obeyed, and if an optimisation is to be
    made, it is at the point where the affinity change request is made (such as
    in KVM).
    
    Drop the VMOVP elision altogether, and only use the vpe_table_mask
    to try and stay within the same ITS affinity group if at all possible.
    
    Fixes: dd3f050a216e (irqchip/gic-v4.1: Implement the v4.1 flavour of VMOVP)
    Reported-by: Kunkun Jiang <jiangkunkun@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240213101206.2137483-4-maz@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
irqchip/irq-brcmstb-l2: Add write memory barrier before exit [+ + +]
Author: Doug Berger <opendmb@gmail.com>
Date:   Fri Feb 9 17:24:49 2024 -0800

    irqchip/irq-brcmstb-l2: Add write memory barrier before exit
    
    commit b0344d6854d25a8b3b901c778b1728885dd99007 upstream.
    
    It was observed on Broadcom devices that use GIC v3 architecture L1
    interrupt controllers as the parent of brcmstb-l2 interrupt controllers
    that the deactivation of the parent interrupt could happen before the
    brcmstb-l2 deasserted its output. This would lead the GIC to reactivate the
    interrupt only to find that no L2 interrupt was pending. The result was a
    spurious interrupt invoking handle_bad_irq() with its associated
    messaging. While this did not create a functional problem it is a waste of
    cycles.
    
    The hazard exists because the memory mapped bus writes to the brcmstb-l2
    registers are buffered and the GIC v3 architecture uses a very efficient
    system register write to deactivate the interrupt.
    
    Add a write memory barrier prior to invoking chained_irq_exit() to
    introduce a dsb(st) on those systems to ensure the system register write
    cannot be executed until the memory mapped writes are visible to the
    system.
    
    [ florian: Added Fixes tag ]
    
    Fixes: 7f646e92766e ("irqchip: brcmstb-l2: Add Broadcom Set Top Box  Level-2 interrupt controller")
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240210012449.3009125-1-florian.fainelli@broadcom.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
irqchip/loongson-eiointc: Use correct struct type in eiointc_domain_alloc() [+ + +]
Author: Bibo Mao <maobibo@loongson.cn>
Date:   Tue Jan 30 16:27:20 2024 +0800

    irqchip/loongson-eiointc: Use correct struct type in eiointc_domain_alloc()
    
    [ Upstream commit f1c2765c6afcd1f71f76ed8c9bf94acedab4cecb ]
    
    eiointc_domain_alloc() uses struct eiointc, which is not defined, for a
    pointer. Older compilers treat that as a forward declaration and due to
    assignment of a void pointer there is no warning emitted. As the variable
    is then handed in as a void pointer argument to irq_domain_set_info() the
    code is functional.
    
    Use struct eiointc_priv instead.
    
    [ tglx: Rewrote changelog ]
    
    Fixes: dd281e1a1a93 ("irqchip: Add Loongson Extended I/O interrupt controller support")
    Signed-off-by: Bibo Mao <maobibo@loongson.cn>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Huacai Chen <chenhuacai@loongson.cn>
    Link: https://lore.kernel.org/r/20240130082722.2912576-2-maobibo@loongson.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kbuild: Drop -Wdeclaration-after-statement [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jun 9 11:28:30 2023 +0200

    kbuild: Drop -Wdeclaration-after-statement
    
    commit b5ec6fd286dfa466f64cb0e56ed768092d0342ae upstream.
    
    With the advent on scope-based resource management it comes really
    tedious to abide by the contraints of -Wdeclaration-after-statement.
    
    It will still be recommeneded to place declarations at the start of a
    scope where possible, but it will no longer be enforced.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/CAHk-%3Dwi-RyoUhbChiVaJZoZXheAwnJ7OO%3DGxe85BkPAd93TwDA%40mail.gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kbuild: Fix changing ELF file type for output of gen_btf for big endian [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon Feb 12 19:05:10 2024 -0700

    kbuild: Fix changing ELF file type for output of gen_btf for big endian
    
    commit e3a9ee963ad8ba677ca925149812c5932b49af69 upstream.
    
    Commit 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
    changed the ELF type of .btf.vmlinux.bin.o to ET_REL via dd, which works
    fine for little endian platforms:
    
       00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
      -00000010  03 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|
      +00000010  01 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|
    
    However, for big endian platforms, it changes the wrong byte, resulting
    in an invalid ELF file type, which ld.lld rejects:
    
       00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
      -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
      +00000010  01 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
    
      Type:                              <unknown>: 103
    
      ld.lld: error: .btf.vmlinux.bin.o: unknown file type
    
    Fix this by updating the entire 16-bit e_type field rather than just a
    single byte, so that everything works correctly for all platforms and
    linkers.
    
       00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
      -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
      +00000010  00 01 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
    
      Type:                              REL (Relocatable file)
    
    While in the area, update the comment to mention that binutils 2.35+
    matches LLD's behavior of rejecting an ET_EXEC input, which occurred
    after the comment was added.
    
    Cc: stable@vger.kernel.org
    Fixes: 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
    Link: https://github.com/llvm/llvm-project/pull/75643
    Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Fangrui Song <maskray@google.com>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Justin Stitt <justinstitt@google.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ksmbd: free aux buffer if ksmbd_iov_pin_rsp_read fails [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Mon Feb 5 14:19:16 2024 +0300

    ksmbd: free aux buffer if ksmbd_iov_pin_rsp_read fails
    
    commit 108a020c64434fed4b69762879d78cd24088b4c7 upstream.
    
    ksmbd_iov_pin_rsp_read() doesn't free the provided aux buffer if it
    fails. Seems to be the caller's responsibility to clear the buffer in
    error case.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound")
    Cc: stable@vger.kernel.org
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KVM: selftests: Clear dirty ring states between two modes in dirty_log_test [+ + +]
Author: Gavin Shan <gshan@redhat.com>
Date:   Thu Nov 10 18:49:13 2022 +0800

    KVM: selftests: Clear dirty ring states between two modes in dirty_log_test
    
    [ Upstream commit 7167190ddb863bd061c0c6b61f4cec94184b40da ]
    
    There are two states, which need to be cleared before next mode
    is executed. Otherwise, we will hit failure as the following messages
    indicate.
    
    - The variable 'dirty_ring_vcpu_ring_full' shared by main and vcpu
      thread. It's indicating if the vcpu exit due to full ring buffer.
      The value can be carried from previous mode (VM_MODE_P40V48_4K) to
      current one (VM_MODE_P40V48_64K) when VM_MODE_P40V48_16K isn't
      supported.
    
    - The current ring buffer index needs to be reset before next mode
      (VM_MODE_P40V48_64K) is executed. Otherwise, the stale value is
      carried from previous mode (VM_MODE_P40V48_4K).
    
      # ./dirty_log_test -M dirty-ring
      Setting log mode to: 'dirty-ring'
      Test iterations: 32, interval: 10 (ms)
      Testing guest mode: PA-bits:40,  VA-bits:48,  4K pages
      guest physical test memory offset: 0xffbfffc000
        :
      Dirtied 995328 pages
      Total bits checked: dirty (1012434), clear (7114123), track_next (966700)
      Testing guest mode: PA-bits:40,  VA-bits:48, 64K pages
      guest physical test memory offset: 0xffbffc0000
      vcpu stops because vcpu is kicked out...
      vcpu continues now.
      Notifying vcpu to continue
      Iteration 1 collected 0 pages
      vcpu stops because dirty ring is full...
      vcpu continues now.
      vcpu stops because dirty ring is full...
      vcpu continues now.
      vcpu stops because dirty ring is full...
      ==== Test Assertion Failure ====
      dirty_log_test.c:369: cleared == count
      pid=10541 tid=10541 errno=22 - Invalid argument
         1  0x0000000000403087: dirty_ring_collect_dirty_pages at dirty_log_test.c:369
         2  0x0000000000402a0b: log_mode_collect_dirty_pages at dirty_log_test.c:492
         3   (inlined by) run_test at dirty_log_test.c:795
         4   (inlined by) run_test at dirty_log_test.c:705
         5  0x0000000000403a37: for_each_guest_mode at guest_modes.c:100
         6  0x0000000000401ccf: main at dirty_log_test.c:938
         7  0x0000ffff9ecd279b: ?? ??:0
         8  0x0000ffff9ecd286b: ?? ??:0
         9  0x0000000000401def: _start at ??:?
      Reset dirty pages (0) mismatch with collected (35566)
    
    Fix the issues by clearing 'dirty_ring_vcpu_ring_full' and the ring
    buffer index before next new mode is to be executed.
    
    Signed-off-by: Gavin Shan <gshan@redhat.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20221110104914.31280-7-gshan@redhat.com
    Stable-dep-of: ba58f873cdee ("KVM: selftests: Fix a semaphore imbalance in the dirty ring logging test")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: selftests: Fix a semaphore imbalance in the dirty ring logging test [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Feb 2 15:18:31 2024 -0800

    KVM: selftests: Fix a semaphore imbalance in the dirty ring logging test
    
    [ Upstream commit ba58f873cdeec30b6da48e28dd5782c5a3e1371b ]
    
    When finishing the final iteration of dirty_log_test testcase, set
    host_quit _before_ the final "continue" so that the vCPU worker doesn't
    run an extra iteration, and delete the hack-a-fix of an extra "continue"
    from the dirty ring testcase.  This fixes a bug where the extra post to
    sem_vcpu_cont may not be consumed, which results in failures in subsequent
    runs of the testcases.  The bug likely was missed during development as
    x86 supports only a single "guest mode", i.e. there aren't any subsequent
    testcases after the dirty ring test, because for_each_guest_mode() only
    runs a single iteration.
    
    For the regular dirty log testcases, letting the vCPU run one extra
    iteration is a non-issue as the vCPU worker waits on sem_vcpu_cont if and
    only if the worker is explicitly told to stop (vcpu_sync_stop_requested).
    But for the dirty ring test, which needs to periodically stop the vCPU to
    reap the dirty ring, letting the vCPU resume the guest _after_ the last
    iteration means the vCPU will get stuck without an extra "continue".
    
    However, blindly firing off an post to sem_vcpu_cont isn't guaranteed to
    be consumed, e.g. if the vCPU worker sees host_quit==true before resuming
    the guest.  This results in a dangling sem_vcpu_cont, which leads to
    subsequent iterations getting out of sync, as the vCPU worker will
    continue on before the main task is ready for it to resume the guest,
    leading to a variety of asserts, e.g.
    
      ==== Test Assertion Failure ====
      dirty_log_test.c:384: dirty_ring_vcpu_ring_full
      pid=14854 tid=14854 errno=22 - Invalid argument
         1  0x00000000004033eb: dirty_ring_collect_dirty_pages at dirty_log_test.c:384
         2  0x0000000000402d27: log_mode_collect_dirty_pages at dirty_log_test.c:505
         3   (inlined by) run_test at dirty_log_test.c:802
         4  0x0000000000403dc7: for_each_guest_mode at guest_modes.c:100
         5  0x0000000000401dff: main at dirty_log_test.c:941 (discriminator 3)
         6  0x0000ffff9be173c7: ?? ??:0
         7  0x0000ffff9be1749f: ?? ??:0
         8  0x000000000040206f: _start at ??:?
      Didn't continue vcpu even without ring full
    
    Alternatively, the test could simply reset the semaphores before each
    testcase, but papering over hacks with more hacks usually ends in tears.
    
    Reported-by: Shaoqin Huang <shahuang@redhat.com>
    Fixes: 84292e565951 ("KVM: selftests: Add dirty ring buffer test")
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Reviewed-by: Shaoqin Huang <shahuang@redhat.com>
    Link: https://lore.kernel.org/r/20240202231831.354848-1-seanjc@google.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86/pmu: Fix type length error when reading pmu->fixed_ctr_ctrl [+ + +]
Author: Mingwei Zhang <mizhang@google.com>
Date:   Tue Jan 23 22:12:20 2024 +0000

    KVM: x86/pmu: Fix type length error when reading pmu->fixed_ctr_ctrl
    
    commit 05519c86d6997cfb9bb6c82ce1595d1015b718dc upstream.
    
    Use a u64 instead of a u8 when taking a snapshot of pmu->fixed_ctr_ctrl
    when reprogramming fixed counters, as truncating the value results in KVM
    thinking fixed counter 2 is already disabled (the bug also affects fixed
    counters 3+, but KVM doesn't yet support those).  As a result, if the
    guest disables fixed counter 2, KVM will get a false negative and fail to
    reprogram/disable emulation of the counter, which can leads to incorrect
    counts and spurious PMIs in the guest.
    
    Fixes: 76d287b2342e ("KVM: x86/pmu: Drop "u8 ctrl, int idx" for reprogram_fixed_counter()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mingwei Zhang <mizhang@google.com>
    Link: https://lore.kernel.org/r/20240123221220.3911317-1-mizhang@google.com
    [sean: rewrite changelog to call out the effects of the bug]
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
lan966x: Fix crash when adding interface under a lag [+ + +]
Author: Horatiu Vultur <horatiu.vultur@microchip.com>
Date:   Tue Feb 6 13:30:54 2024 +0100

    lan966x: Fix crash when adding interface under a lag
    
    [ Upstream commit 15faa1f67ab405d47789d4702f587ec7df7ef03e ]
    
    There is a crash when adding one of the lan966x interfaces under a lag
    interface. The issue can be reproduced like this:
    ip link add name bond0 type bond miimon 100 mode balance-xor
    ip link set dev eth0 master bond0
    
    The reason is because when adding a interface under the lag it would go
    through all the ports and try to figure out which other ports are under
    that lag interface. And the issue is that lan966x can have ports that are
    NULL pointer as they are not probed. So then iterating over these ports
    it would just crash as they are NULL pointers.
    The fix consists in actually checking for NULL pointers before accessing
    something from the ports. Like we do in other places.
    
    Fixes: cabc9d49333d ("net: lan966x: Add lag support for lan966x")
    Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240206123054.3052966-1-horatiu.vultur@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 6.1.79 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Feb 23 09:12:53 2024 +0100

    Linux 6.1.79
    
    Link: https://lore.kernel.org/r/20240220204841.073267068@linuxfoundation.org
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20240221130223.073542172@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Yann Sionneau<ysionneau@kalrayinc.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
linux/init: remove __memexit* annotations [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Oct 23 02:06:05 2023 +0900

    linux/init: remove __memexit* annotations
    
    commit 6a4e59eeedc3018cb57722eecfcbb49431aeb05f upstream.
    
    We have never used __memexit, __memexitdata, or __memexitconst.
    
    These were unneeded.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    [nathan: Remove additional case of XXXEXIT_TO_SOME_EXIT due to lack of
             78dac1a22944 in 6.1]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Stable-dep-of: 846cfbeed09b ("um: Fix adding '-no-pie' for clang")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
locking: Introduce __cleanup() based infrastructure [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri May 26 12:23:48 2023 +0200

    locking: Introduce __cleanup() based infrastructure
    
    commit 54da6a0924311c7cf5015533991e44fb8eb12773 upstream.
    
    Use __attribute__((__cleanup__(func))) to build:
    
     - simple auto-release pointers using __free()
    
     - 'classes' with constructor and destructor semantics for
       scope-based resource management.
    
     - lock guards based on the above classes.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20230612093537.614161713%40infradead.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
lsm: fix the logic in security_inode_getsecctx() [+ + +]
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date:   Fri Jan 26 11:44:03 2024 +0100

    lsm: fix the logic in security_inode_getsecctx()
    
    commit 99b817c173cd213671daecd25ca27f56b0c7c4ec upstream.
    
    The inode_getsecctx LSM hook has previously been corrected to have
    -EOPNOTSUPP instead of 0 as the default return value to fix BPF LSM
    behavior. However, the call_int_hook()-generated loop in
    security_inode_getsecctx() was left treating 0 as the neutral value, so
    after an LSM returns 0, the loop continues to try other LSMs, and if one
    of them returns a non-zero value, the function immediately returns with
    said value. So in a situation where SELinux and the BPF LSMs registered
    this hook, -EOPNOTSUPP would be incorrectly returned whenever SELinux
    returned 0.
    
    Fix this by open-coding the call_int_hook() loop and making it use the
    correct LSM_RET_DEFAULT() value as the neutral one, similar to what
    other hooks do.
    
    Cc: stable@vger.kernel.org
    Reported-by: Stephen Smalley <stephen.smalley.work@gmail.com>
    Link: https://lore.kernel.org/selinux/CAEjxPJ4ev-pasUwGx48fDhnmjBnq_Wh90jYPwRQRAqXxmOKD4Q@mail.gmail.com/
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2257983
    Fixes: b36995b8609a ("lsm: fix default return value for inode_getsecctx")
    Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
    Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
    [PM: subject line tweak]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
md: bypass block throttle for superblock update [+ + +]
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Wed Nov 8 10:22:15 2023 -0800

    md: bypass block throttle for superblock update
    
    [ Upstream commit d6e035aad6c09991da1c667fb83419329a3baed8 ]
    
    commit 5e2cf333b7bd ("md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d")
    introduced a hung bug and will be reverted in next patch, since the issue
    that commit is fixing is due to md superblock write is throttled by wbt,
    to fix it, we can have superblock write bypass block layer throttle.
    
    Fixes: 5e2cf333b7bd ("md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d")
    Cc: stable@vger.kernel.org # v5.19+
    Suggested-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20231108182216.73611-1-junxiao.bi@oracle.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
media: ir_toy: fix a memleak in irtoy_tx [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Wed Jan 17 09:14:19 2024 +0100

    media: ir_toy: fix a memleak in irtoy_tx
    
    [ Upstream commit dc9ceb90c4b42c6e5c6757df1d6257110433788e ]
    
    When irtoy_command fails, buf should be freed since it is allocated by
    irtoy_tx, or there is a memleak.
    
    Fixes: 4114978dcd24 ("media: ir_toy: prevent device from hanging during transmit")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: rc: bpf attach/detach requires write permission [+ + +]
Author: Sean Young <sean@mess.org>
Date:   Thu Apr 13 10:50:32 2023 +0200

    media: rc: bpf attach/detach requires write permission
    
    commit 6a9d552483d50953320b9d3b57abdee8d436f23f upstream.
    
    Note that bpf attach/detach also requires CAP_NET_ADMIN.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: Revert "media: rkisp1: Drop IRQF_SHARED" [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Mon Dec 18 08:54:00 2023 +0100

    media: Revert "media: rkisp1: Drop IRQF_SHARED"
    
    commit a107d643b2a3382e0a2d2c4ef08bf8c6bff4561d upstream.
    
    This reverts commit 85d2a31fe4d9be1555f621ead7a520d8791e0f74.
    
    The rkisp1 does share interrupt lines on some platforms, after all. Thus
    we need to revert this, and implement a fix for the rkisp1 shared irq
    handling in a follow-up patch.
    
    Closes: https://lore.kernel.org/all/87o7eo8vym.fsf@gmail.com/
    Link: https://lore.kernel.org/r/20231218-rkisp-shirq-fix-v1-1-173007628248@ideasonboard.com
    
    Reported-by: Mikhail Rudenko <mike.rudenko@gmail.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
MIPS: Add 'memory' clobber to csum_ipv6_magic() inline assembler [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Feb 11 08:08:37 2024 -0800

    MIPS: Add 'memory' clobber to csum_ipv6_magic() inline assembler
    
    [ Upstream commit d55347bfe4e66dce2e1e7501e5492f4af3e315f8 ]
    
    After 'lib: checksum: Use aligned accesses for ip_fast_csum and
    csum_ipv6_magic tests' was applied, the test_csum_ipv6_magic unit test
    started failing for all mips platforms, both little and bit endian.
    Oddly enough, adding debug code into test_csum_ipv6_magic() made the
    problem disappear.
    
    The gcc manual says:
    
    "The "memory" clobber tells the compiler that the assembly code performs
     memory reads or writes to items other than those listed in the input
     and output operands (for example, accessing the memory pointed to by one
     of the input parameters)
    "
    
    This is definitely the case for csum_ipv6_magic(). Indeed, adding the
    'memory' clobber fixes the problem.
    
    Cc: Charlie Jenkins <charlie@rivosinc.com>
    Cc: Palmer Dabbelt <palmer@rivosinc.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
misc: fastrpc: Mark all sessions as invalid in cb_remove [+ + +]
Author: Ekansh Gupta <quic_ekangupt@quicinc.com>
Date:   Mon Jan 8 17:18:33 2024 +0530

    misc: fastrpc: Mark all sessions as invalid in cb_remove
    
    commit a4e61de63e34860c36a71d1a364edba16fb6203b upstream.
    
    In remoteproc shutdown sequence, rpmsg_remove will get called which
    would depopulate all the child nodes that have been created during
    rpmsg_probe. This would result in cb_remove call for all the context
    banks for the remoteproc. In cb_remove function, session 0 is
    getting skipped which is not correct as session 0 will never become
    available again. Add changes to mark session 0 also as invalid.
    
    Fixes: f6f9279f2bf0 ("misc: fastrpc: Add Qualcomm fastrpc basic driver model")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
    Link: https://lore.kernel.org/r/20240108114833.20480-1-quic_ekangupt@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mlxsw: spectrum_acl_tcam: Fix stack corruption [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Wed Jan 17 16:04:18 2024 +0100

    mlxsw: spectrum_acl_tcam: Fix stack corruption
    
    commit 483ae90d8f976f8339cf81066312e1329f2d3706 upstream.
    
    When tc filters are first added to a net device, the corresponding local
    port gets bound to an ACL group in the device. The group contains a list
    of ACLs. In turn, each ACL points to a different TCAM region where the
    filters are stored. During forwarding, the ACLs are sequentially
    evaluated until a match is found.
    
    One reason to place filters in different regions is when they are added
    with decreasing priorities and in an alternating order so that two
    consecutive filters can never fit in the same region because of their
    key usage.
    
    In Spectrum-2 and newer ASICs the firmware started to report that the
    maximum number of ACLs in a group is more than 16, but the layout of the
    register that configures ACL groups (PAGT) was not updated to account
    for that. It is therefore possible to hit stack corruption [1] in the
    rare case where more than 16 ACLs in a group are required.
    
    Fix by limiting the maximum ACL group size to the minimum between what
    the firmware reports and the maximum ACLs that fit in the PAGT register.
    
    Add a test case to make sure the machine does not crash when this
    condition is hit.
    
    [1]
    Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120
    [...]
     dump_stack_lvl+0x36/0x50
     panic+0x305/0x330
     __stack_chk_fail+0x15/0x20
     mlxsw_sp_acl_tcam_group_update+0x116/0x120
     mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110
     mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20
     mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
     mlxsw_sp_acl_rule_add+0x47/0x240
     mlxsw_sp_flower_replace+0x1a9/0x1d0
     tc_setup_cb_add+0xdc/0x1c0
     fl_hw_replace_filter+0x146/0x1f0
     fl_change+0xc17/0x1360
     tc_new_tfilter+0x472/0xb90
     rtnetlink_rcv_msg+0x313/0x3b0
     netlink_rcv_skb+0x58/0x100
     netlink_unicast+0x244/0x390
     netlink_sendmsg+0x1e4/0x440
     ____sys_sendmsg+0x164/0x260
     ___sys_sendmsg+0x9a/0xe0
     __sys_sendmsg+0x7a/0xc0
     do_syscall_64+0x40/0xe0
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Fixes: c3ab435466d5 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
    Reported-by: Orel Hagag <orelh@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Amit Cohen <amcohen@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/2d91c89afba59c22587b444994ae419dbea8d876.1705502064.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again [+ + +]
Author: Zach O'Keefe <zokeefe@google.com>
Date:   Thu Jan 18 10:19:53 2024 -0800

    mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again
    
    commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78 upstream.
    
    (struct dirty_throttle_control *)->thresh is an unsigned long, but is
    passed as the u32 divisor argument to div_u64().  On architectures where
    unsigned long is 64 bytes, the argument will be implicitly truncated.
    
    Use div64_u64() instead of div_u64() so that the value used in the "is
    this a safe division" check is the same as the divisor.
    
    Also, remove redundant cast of the numerator to u64, as that should happen
    implicitly.
    
    This would be difficult to exploit in memcg domain, given the ratio-based
    arithmetic domain_drity_limits() uses, but is much easier in global
    writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g.
    vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32)
    
    Link: https://lkml.kernel.org/r/20240118181954.1415197-1-zokeefe@google.com
    Fixes: f6789593d5ce ("mm/page-writeback.c: fix divide by zero in bdi_dirty_limits()")
    Signed-off-by: Zach O'Keefe <zokeefe@google.com>
    Cc: Maxim Patlasov <MPatlasov@parallels.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: hugetlb pages should not be reserved by shmat() if SHM_NORESERVE [+ + +]
Author: Prakash Sangappa <prakash.sangappa@oracle.com>
Date:   Tue Jan 23 12:04:42 2024 -0800

    mm: hugetlb pages should not be reserved by shmat() if SHM_NORESERVE
    
    commit e656c7a9e59607d1672d85ffa9a89031876ffe67 upstream.
    
    For shared memory of type SHM_HUGETLB, hugetlb pages are reserved in
    shmget() call.  If SHM_NORESERVE flags is specified then the hugetlb pages
    are not reserved.  However when the shared memory is attached with the
    shmat() call the hugetlb pages are getting reserved incorrectly for
    SHM_HUGETLB shared memory created with SHM_NORESERVE which is a bug.
    
    -------------------------------
    Following test shows the issue.
    
    $cat shmhtb.c
    
    int main()
    {
            int shmflags = 0660 | IPC_CREAT | SHM_HUGETLB | SHM_NORESERVE;
            int shmid;
    
            shmid = shmget(SKEY, SHMSZ, shmflags);
            if (shmid < 0)
            {
                    printf("shmat: shmget() failed, %d\n", errno);
                    return 1;
            }
            printf("After shmget()\n");
            system("cat /proc/meminfo | grep -i hugepages_");
    
            shmat(shmid, NULL, 0);
            printf("\nAfter shmat()\n");
            system("cat /proc/meminfo | grep -i hugepages_");
    
            shmctl(shmid, IPC_RMID, NULL);
            return 0;
    }
    
     #sysctl -w vm.nr_hugepages=20
     #./shmhtb
    
    After shmget()
    HugePages_Total:      20
    HugePages_Free:       20
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    
    After shmat()
    HugePages_Total:      20
    HugePages_Free:       20
    HugePages_Rsvd:        5 <--
    HugePages_Surp:        0
    --------------------------------
    
    Fix is to ensure that hugetlb pages are not reserved for SHM_HUGETLB shared
    memory in the shmat() call.
    
    Link: https://lkml.kernel.org/r/1706040282-12388-1-git-send-email-prakash.sangappa@oracle.com
    Signed-off-by: Prakash Sangappa <prakash.sangappa@oracle.com>
    Acked-by: Muchun Song <muchun.song@linux.dev>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: sdhci-pci-o2micro: Fix a warm reboot issue that disk can't be detected by BIOS [+ + +]
Author: Fred Ai <fred.ai@bayhubtech.com>
Date:   Sat Feb 3 02:29:08 2024 -0800

    mmc: sdhci-pci-o2micro: Fix a warm reboot issue that disk can't be detected by BIOS
    
    commit 58aeb5623c2ebdadefe6352b14f8076a7073fea0 upstream.
    
    Driver shall switch clock source from DLL clock to
    OPE clock when power off card to ensure that card
    can be identified with OPE clock by BIOS.
    
    Signed-off-by: Fred Ai <fred.ai@bayhubtech.com>
    Fixes:4be33cf18703 ("mmc: sdhci-pci-o2micro: Improve card input timing at SDR104/HS200 mode")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240203102908.4683-1-fredaibayhubtech@126.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: slot-gpio: Allow non-sleeping GPIO ro [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Tue Feb 6 09:39:12 2024 +0100

    mmc: slot-gpio: Allow non-sleeping GPIO ro
    
    commit cc9432c4fb159a3913e0ce3173b8218cd5bad2e0 upstream.
    
    This change uses the appropriate _cansleep or non-sleeping API for
    reading GPIO read-only state. This allows users with GPIOs that
    never sleepbeing called in atomic context.
    
    Implement the same mechanism as in commit 52af318c93e97 ("mmc: Allow
    non-sleeping GPIO cd").
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240206083912.2543142-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Jan 23 15:59:55 2024 -0700

    modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS
    
    commit 397586506c3da005b9333ce5947ad01e8018a3be upstream.
    
    After the linked LLVM change, building ARCH=um defconfig results in a
    segmentation fault in modpost. Prior to commit a23e7584ecf3 ("modpost:
    unify 'sym' and 'to' in default_mismatch_handler()"), there was a
    warning:
    
      WARNING: modpost: vmlinux.o(__ex_table+0x88): Section mismatch in reference to the .ltext:(unknown)
      WARNING: modpost: The relocation at __ex_table+0x88 references
      section ".ltext" which is not in the list of
      authorized sections.  If you're adding a new section
      and/or if this reference is valid, add ".ltext" to the
      list of authorized sections to jump to on fault.
      This can be achieved by adding ".ltext" to
      OTHER_TEXT_SECTIONS in scripts/mod/modpost.c.
    
    The linked LLVM change moves global objects to the '.ltext' (and
    '.ltext.*' with '-ffunction-sections') sections with '-mcmodel=large',
    which ARCH=um uses. These sections should be handled just as '.text'
    and '.text.*' are, so add them to TEXT_SECTIONS.
    
    Cc: stable@vger.kernel.org
    Closes: https://github.com/ClangBuiltLinux/linux/issues/1981
    Link: https://github.com/llvm/llvm-project/commit/4bf8a688956a759b7b6b8d94f42d25c13c7af130
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

modpost: Don't let "driver"s reference .exit.* [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sat Sep 30 18:52:04 2023 +0200

    modpost: Don't let "driver"s reference .exit.*
    
    commit f177cd0c15fcc7bdbb68d8d1a3166dead95314c8 upstream.
    
    Drivers must not reference functions marked with __exit as these likely
    are not available when the code is built-in.
    
    There are few creative offenders uncovered for example in ARCH=amd64
    allmodconfig builds. So only trigger the section mismatch warning for
    W=1 builds.
    
    The dual rule that drivers must not reference .init.* is implemented
    since commit 0db252452378 ("modpost: don't allow *driver to reference
    .init.*") which however missed that .exit.* should be handled in the
    same way.
    
    Thanks to Masahiro Yamada and Arnd Bergmann who gave valuable hints to
    find this improvement.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Stable-dep-of: 846cfbeed09b ("um: Fix adding '-no-pie' for clang")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

modpost: Include '.text.*' in TEXT_SECTIONS [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Dec 13 11:35:29 2022 -0700

    modpost: Include '.text.*' in TEXT_SECTIONS
    
    commit 19331e84c3873256537d446afec1f6c507f8c4ef upstream.
    
    Commit 6c730bfc894f ("modpost: handle -ffunction-sections") added
    ".text.*" to the OTHER_TEXT_SECTIONS macro to fix certain section
    mismatch warnings. Unfortunately, this makes it impossible for modpost
    to warn about section mismatches with LTO, which implies
    '-ffunction-sections', as all functions are put in their own
    '.text.<func_name>' sections, which may still reference functions in
    sections they are not supposed to, such as __init.
    
    Fix this by moving ".text.*" into TEXT_SECTIONS, so that configurations
    with '-ffunction-sections' will see warnings about mismatched sections.
    
    Link: https://lore.kernel.org/Y39kI3MOtVI5BAnV@google.com/
    Reported-by: Vincent Donnefort <vdonnefort@google.com>
    Reviewed-and-tested-by: Alexander Lobakin <alexandr.lobakin@intel.com>
    Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
    Tested-by: Vincent Donnefort <vdonnefort@google.com>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Stable-dep-of: 846cfbeed09b ("um: Fix adding '-no-pie' for clang")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

modpost: propagate W=1 build option to modpost [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue Jun 6 18:41:59 2023 +0900

    modpost: propagate W=1 build option to modpost
    
    commit 20ff36856fe00879f82de71fe6f1482ca1b72334 upstream.
    
    "No build warning" is a strong requirement these days, so you must fix
    all issues before enabling a new warning flag.
    
    We often add a new warning to W=1 first so that the kbuild test robot
    blocks new breakages.
    
    This commit allows modpost to show extra warnings only when W=1
    (or KBUILD_EXTRA_WARN=1) is given.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Stable-dep-of: 846cfbeed09b ("um: Fix adding '-no-pie' for clang")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

modpost: trim leading spaces when processing source files list [+ + +]
Author: Radek Krejci <radek.krejci@oracle.com>
Date:   Wed Feb 14 10:14:07 2024 +0100

    modpost: trim leading spaces when processing source files list
    
    [ Upstream commit 5d9a16b2a4d9e8fa028892ded43f6501bc2969e5 ]
    
    get_line() does not trim the leading spaces, but the
    parse_source_files() expects to get lines with source files paths where
    the first space occurs after the file path.
    
    Fixes: 70f30cfe5b89 ("modpost: use read_text_file() and get_line() for reading text files")
    Signed-off-by: Radek Krejci <radek.krejci@oracle.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: check addrs list in userspace_pm_get_local_id [+ + +]
Author: Geliang Tang <geliang@kernel.org>
Date:   Thu Feb 8 19:03:53 2024 +0100

    mptcp: check addrs list in userspace_pm_get_local_id
    
    commit f012d796a6de662692159c539689e47e662853a8 upstream.
    
    Before adding a new entry in mptcp_userspace_pm_get_local_id(), it's
    better to check whether this address is already in userspace pm local
    address list. If it's in the list, no need to add a new entry, just
    return it's address ID and use this address.
    
    Fixes: 8b20137012d9 ("mptcp: read attributes of addr entries managed by userspace PMs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Geliang Tang <geliang.tang@linux.dev>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: drop the push_pending field [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 8 19:03:49 2024 +0100

    mptcp: drop the push_pending field
    
    commit bdd70eb68913c960acb895b00a8c62eb64715b1f upstream.
    
    Such field is there to avoid acquiring the data lock in a few spots,
    but it adds complexity to the already non trivial locking schema.
    
    All the relevant call sites (mptcp-level re-injection, set socket
    options), are slow-path, drop such field in favor of 'cb_flags', adding
    the relevant locking.
    
    This patch could be seen as an improvement, instead of a fix. But it
    simplifies the next patch. The 'Fixes' tag has been added to help having
    this series backported to stable.
    
    Fixes: e9d09baca676 ("mptcp: avoid atomic bit manipulation when possible")
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: fix data re-injection from stale subflow [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Wed Jan 31 22:49:46 2024 +0100

    mptcp: fix data re-injection from stale subflow
    
    commit b6c620dc43ccb4e802894e54b651cf81495e9598 upstream.
    
    When the MPTCP PM detects that a subflow is stale, all the packet
    scheduler must re-inject all the mptcp-level unacked data. To avoid
    acquiring unneeded locks, it first try to check if any unacked data
    is present at all in the RTX queue, but such check is currently
    broken, as it uses TCP-specific helper on an MPTCP socket.
    
    Funnily enough fuzzers and static checkers are happy, as the accessed
    memory still belongs to the mptcp_sock struct, and even from a
    functional perspective the recovery completed successfully, as
    the short-cut test always failed.
    
    A recent unrelated TCP change - commit d5fed5addb2b ("tcp: reorganize
    tcp_sock fast path variables") - exposed the issue, as the tcp field
    reorganization makes the mptcp code always skip the re-inection.
    
    Fix the issue dropping the bogus call: we are on a slow path, the early
    optimization proved once again to be evil.
    
    Fixes: 1e1d9d6f119c ("mptcp: handle pending data on closed subflow")
    Cc: stable@vger.kernel.org
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/468
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240131-upstream-net-20240131-mptcp-ci-issues-v1-1-4c1c11e571ff@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: get rid of msk->subflow [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Fri Aug 11 17:57:26 2023 +0200

    mptcp: get rid of msk->subflow
    
    commit 39880bd808ad2ddfb9b7fee129568c3b814f0609 upstream.
    
    This is a partial backport of the upstram commit 39880bd808ad ("mptcp:
    get rid of msk->subflow"). It's partial to avoid a long a complex
    dependency chain not suitable for stable.
    
    The only bit remaning from the original commit is the introduction of a
    new field avoid a race at close time causing an UaF:
    
    BUG: KASAN: use-after-free in mptcp_subflow_queue_clean+0x2c9/0x390 include/net/mptcp.h:104
    Read of size 1 at addr ffff88803bf72884 by task syz-executor.6/23092
    
    CPU: 0 PID: 23092 Comm: syz-executor.6 Not tainted 6.1.65-gc6114c845984 #50
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x125/0x18f lib/dump_stack.c:106
     print_report+0x163/0x4f0 mm/kasan/report.c:284
     kasan_report+0xc4/0x100 mm/kasan/report.c:495
     mptcp_subflow_queue_clean+0x2c9/0x390 include/net/mptcp.h:104
     mptcp_check_listen_stop+0x190/0x2a0 net/mptcp/protocol.c:3009
     __mptcp_close+0x9a/0x970 net/mptcp/protocol.c:3024
     mptcp_close+0x2a/0x130 net/mptcp/protocol.c:3089
     inet_release+0x13d/0x190 net/ipv4/af_inet.c:429
     sock_close+0xcf/0x230 net/socket.c:652
     __fput+0x3a2/0x870 fs/file_table.c:320
     task_work_run+0x24e/0x300 kernel/task_work.c:179
     resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
     exit_to_user_mode_loop+0xa4/0xc0 kernel/entry/common.c:171
     exit_to_user_mode_prepare+0x51/0x90 kernel/entry/common.c:204
     syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:286
     do_syscall_64+0x53/0xa0 arch/x86/entry/common.c:86
     entry_SYSCALL_64_after_hwframe+0x64/0xce
    RIP: 0033:0x41d791
    Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 74 2a 00 00 c3 48 83 ec 08 e8 9a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 e3 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
    RSP: 002b:00000000008bfb90 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
    RAX: 0000000000000000 RBX: 0000000000000004 RCX: 000000000041d791
    RDX: 0000001b33920000 RSI: ffffffff8139adff RDI: 0000000000000003
    RBP: 000000000079d980 R08: 0000001b33d20000 R09: 0000000000000951
    R10: 000000008139a955 R11: 0000000000000293 R12: 00000000000c739b
    R13: 000000000079bf8c R14: 00007fa301053000 R15: 00000000000c705a
     </TASK>
    
    Allocated by task 22528:
     kasan_save_stack mm/kasan/common.c:45 [inline]
     kasan_set_track+0x40/0x70 mm/kasan/common.c:52
     ____kasan_kmalloc mm/kasan/common.c:374 [inline]
     __kasan_kmalloc+0xa0/0xb0 mm/kasan/common.c:383
     kasan_kmalloc include/linux/kasan.h:211 [inline]
     __do_kmalloc_node mm/slab_common.c:955 [inline]
     __kmalloc+0xaa/0x1c0 mm/slab_common.c:968
     kmalloc include/linux/slab.h:558 [inline]
     sk_prot_alloc+0xac/0x200 net/core/sock.c:2038
     sk_clone_lock+0x56/0x1090 net/core/sock.c:2236
     inet_csk_clone_lock+0x26/0x420 net/ipv4/inet_connection_sock.c:1141
     tcp_create_openreq_child+0x30/0x1910 net/ipv4/tcp_minisocks.c:474
     tcp_v6_syn_recv_sock+0x413/0x1a90 net/ipv6/tcp_ipv6.c:1283
     subflow_syn_recv_sock+0x621/0x1300 net/mptcp/subflow.c:730
     tcp_get_cookie_sock+0xf0/0x5f0 net/ipv4/syncookies.c:201
     cookie_v6_check+0x130f/0x1c50 net/ipv6/syncookies.c:261
     tcp_v6_do_rcv+0x7e0/0x12b0 net/ipv6/tcp_ipv6.c:1147
     tcp_v6_rcv+0x2494/0x2f50 net/ipv6/tcp_ipv6.c:1743
     ip6_protocol_deliver_rcu+0xba3/0x1620 net/ipv6/ip6_input.c:438
     ip6_input+0x1bc/0x470 net/ipv6/ip6_input.c:483
     ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:302
     __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5525
     process_backlog+0x353/0x660 net/core/dev.c:5967
     __napi_poll+0xc6/0x5a0 net/core/dev.c:6534
     net_rx_action+0x652/0xea0 net/core/dev.c:6601
     __do_softirq+0x176/0x525 kernel/softirq.c:571
    
    Freed by task 23093:
     kasan_save_stack mm/kasan/common.c:45 [inline]
     kasan_set_track+0x40/0x70 mm/kasan/common.c:52
     kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:516
     ____kasan_slab_free+0x13a/0x1b0 mm/kasan/common.c:236
     kasan_slab_free include/linux/kasan.h:177 [inline]
     slab_free_hook mm/slub.c:1724 [inline]
     slab_free_freelist_hook mm/slub.c:1750 [inline]
     slab_free mm/slub.c:3661 [inline]
     __kmem_cache_free+0x1eb/0x340 mm/slub.c:3674
     sk_prot_free net/core/sock.c:2074 [inline]
     __sk_destruct+0x4ad/0x620 net/core/sock.c:2160
     tcp_v6_rcv+0x269c/0x2f50 net/ipv6/tcp_ipv6.c:1761
     ip6_protocol_deliver_rcu+0xba3/0x1620 net/ipv6/ip6_input.c:438
     ip6_input+0x1bc/0x470 net/ipv6/ip6_input.c:483
     ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:302
     __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5525
     process_backlog+0x353/0x660 net/core/dev.c:5967
     __napi_poll+0xc6/0x5a0 net/core/dev.c:6534
     net_rx_action+0x652/0xea0 net/core/dev.c:6601
     __do_softirq+0x176/0x525 kernel/softirq.c:571
    
    The buggy address belongs to the object at ffff88803bf72000
     which belongs to the cache kmalloc-4k of size 4096
    The buggy address is located 2180 bytes inside of
     4096-byte region [ffff88803bf72000, ffff88803bf73000)
    
    The buggy address belongs to the physical page:
    page:00000000a72e4e51 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3bf70
    head:00000000a72e4e51 order:3 compound_mapcount:0 compound_pincount:0
    flags: 0x100000000010200(slab|head|node=0|zone=1)
    raw: 0100000000010200 ffffea0000a0ea00 dead000000000002 ffff888100042140
    raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff88803bf72780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88803bf72800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff88803bf72880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
     ffff88803bf72900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88803bf72980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    
    Prevent the MPTCP worker from freeing the first subflow for unaccepted
    socket when such sockets transition to TCP_CLOSE state, and let that
    happen at accept() or listener close() time.
    
    Fixes: b6985b9b8295 ("mptcp: use the workqueue to destroy unaccepted sockets")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Reported-by: Christoph Paasch <cpaasch@apple.com>
    Tested-by: Christoph Paasch <cpaasch@apple.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: ethernet: ti: cpsw: enable mac_managed_pm to fix mdio [+ + +]
Author: Sinthu Raja <sinthu.raja@ti.com>
Date:   Tue Feb 6 06:29:28 2024 +0530

    net: ethernet: ti: cpsw: enable mac_managed_pm to fix mdio
    
    commit bc4ce46b1e3d1da4309405cd4afc7c0fcddd0b90 upstream.
    
    The below commit  introduced a WARN when phy state is not in the states:
    PHY_HALTED, PHY_READY and PHY_UP.
    commit 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
    
    When cpsw resumes, there have port in PHY_NOLINK state, so the below
    warning comes out. Set mac_managed_pm be true to tell mdio that the phy
    resume/suspend is managed by the mac, to fix the following warning:
    
    WARNING: CPU: 0 PID: 965 at drivers/net/phy/phy_device.c:326 mdio_bus_phy_resume+0x140/0x144
    CPU: 0 PID: 965 Comm: sh Tainted: G           O       6.1.46-g247b2535b2 #1
    Hardware name: Generic AM33XX (Flattened Device Tree)
     unwind_backtrace from show_stack+0x18/0x1c
     show_stack from dump_stack_lvl+0x24/0x2c
     dump_stack_lvl from __warn+0x84/0x15c
     __warn from warn_slowpath_fmt+0x1a8/0x1c8
     warn_slowpath_fmt from mdio_bus_phy_resume+0x140/0x144
     mdio_bus_phy_resume from dpm_run_callback+0x3c/0x140
     dpm_run_callback from device_resume+0xb8/0x2b8
     device_resume from dpm_resume+0x144/0x314
     dpm_resume from dpm_resume_end+0x14/0x20
     dpm_resume_end from suspend_devices_and_enter+0xd0/0x924
     suspend_devices_and_enter from pm_suspend+0x2e0/0x33c
     pm_suspend from state_store+0x74/0xd0
     state_store from kernfs_fop_write_iter+0x104/0x1ec
     kernfs_fop_write_iter from vfs_write+0x1b8/0x358
     vfs_write from ksys_write+0x78/0xf8
     ksys_write from ret_fast_syscall+0x0/0x54
    Exception stack(0xe094dfa8 to 0xe094dff0)
    dfa0:                   00000004 005c3fb8 00000001 005c3fb8 00000004 00000001
    dfc0: 00000004 005c3fb8 b6f6bba0 00000004 00000004 0059edb8 00000000 00000000
    dfe0: 00000004 bed918f0 b6f09bd3 b6e89a66
    
    Cc: <stable@vger.kernel.org> # v6.0+
    Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
    Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM")
    Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: ethernet: ti: cpsw_new: enable mac_managed_pm to fix mdio [+ + +]
Author: Sinthu Raja <sinthu.raja@ti.com>
Date:   Tue Feb 6 06:29:27 2024 +0530

    net: ethernet: ti: cpsw_new: enable mac_managed_pm to fix mdio
    
    commit 9def04e759caa5a3d741891037ae99f81e2fff01 upstream.
    
    The below commit  introduced a WARN when phy state is not in the states:
    PHY_HALTED, PHY_READY and PHY_UP.
    commit 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
    
    When cpsw_new resumes, there have port in PHY_NOLINK state, so the below
    warning comes out. Set mac_managed_pm be true to tell mdio that the phy
    resume/suspend is managed by the mac, to fix the following warning:
    
    WARNING: CPU: 0 PID: 965 at drivers/net/phy/phy_device.c:326 mdio_bus_phy_resume+0x140/0x144
    CPU: 0 PID: 965 Comm: sh Tainted: G           O       6.1.46-g247b2535b2 #1
    Hardware name: Generic AM33XX (Flattened Device Tree)
     unwind_backtrace from show_stack+0x18/0x1c
     show_stack from dump_stack_lvl+0x24/0x2c
     dump_stack_lvl from __warn+0x84/0x15c
     __warn from warn_slowpath_fmt+0x1a8/0x1c8
     warn_slowpath_fmt from mdio_bus_phy_resume+0x140/0x144
     mdio_bus_phy_resume from dpm_run_callback+0x3c/0x140
     dpm_run_callback from device_resume+0xb8/0x2b8
     device_resume from dpm_resume+0x144/0x314
     dpm_resume from dpm_resume_end+0x14/0x20
     dpm_resume_end from suspend_devices_and_enter+0xd0/0x924
     suspend_devices_and_enter from pm_suspend+0x2e0/0x33c
     pm_suspend from state_store+0x74/0xd0
     state_store from kernfs_fop_write_iter+0x104/0x1ec
     kernfs_fop_write_iter from vfs_write+0x1b8/0x358
     vfs_write from ksys_write+0x78/0xf8
     ksys_write from ret_fast_syscall+0x0/0x54
    Exception stack(0xe094dfa8 to 0xe094dff0)
    dfa0:                   00000004 005c3fb8 00000001 005c3fb8 00000004 00000001
    dfc0: 00000004 005c3fb8 b6f6bba0 00000004 00000004 0059edb8 00000000 00000000
    dfe0: 00000004 bed918f0 b6f09bd3 b6e89a66
    
    Cc: <stable@vger.kernel.org> # v6.0+
    Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
    Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM")
    Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame() [+ + +]
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Wed Jan 24 02:21:47 2024 -0800

    net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
    
    commit 37e8c97e539015637cb920d3e6f1e404f707a06e upstream.
    
    Syzkaller reported [1] hitting a warning after failing to allocate
    resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
    not help much in this case, it might be prudent to switch to
    netdev_warn_once(). At the very least it will suppress syzkaller
    reports such as [1].
    
    Just in case, use netdev_warn_once() in send_prp_supervision_frame()
    for similar reasons.
    
    [1]
    HSR: Could not send supervision frame
    WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
    RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
    ...
    Call Trace:
     <IRQ>
     hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
     call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
     expire_timers kernel/time/timer.c:1751 [inline]
     __run_timers+0x764/0xb20 kernel/time/timer.c:2022
     run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
     __do_softirq+0x21a/0x8de kernel/softirq.c:553
     invoke_softirq kernel/softirq.c:427 [inline]
     __irq_exit_rcu kernel/softirq.c:632 [inline]
     irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
     sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
     </IRQ>
     <TASK>
     asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
    ...
    
    This issue is also found in older kernels (at least up to 5.10).
    
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+3ae0a3f42c84074b7c8e@syzkaller.appspotmail.com
    Fixes: 121c33b07b31 ("net: hsr: introduce common code for skb initialization")
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: openvswitch: limit the number of recursions from action sets [+ + +]
Author: Aaron Conole <aconole@redhat.com>
Date:   Wed Feb 7 08:24:15 2024 -0500

    net: openvswitch: limit the number of recursions from action sets
    
    [ Upstream commit 6e2f90d31fe09f2b852de25125ca875aabd81367 ]
    
    The ovs module allows for some actions to recursively contain an action
    list for complex scenarios, such as sampling, checking lengths, etc.
    When these actions are copied into the internal flow table, they are
    evaluated to validate that such actions make sense, and these calls
    happen recursively.
    
    The ovs-vswitchd userspace won't emit more than 16 recursion levels
    deep.  However, the module has no such limit and will happily accept
    limits larger than 16 levels nested.  Prevent this by tracking the
    number of recursions happening and manually limiting it to 16 levels
    nested.
    
    The initial implementation of the sample action would track this depth
    and prevent more than 3 levels of recursion, but this was removed to
    support the clone use case, rather than limited at the current userspace
    limit.
    
    Fixes: 798c166173ff ("openvswitch: Optimize sample action for the clone use cases")
    Signed-off-by: Aaron Conole <aconole@redhat.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240207132416.1488485-2-aconole@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: prevent mss overflow in skb_segment() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Dec 12 16:46:21 2023 +0000

    net: prevent mss overflow in skb_segment()
    
    commit 23d05d563b7e7b0314e65c8e882bc27eac2da8e7 upstream.
    
    Once again syzbot is able to crash the kernel in skb_segment() [1]
    
    GSO_BY_FRAGS is a forbidden value, but unfortunately the following
    computation in skb_segment() can reach it quite easily :
    
            mss = mss * partial_segs;
    
    65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to
    a bad final result.
    
    Make sure to limit segmentation so that the new mss value is smaller
    than GSO_BY_FRAGS.
    
    [1]
    
    general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
    CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
    RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
    Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
    RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
    RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
    RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
    R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
    R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
    FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109
    ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120
    skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
    __skb_gso_segment+0x339/0x710 net/core/gso.c:124
    skb_gso_segment include/net/gso.h:83 [inline]
    validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626
    __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338
    dev_queue_xmit include/linux/netdevice.h:3134 [inline]
    packet_xmit+0x257/0x380 net/packet/af_packet.c:276
    packet_snd net/packet/af_packet.c:3087 [inline]
    packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119
    sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190
    __do_sys_sendto net/socket.c:2202 [inline]
    __se_sys_sendto net/socket.c:2198 [inline]
    __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x63/0x6b
    RIP: 0033:0x7f8692032aa9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9
    RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003
    RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480
    R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003
    </TASK>
    Modules linked in:
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
    Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
    RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
    RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
    RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
    R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
    R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
    FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    Fixes: 3953c46c3ac7 ("sk_buff: allow segmenting based on frag sizes")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20231212164621.4131800-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: stmmac: do not clear TBS enable bit on link up/down [+ + +]
Author: Esben Haabendal <esben@geanix.com>
Date:   Fri Jan 26 10:10:41 2024 +0100

    net: stmmac: do not clear TBS enable bit on link up/down
    
    commit 4896bb7c0b31a0a3379b290ea7729900c59e0c69 upstream.
    
    With the dma conf being reallocated on each call to stmmac_open(), any
    information in there is lost, unless we specifically handle it.
    
    The STMMAC_TBS_EN bit is set when adding an etf qdisc, and the etf qdisc
    therefore would stop working when link was set down and then back up.
    
    Fixes: ba39b344e924 ("net: ethernet: stmicro: stmmac: generate stmmac dma conf before open")
    Cc: stable@vger.kernel.org
    Signed-off-by: Esben Haabendal <esben@geanix.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: sysfs: Fix /sys/class/net/ path for statistics [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Fri Feb 9 01:55:18 2024 -0800

    net: sysfs: Fix /sys/class/net/<iface> path for statistics
    
    [ Upstream commit 5b3fbd61b9d1f4ed2db95aaf03f9adae0373784d ]
    
    The Documentation/ABI/testing/sysfs-class-net-statistics documentation
    is pointing to the wrong path for the interface.  Documentation is
    pointing to /sys/class/<iface>, instead of /sys/class/net/<iface>.
    
    Fix it by adding the `net/` directory before the interface.
    
    Fixes: 6044f9700645 ("net: sysfs: document /sys/class/net/statistics/*")
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: tls: factor out tls_*crypt_async_wait() [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Feb 6 17:18:18 2024 -0800

    net: tls: factor out tls_*crypt_async_wait()
    
    [ Upstream commit c57ca512f3b68ddcd62bda9cc24a8f5584ab01b1 ]
    
    Factor out waiting for async encrypt and decrypt to finish.
    There are already multiple copies and a subsequent fix will
    need more. No functional changes.
    
    Note that crypto_wait_req() returns wait->err
    
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: aec7961916f3 ("tls: fix race between async notify and socket close")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: tls: fix returned read length with async decrypt [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Feb 6 17:18:24 2024 -0800

    net: tls: fix returned read length with async decrypt
    
    [ Upstream commit ac437a51ce662364062f704e321227f6728e6adc ]
    
    We double count async, non-zc rx data. The previous fix was
    lucky because if we fully zc async_copy_bytes is 0 so we add 0.
    Decrypted already has all the bytes we handled, in all cases.
    We don't have to adjust anything, delete the erroneous line.
    
    Fixes: 4d42cd6bc2ac ("tls: rx: fix return value for async crypto")
    Co-developed-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: tls: fix use-after-free with partial reads and async decrypt [+ + +]
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Tue Feb 6 17:18:22 2024 -0800

    net: tls: fix use-after-free with partial reads and async decrypt
    
    [ Upstream commit 32b55c5ff9103b8508c1e04bfa5a08c64e7a925f ]
    
    tls_decrypt_sg doesn't take a reference on the pages from clear_skb,
    so the put_page() in tls_decrypt_done releases them, and we trigger
    a use-after-free in process_rx_list when we try to read from the
    partially-read skb.
    
    Fixes: fd31f3996af2 ("tls: rx: decrypt into a fresh skb")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: ipset: fix performance regression in swap operation [+ + +]
Author: Jozsef Kadlecsik <kadlec@netfilter.org>
Date:   Mon Jan 29 10:57:01 2024 +0100

    netfilter: ipset: fix performance regression in swap operation
    
    commit 97f7cf1cd80eeed3b7c808b7c12463295c751001 upstream.
    
    The patch "netfilter: ipset: fix race condition between swap/destroy
    and kernel side add/del/test", commit 28628fa9 fixes a race condition.
    But the synchronize_rcu() added to the swap function unnecessarily slows
    it down: it can safely be moved to destroy and use call_rcu() instead.
    
    Eric Dumazet pointed out that simply calling the destroy functions as
    rcu callback does not work: sets with timeout use garbage collectors
    which need cancelling at destroy which can wait. Therefore the destroy
    functions are split into two: cancelling garbage collectors safely at
    executing the command received by netlink and moving the remaining
    part only into the rcu callback.
    
    Link: https://lore.kernel.org/lkml/C0829B10-EAA6-4809-874E-E1E9C05A8D84@automattic.com/
    Fixes: 28628fa952fe ("netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test")
    Reported-by: Ale Crismani <ale.crismani@automattic.com>
    Reported-by: David Wang <00107082@163.com>
    Tested-by: David Wang <00107082@163.com>
    Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: ipset: Missing gc cancellations fixed [+ + +]
Author: Jozsef Kadlecsik <kadlec@netfilter.org>
Date:   Sun Feb 4 16:26:42 2024 +0100

    netfilter: ipset: Missing gc cancellations fixed
    
    commit 27c5a095e2518975e20a10102908ae8231699879 upstream.
    
    The patch fdb8e12cc2cc ("netfilter: ipset: fix performance regression
    in swap operation") missed to add the calls to gc cancellations
    at the error path of create operations and at module unload. Also,
    because the half of the destroy operations now executed by a
    function registered by call_rcu(), neither NFNL_SUBSYS_IPSET mutex
    or rcu read lock is held and therefore the checking of them results
    false warnings.
    
    Fixes: 97f7cf1cd80e ("netfilter: ipset: fix performance regression in swap operation")
    Reported-by: syzbot+52bbc0ad036f6f0d4a25@syzkaller.appspotmail.com
    Reported-by: Brad Spengler <spender@grsecurity.net>
    Reported-by: Стас Ничипорович <stasn77@gmail.com>
    Tested-by: Brad Spengler <spender@grsecurity.net>
    Tested-by: Стас Ничипорович <stasn77@gmail.com>
    Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfc: nci: free rx_data_reassembly skb on NCI device cleanup [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Thu Jan 25 12:53:09 2024 +0300

    nfc: nci: free rx_data_reassembly skb on NCI device cleanup
    
    commit bfb007aebe6bff451f7f3a4be19f4f286d0d5d9c upstream.
    
    rx_data_reassembly skb is stored during NCI data exchange for processing
    fragmented packets. It is dropped only when the last fragment is processed
    or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
    However, the NCI device may be deallocated before that which leads to skb
    leak.
    
    As by design the rx_data_reassembly skb is bound to the NCI device and
    nothing prevents the device to be freed before the skb is processed in
    some way and cleaned, free it on the NCI device cleanup.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation")
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+6b7c68d9c21e4ee4251b@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/lkml/000000000000f43987060043da7b@google.com/
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfp: flower: fix hardware offload for the transfer layer port [+ + +]
Author: Hui Zhou <hui.zhou@corigine.com>
Date:   Wed Jan 24 17:19:09 2024 +0200

    nfp: flower: fix hardware offload for the transfer layer port
    
    commit 3a007b8009b5f8af021021b7a590a6da0dc4c6e0 upstream.
    
    The nfp driver will merge the tp source port and tp destination port
    into one dword which the offset must be zero to do hardware offload.
    However, the mangle action for the tp source port and tp destination
    port is separated for tc ct action. Modify the mangle action for the
    FLOW_ACT_MANGLE_HDR_TYPE_TCP and FLOW_ACT_MANGLE_HDR_TYPE_UDP to
    satisfy the nfp driver offload check for the tp port.
    
    The mangle action provides a 4B value for source, and a 4B value for
    the destination, but only 2B of each contains the useful information.
    For offload the 2B of each is combined into a single 4B word. Since the
    incoming mask for the source is '0xFFFF<mask>' the shift-left will
    throw away the 0xFFFF part. When this gets combined together in the
    offload it will clear the destination field. Fix this by setting the
    lower bits back to 0xFFFF, effectively doing a rotate-left operation on
    the mask.
    
    Fixes: 5cee92c6f57a ("nfp: flower: support hw offload for ct nat action")
    CC: stable@vger.kernel.org # 6.1+
    Signed-off-by: Hui Zhou <hui.zhou@corigine.com>
    Signed-off-by: Louis Peens <louis.peens@corigine.com>
    Link: https://lore.kernel.org/r/20240124151909.31603-3-louis.peens@corigine.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfp: flower: prevent re-adding mac index for bonded port [+ + +]
Author: Daniel de Villiers <daniel.devilliers@corigine.com>
Date:   Fri Feb 2 13:37:18 2024 +0200

    nfp: flower: prevent re-adding mac index for bonded port
    
    commit 1a1c13303ff6d64e6f718dc8aa614e580ca8d9b4 upstream.
    
    When physical ports are reset (either through link failure or manually
    toggled down and up again) that are slaved to a Linux bond with a tunnel
    endpoint IP address on the bond device, not all tunnel packets arriving
    on the bond port are decapped as expected.
    
    The bond dev assigns the same MAC address to itself and each of its
    slaves. When toggling a slave device, the same MAC address is therefore
    offloaded to the NFP multiple times with different indexes.
    
    The issue only occurs when re-adding the shared mac. The
    nfp_tunnel_add_shared_mac() function has a conditional check early on
    that checks if a mac entry already exists and if that mac entry is
    global: (entry && nfp_tunnel_is_mac_idx_global(entry->index)). In the
    case of a bonded device (For example br-ex), the mac index is obtained,
    and no new index is assigned.
    
    We therefore modify the conditional in nfp_tunnel_add_shared_mac() to
    check if the port belongs to the LAG along with the existing checks to
    prevent a new global mac index from being re-assigned to the slave port.
    
    Fixes: 20cce8865098 ("nfp: flower: enable MAC address sharing for offloadable devs")
    CC: stable@vger.kernel.org # 5.1+
    Signed-off-by: Daniel de Villiers <daniel.devilliers@corigine.com>
    Signed-off-by: Louis Peens <louis.peens@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfp: use correct macro for LengthSelect in BAR config [+ + +]
Author: Daniel Basilio <daniel.basilio@corigine.com>
Date:   Fri Feb 2 13:37:17 2024 +0200

    nfp: use correct macro for LengthSelect in BAR config
    
    commit b3d4f7f2288901ed2392695919b3c0e24c1b4084 upstream.
    
    The 1st and 2nd expansion BAR configuration registers are configured,
    when the driver starts up, in variables 'barcfg_msix_general' and
    'barcfg_msix_xpb', respectively. The 'LengthSelect' field is ORed in
    from bit 0, which is incorrect. The 'LengthSelect' field should
    start from bit 27.
    
    This has largely gone un-noticed because
    NFP_PCIE_BAR_PCIE2CPP_LengthSelect_32BIT happens to be 0.
    
    Fixes: 4cb584e0ee7d ("nfp: add CPP access core")
    Cc: stable@vger.kernel.org # 4.11+
    Signed-off-by: Daniel Basilio <daniel.basilio@corigine.com>
    Signed-off-by: Louis Peens <louis.peens@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfsd: don't take fi_lock in nfsd_break_deleg_cb() [+ + +]
Author: NeilBrown <neilb@suse.de>
Date:   Mon Feb 5 13:22:39 2024 +1100

    nfsd: don't take fi_lock in nfsd_break_deleg_cb()
    
    [ Upstream commit 5ea9a7c5fe4149f165f0e3b624fe08df02b6c301 ]
    
    A recent change to check_for_locks() changed it to take ->flc_lock while
    holding ->fi_lock.  This creates a lock inversion (reported by lockdep)
    because there is a case where ->fi_lock is taken while holding
    ->flc_lock.
    
    ->flc_lock is held across ->fl_lmops callbacks, and
    nfsd_break_deleg_cb() is one of those and does take ->fi_lock.  However
    it doesn't need to.
    
    Prior to v4.17-rc1~110^2~22 ("nfsd: create a separate lease for each
    delegation") nfsd_break_deleg_cb() would walk the ->fi_delegations list
    and so needed the lock.  Since then it doesn't walk the list and doesn't
    need the lock.
    
    Two actions are performed under the lock.  One is to call
    nfsd_break_one_deleg which calls nfsd4_run_cb().  These doesn't act on
    the nfs4_file at all, so don't need the lock.
    
    The other is to set ->fi_had_conflict which is in the nfs4_file.
    This field is only ever set here (except when initialised to false)
    so there is no possible problem will multiple threads racing when
    setting it.
    
    The field is tested twice in nfs4_set_delegation().  The first test does
    not hold a lock and is documented as an opportunistic optimisation, so
    it doesn't impose any need to hold ->fi_lock while setting
    ->fi_had_conflict.
    
    The second test in nfs4_set_delegation() *is* make under ->fi_lock, so
    removing the locking when ->fi_had_conflict is set could make a change.
    The change could only be interesting if ->fi_had_conflict tested as
    false even though nfsd_break_one_deleg() ran before ->fi_lock was
    unlocked.  i.e. while hash_delegation_locked() was running.
    As hash_delegation_lock() doesn't interact in any way with nfs4_run_cb()
    there can be no importance to this interaction.
    
    So this patch removes the locking from nfsd_break_one_deleg() and moves
    the final test on ->fi_had_conflict out of the locked region to make it
    clear that locking isn't important to the test.  It is still tested
    *after* vfs_setlease() has succeeded.  This might be significant and as
    vfs_setlease() takes ->flc_lock, and nfsd_break_one_deleg() is called
    under ->flc_lock this "after" is a true ordering provided by a spinlock.
    
    Fixes: edcf9725150e ("nfsd: fix RELEASE_LOCKOWNER")
    Signed-off-by: NeilBrown <neilb@suse.de>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfsd: fix RELEASE_LOCKOWNER [+ + +]
Author: NeilBrown <neilb@suse.de>
Date:   Mon Jan 22 14:58:16 2024 +1100

    nfsd: fix RELEASE_LOCKOWNER
    
    [ Upstream commit edcf9725150e42beeca42d085149f4c88fa97afd ]
    
    The test on so_count in nfsd4_release_lockowner() is nonsense and
    harmful.  Revert to using check_for_locks(), changing that to not sleep.
    
    First: harmful.
    As is documented in the kdoc comment for nfsd4_release_lockowner(), the
    test on so_count can transiently return a false positive resulting in a
    return of NFS4ERR_LOCKS_HELD when in fact no locks are held.  This is
    clearly a protocol violation and with the Linux NFS client it can cause
    incorrect behaviour.
    
    If RELEASE_LOCKOWNER is sent while some other thread is still
    processing a LOCK request which failed because, at the time that request
    was received, the given owner held a conflicting lock, then the nfsd
    thread processing that LOCK request can hold a reference (conflock) to
    the lock owner that causes nfsd4_release_lockowner() to return an
    incorrect error.
    
    The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it
    never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so
    it knows that the error is impossible.  It assumes the lock owner was in
    fact released so it feels free to use the same lock owner identifier in
    some later locking request.
    
    When it does reuse a lock owner identifier for which a previous RELEASE
    failed, it will naturally use a lock_seqid of zero.  However the server,
    which didn't release the lock owner, will expect a larger lock_seqid and
    so will respond with NFS4ERR_BAD_SEQID.
    
    So clearly it is harmful to allow a false positive, which testing
    so_count allows.
    
    The test is nonsense because ... well... it doesn't mean anything.
    
    so_count is the sum of three different counts.
    1/ the set of states listed on so_stateids
    2/ the set of active vfs locks owned by any of those states
    3/ various transient counts such as for conflicting locks.
    
    When it is tested against '2' it is clear that one of these is the
    transient reference obtained by find_lockowner_str_locked().  It is not
    clear what the other one is expected to be.
    
    In practice, the count is often 2 because there is precisely one state
    on so_stateids.  If there were more, this would fail.
    
    In my testing I see two circumstances when RELEASE_LOCKOWNER is called.
    In one case, CLOSE is called before RELEASE_LOCKOWNER.  That results in
    all the lock states being removed, and so the lockowner being discarded
    (it is removed when there are no more references which usually happens
    when the lock state is discarded).  When nfsd4_release_lockowner() finds
    that the lock owner doesn't exist, it returns success.
    
    The other case shows an so_count of '2' and precisely one state listed
    in so_stateid.  It appears that the Linux client uses a separate lock
    owner for each file resulting in one lock state per lock owner, so this
    test on '2' is safe.  For another client it might not be safe.
    
    So this patch changes check_for_locks() to use the (newish)
    find_any_file_locked() so that it doesn't take a reference on the
    nfs4_file and so never calls nfsd_file_put(), and so never sleeps.  With
    this check is it safe to restore the use of check_for_locks() rather
    than testing so_count against the mysterious '2'.
    
    Fixes: ce3c4ad7f4ce ("NFSD: Fix possible sleep during nfsd4_release_lockowner()")
    Signed-off-by: NeilBrown <neilb@suse.de>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Cc: stable@vger.kernel.org # v6.2+
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nilfs2: fix data corruption in dsync block recovery for small block sizes [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed Jan 24 21:19:36 2024 +0900

    nilfs2: fix data corruption in dsync block recovery for small block sizes
    
    commit 67b8bcbaed4777871bb0dcc888fb02a614a98ab1 upstream.
    
    The helper function nilfs_recovery_copy_block() of
    nilfs_recovery_dsync_blocks(), which recovers data from logs created by
    data sync writes during a mount after an unclean shutdown, incorrectly
    calculates the on-page offset when copying repair data to the file's page
    cache.  In environments where the block size is smaller than the page
    size, this flaw can cause data corruption and leak uninitialized memory
    bytes during the recovery process.
    
    Fix these issues by correcting this byte offset calculation on the page.
    
    Link: https://lkml.kernel.org/r/20240124121936.10575-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed Jan 31 23:56:57 2024 +0900

    nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
    
    commit 38296afe3c6ee07319e01bb249aa4bb47c07b534 upstream.
    
    Syzbot reported a hang issue in migrate_pages_batch() called by mbind()
    and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
    
    While migrate_pages_batch() locks a folio and waits for the writeback to
    complete, the log writer thread that should bring the writeback to
    completion picks up the folio being written back in
    nilfs_lookup_dirty_data_buffers() that it calls for subsequent log
    creation and was trying to lock the folio.  Thus causing a deadlock.
    
    In the first place, it is unexpected that folios/pages in the middle of
    writeback will be updated and become dirty.  Nilfs2 adds a checksum to
    verify the validity of the log being written and uses it for recovery at
    mount, so data changes during writeback are suppressed.  Since this is
    broken, an unclean shutdown could potentially cause recovery to fail.
    
    Investigation revealed that the root cause is that the wait for writeback
    completion in nilfs_page_mkwrite() is conditional, and if the backing
    device does not require stable writes, data may be modified without
    waiting.
    
    Fix these issues by making nilfs_page_mkwrite() wait for writeback to
    finish regardless of the stable write requirement of the backing device.
    
    Link: https://lkml.kernel.org/r/20240131145657.4209-1-konishi.ryusuke@gmail.com
    Fixes: 1d1d1a767206 ("mm: only enforce stable page writes if the backing device requires it")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+ee2ae68da3b22d04cd8d@syzkaller.appspotmail.com
    Closes: https://lkml.kernel.org/r/00000000000047d819061004ad6c@google.com
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: fix potential bug in end_buffer_async_write [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sun Feb 4 01:16:45 2024 +0900

    nilfs2: fix potential bug in end_buffer_async_write
    
    commit 5bc09b397cbf1221f8a8aacb1152650c9195b02b upstream.
    
    According to a syzbot report, end_buffer_async_write(), which handles the
    completion of block device writes, may detect abnormal condition of the
    buffer async_write flag and cause a BUG_ON failure when using nilfs2.
    
    Nilfs2 itself does not use end_buffer_async_write().  But, the async_write
    flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue
    with race condition of competition between segments for dirty blocks") as
    a means of resolving double list insertion of dirty blocks in
    nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the
    resulting crash.
    
    This modification is safe as long as it is used for file data and b-tree
    node blocks where the page caches are independent.  However, it was
    irrelevant and redundant to also introduce async_write for segment summary
    and super root blocks that share buffers with the backing device.  This
    led to the possibility that the BUG_ON check in end_buffer_async_write
    would fail as described above, if independent writebacks of the backing
    device occurred in parallel.
    
    The use of async_write for segment summary buffers has already been
    removed in a previous change.
    
    Fix this issue by removing the manipulation of the async_write flag for
    the remaining super root block buffer.
    
    Link: https://lkml.kernel.org/r/20240203161645.4992-1-konishi.ryusuke@gmail.com
    Fixes: 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+5c04210f7c7f897c1e7f@syzkaller.appspotmail.com
    Closes: https://lkml.kernel.org/r/00000000000019a97c05fd42f8c8@google.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: replace WARN_ONs for invalid DAT metadata block requests [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Fri Jan 27 01:41:14 2023 +0900

    nilfs2: replace WARN_ONs for invalid DAT metadata block requests
    
    commit 5124a0a549857c4b87173280e192eea24dea72ad upstream.
    
    If DAT metadata file block access fails due to corruption of the DAT file
    or abnormal virtual block numbers held by b-trees or inodes, a kernel
    warning is generated.
    
    This replaces the WARN_ONs by error output, so that a kernel, booted with
    panic_on_warn, does not panic.  This patch also replaces the detected
    return code -ENOENT with another internal code -EINVAL to notify the bmap
    layer of metadata corruption.  When the bmap layer sees -EINVAL, it
    handles the abnormal situation with nilfs_bmap_convert_error() and finally
    returns code -EIO as it should.
    
    Link: https://lkml.kernel.org/r/0000000000005cc3d205ea23ddcf@google.com
    Link: https://lkml.kernel.org/r/20230126164114.6911-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: <syzbot+5d5d25f90f195a3cfcb4@syzkaller.appspotmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nouveau/svm: fix kvcalloc() argument order [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Feb 12 12:22:17 2024 +0100

    nouveau/svm: fix kvcalloc() argument order
    
    [ Upstream commit 2c80a2b715df75881359d07dbaacff8ad411f40e ]
    
    The conversion to kvcalloc() mixed up the object size and count
    arguments, causing a warning:
    
    drivers/gpu/drm/nouveau/nouveau_svm.c: In function 'nouveau_svm_fault_buffer_ctor':
    drivers/gpu/drm/nouveau/nouveau_svm.c:1010:40: error: 'kvcalloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
     1010 |         buffer->fault = kvcalloc(sizeof(*buffer->fault), buffer->entries, GFP_KERNEL);
          |                                        ^
    drivers/gpu/drm/nouveau/nouveau_svm.c:1010:40: note: earlier argument should specify number of elements, later size of each element
    
    The behavior is still correct aside from the warning, but fixing it avoids
    the warnings and can help the compiler track the individual objects better.
    
    Fixes: 71e4bbca070e ("nouveau/svm: Use kvcalloc() instead of kvzalloc()")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240212112230.1117284-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
of: property: Add in-ports/out-ports support to of_graph_get_port_parent() [+ + +]
Author: Saravana Kannan <saravanak@google.com>
Date:   Tue Feb 6 17:18:02 2024 -0800

    of: property: Add in-ports/out-ports support to of_graph_get_port_parent()
    
    commit 8f1e0d791b5281f3a38620bc7c57763dc551be15 upstream.
    
    Similar to the existing "ports" node name, coresight device tree bindings
    have added "in-ports" and "out-ports" as standard node names for a
    collection of ports.
    
    Add support for these name to of_graph_get_port_parent() so that
    remote-endpoint parsing can find the correct parent node for these
    coresight ports too.
    
    Signed-off-by: Saravana Kannan <saravanak@google.com>
    Link: https://lore.kernel.org/r/20240207011803.2637531-4-saravanak@google.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

of: property: fix typo in io-channels [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Tue Jan 23 16:14:22 2024 +0100

    of: property: fix typo in io-channels
    
    commit 8f7e917907385e112a845d668ae2832f41e64bf5 upstream.
    
    The property is io-channels and not io-channel. This was effectively
    preventing the devlink creation.
    
    Fixes: 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Reviewed-by: Saravana Kannan <saravanak@google.com>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/20240123-iio-backend-v7-1-1bff236b8693@analog.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

of: property: Improve finding the supplier of a remote-endpoint property [+ + +]
Author: Saravana Kannan <saravanak@google.com>
Date:   Tue Feb 6 17:18:01 2024 -0800

    of: property: Improve finding the supplier of a remote-endpoint property
    
    [ Upstream commit 782bfd03c3ae2c0e6e01b661b8e18f1de50357be ]
    
    After commit 4a032827daa8 ("of: property: Simplify of_link_to_phandle()"),
    remote-endpoint properties created a fwnode link from the consumer device
    to the supplier endpoint. This is a tiny bit inefficient (not buggy) when
    trying to create device links or detecting cycles. So, improve this the
    same way we improved finding the consumer of a remote-endpoint property.
    
    Fixes: 4a032827daa8 ("of: property: Simplify of_link_to_phandle()")
    Signed-off-by: Saravana Kannan <saravanak@google.com>
    Link: https://lore.kernel.org/r/20240207011803.2637531-3-saravanak@google.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

of: unittest: Fix compile in the non-dynamic case [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Mon Jan 29 20:25:56 2024 +0100

    of: unittest: Fix compile in the non-dynamic case
    
    [ Upstream commit 607aad1e4356c210dbef9022955a3089377909b2 ]
    
    If CONFIG_OF_KOBJ is not set, a device_node does not contain a
    kobj and attempts to access the embedded kobj via kref_read break
    the compile.
    
    Replace affected kref_read calls with a macro that reads the
    refcount if it exists and returns 1 if there is no embedded kobj.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202401291740.VP219WIz-lkp@intel.com/
    Fixes: 4dde83569832 ("of: Fix double free in of_parse_phandle_with_args_map")
    Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
    Link: https://lore.kernel.org/r/20240129192556.403271-1-lk@c--e.de
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
parisc: Fix random data corruption from exception handler [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Sat Jan 20 15:29:27 2024 +0100

    parisc: Fix random data corruption from exception handler
    
    commit 8b1d72395635af45410b66cc4c4ab37a12c4a831 upstream.
    
    The current exception handler implementation, which assists when accessing
    user space memory, may exhibit random data corruption if the compiler decides
    to use a different register than the specified register %r29 (defined in
    ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another
    register, the fault handler will nevertheless store -EFAULT into %r29 and thus
    trash whatever this register is used for.
    Looking at the assembly I found that this happens sometimes in emulate_ldd().
    
    To solve the issue, the easiest solution would be if it somehow is
    possible to tell the fault handler which register is used to hold the error
    code. Using %0 or %1 in the inline assembly is not posssible as it will show
    up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not
    convert to an integer.
    
    This patch takes another, better and more flexible approach:
    We extend the __ex_table (which is out of the execution path) by one 32-word.
    In this word we tell the compiler to insert the assembler instruction
    "or %r0,%r0,%reg", where %reg references the register which the compiler
    choosed for the error return code.
    In case of an access failure, the fault handler finds the __ex_table entry and
    can examine the opcode. The used register is encoded in the lowest 5 bits, and
    the fault handler can then store -EFAULT into this register.
    
    Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT
    config option any longer.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: <stable@vger.kernel.org> # v6.0+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parisc: Prevent hung tasks when printing inventory on serial console [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Fri Jan 19 21:16:39 2024 +0100

    parisc: Prevent hung tasks when printing inventory on serial console
    
    commit c8708d758e715c3824a73bf0cda97292b52be44d upstream.
    
    Printing the inventory on a serial console can be quite slow and thus may
    trigger the hung task detector (CONFIG_DETECT_HUNG_TASK=y) and possibly
    reboot the machine. Adding a cond_resched() prevents this.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: <stable@vger.kernel.org> # v6.0+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pmdomain: core: Move the unused cleanup to a _sync initcall [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Dec 27 16:21:24 2023 +0100

    pmdomain: core: Move the unused cleanup to a _sync initcall
    
    commit 741ba0134fa7822fcf4e4a0a537a5c4cfd706b20 upstream.
    
    The unused clock cleanup uses the _sync initcall to give all users at
    earlier initcalls time to probe. Do the same to avoid leaving some PDs
    dangling at "on" (which actually happened on qcom!).
    
    Fixes: 2fe71dcdfd10 ("PM / domains: Add late_initcall to disable unused PM domains")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231227-topic-pmdomain_sync_cleanup-v1-1-5f36769d538b@linaro.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/64: Set task pt_regs->link to the LR value on scv entry [+ + +]
Author: Naveen N Rao <naveen@kernel.org>
Date:   Fri Feb 2 21:13:16 2024 +0530

    powerpc/64: Set task pt_regs->link to the LR value on scv entry
    
    commit aad98efd0b121f63a2e1c221dcb4d4850128c697 upstream.
    
    Nysal reported that userspace backtraces are missing in offcputime bcc
    tool. As an example:
        $ sudo ./bcc/tools/offcputime.py -uU
        Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end.
    
        ^C
            write
            -                python (9107)
                8
    
            write
            -                sudo (9105)
                9
    
            mmap
            -                python (9107)
                16
    
            clock_nanosleep
            -                multipathd (697)
                3001604
    
    The offcputime bcc tool attaches a bpf program to a kprobe on
    finish_task_switch(), which is usually hit on a syscall from userspace.
    With the switch to system call vectored, we started setting
    pt_regs->link to zero. This is because system call vectored behaves like
    a function call with LR pointing to the system call return address, and
    with no modification to SRR0/SRR1. The LR value does indicate our next
    instruction, so it is being saved as pt_regs->nip, and pt_regs->link is
    being set to zero. This is not a problem by itself, but BPF uses perf
    callchain infrastructure for capturing stack traces, and that stores LR
    as the second entry in the stack trace. perf has code to cope with the
    second entry being zero, and skips over it. However, generic userspace
    unwinders assume that a zero entry indicates end of the stack trace,
    resulting in a truncated userspace stack trace.
    
    Rather than fixing all userspace unwinders to ignore/skip past the
    second entry, store the real LR value in pt_regs->link so that there
    continues to be a valid, though duplicate entry in the stack trace.
    
    With this change:
        $ sudo ./bcc/tools/offcputime.py -uU
        Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end.
    
        ^C
            write
            write
            [unknown]
            [unknown]
            [unknown]
            [unknown]
            [unknown]
            PyObject_VectorcallMethod
            [unknown]
            [unknown]
            PyObject_CallOneArg
            PyFile_WriteObject
            PyFile_WriteString
            [unknown]
            [unknown]
            PyObject_Vectorcall
            _PyEval_EvalFrameDefault
            PyEval_EvalCode
            [unknown]
            [unknown]
            [unknown]
            _PyRun_SimpleFileObject
            _PyRun_AnyFileObject
            Py_RunMain
            [unknown]
            Py_BytesMain
            [unknown]
            __libc_start_main
            -                python (1293)
                7
    
            write
            write
            [unknown]
            sudo_ev_loop_v1
            sudo_ev_dispatch_v1
            [unknown]
            [unknown]
            [unknown]
            [unknown]
            __libc_start_main
            -                sudo (1291)
                7
    
            syscall
            syscall
            bpf_open_perf_buffer_opts
            [unknown]
            [unknown]
            [unknown]
            [unknown]
            _PyObject_MakeTpCall
            PyObject_Vectorcall
            _PyEval_EvalFrameDefault
            PyEval_EvalCode
            [unknown]
            [unknown]
            [unknown]
            _PyRun_SimpleFileObject
            _PyRun_AnyFileObject
            Py_RunMain
            [unknown]
            Py_BytesMain
            [unknown]
            __libc_start_main
            -                python (1293)
                11
    
            clock_nanosleep
            clock_nanosleep
            nanosleep
            sleep
            [unknown]
            [unknown]
            __clone
            -                multipathd (698)
                3001661
    
    Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions")
    Cc: stable@vger.kernel.org
    Reported-by: "Nysal Jan K.A" <nysal@linux.ibm.com>
    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240202154316.395276-1-naveen@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/cputable: Add missing PPC_FEATURE_BOOKE on PPC64 Book-E [+ + +]
Author: David Engraf <david.engraf@sysgo.com>
Date:   Wed Feb 7 10:27:58 2024 +0100

    powerpc/cputable: Add missing PPC_FEATURE_BOOKE on PPC64 Book-E
    
    commit eb6d871f4ba49ac8d0537e051fe983a3a4027f61 upstream.
    
    Commit e320a76db4b0 ("powerpc/cputable: Split cpu_specs[] out of
    cputable.h") moved the cpu_specs to separate header files. Previously
    PPC_FEATURE_BOOKE was enabled by CONFIG_PPC_BOOK3E_64. The definition in
    cpu_specs_e500mc.h for PPC64 no longer enables PPC_FEATURE_BOOKE.
    
    This breaks user space reading the ELF hwcaps and expect
    PPC_FEATURE_BOOKE. Debugging an application with gdb is no longer
    working on e5500/e6500 because the 64-bit detection relies on
    PPC_FEATURE_BOOKE for Book-E.
    
    Fixes: e320a76db4b0 ("powerpc/cputable: Split cpu_specs[] out of cputable.h")
    Cc: stable@vger.kernel.org # v6.1+
    Signed-off-by: David Engraf <david.engraf@sysgo.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240207092758.1058893-1-david.engraf@sysgo.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/kasan: Fix addr error caused by page alignment [+ + +]
Author: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Date:   Tue Jan 23 09:45:59 2024 +0800

    powerpc/kasan: Fix addr error caused by page alignment
    
    [ Upstream commit 4a7aee96200ad281a5cc4cf5c7a2e2a49d2b97b0 ]
    
    In kasan_init_region, when k_start is not page aligned, at the begin of
    for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then
    `va = block + k_cur - k_start` is less than block, the addr va is invalid,
    because the memory address space from va to block is not alloced by
    memblock_alloc, which will not be reserved by memblock_reserve later, it
    will be used by other places.
    
    As a result, memory overwriting occurs.
    
    for example:
    int __init __weak kasan_init_region(void *start, size_t size)
    {
    [...]
            /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */
            block = memblock_alloc(k_end - k_start, PAGE_SIZE);
            [...]
            for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) {
                    /* at the begin of for loop
                     * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)
                     * va(dcd96c00) is less than block(dcd97000), va is invalid
                     */
                    void *va = block + k_cur - k_start;
                    [...]
            }
    [...]
    }
    
    Therefore, page alignment is performed on k_start before
    memblock_alloc() to ensure the validity of the VA address.
    
    Fixes: 663c0c9496a6 ("powerpc/kasan: Fix shadow area set up for modules.")
    Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/1705974359-43790-1-git-send-email-xiaojiangfeng@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/kasan: Limit KASAN thread size increase to 32KB [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Mon Feb 12 17:42:44 2024 +1100

    powerpc/kasan: Limit KASAN thread size increase to 32KB
    
    [ Upstream commit f1acb109505d983779bbb7e20a1ee6244d2b5736 ]
    
    KASAN is seen to increase stack usage, to the point that it was reported
    to lead to stack overflow on some 32-bit machines (see link).
    
    To avoid overflows the stack size was doubled for KASAN builds in
    commit 3e8635fb2e07 ("powerpc/kasan: Force thread size increase with
    KASAN").
    
    However with a 32KB stack size to begin with, the doubling leads to a
    64KB stack, which causes build errors:
      arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff)
    
    Although the asm could be reworked, in practice a 32KB stack seems
    sufficient even for KASAN builds - the additional usage seems to be in
    the 2-3KB range for a 64-bit KASAN build.
    
    So only increase the stack for KASAN if the stack size is < 32KB.
    
    Fixes: 18f14afe2816 ("powerpc/64s: Increase default stack size to 32KB")
    Reported-by: Spoorthy <spoorthy@linux.ibm.com>
    Reported-by: Benjamin Gray <bgray@linux.ibm.com>
    Reviewed-by: Benjamin Gray <bgray@linux.ibm.com>
    Link: https://lore.kernel.org/linuxppc-dev/bug-207129-206035@https.bugzilla.kernel.org%2F/
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240212064244.3924505-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pseries: fix accuracy of stolen time [+ + +]
Author: Shrikanth Hegde <sshegde@linux.ibm.com>
Date:   Tue Feb 13 10:56:35 2024 +0530

    powerpc/pseries: fix accuracy of stolen time
    
    commit cbecc9fcbbec60136b0180ba0609c829afed5c81 upstream.
    
    powerVM hypervisor updates the VPA fields with stolen time data.
    It currently reports enqueue_dispatch_tb and ready_enqueue_tb for
    this purpose. In linux these two fields are used to report the stolen time.
    
    The VPA fields are updated at the TB frequency. On powerPC its mostly
    set at 512Mhz. Hence this needs a conversion to ns when reporting it
    back as rest of the kernel timings are in ns. This conversion is already
    handled in tb_to_ns function. So use that function to report accurate
    stolen time.
    
    Observed this issue and used an Capped Shared Processor LPAR(SPLPAR) to
    simplify the experiments. In all these cases, 100% VP Load is run using
    stress-ng workload. Values of stolen time is in percentages as reported
    by mpstat. With the patch values are close to expected.
    
                    6.8.rc1         +Patch
    12EC/12VP          0.0             0.0
    12EC/24VP         25.7            50.2
    12EC/36VP         37.3            69.2
    12EC/48VP         38.5            78.3
    
    Fixes: 0e8a63132800 ("powerpc/pseries: Implement CONFIG_PARAVIRT_TIME_ACCOUNTING")
    Cc: stable@vger.kernel.org # v6.1+
    Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240213052635.231597-1-sshegde@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RDMA/irdma: Ensure iWarp QP queue memory is OS paged aligned [+ + +]
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Wed Nov 29 14:21:42 2023 -0600

    RDMA/irdma: Ensure iWarp QP queue memory is OS paged aligned
    
    commit 0a5ec366de7e94192669ba08de6ed336607fd282 upstream.
    
    The SQ is shared for between kernel and used by storing the kernel page
    pointer and passing that to a kmap_atomic().
    
    This then requires that the alignment is PAGE_SIZE aligned.
    
    Fix by adding an iWarp specific alignment check.
    
    Fixes: e965ef0e7b2c ("RDMA/irdma: Split QP handler into irdma_reg_user_mr_type_qp")
    Link: https://lore.kernel.org/r/20231129202143.1434-3-shiraz.saleem@intel.com
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "drm/amd: flush any delayed gfxoff on suspend entry" [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed Feb 7 23:52:54 2024 -0600

    Revert "drm/amd: flush any delayed gfxoff on suspend entry"
    
    commit 916361685319098f696b798ef1560f69ed96e934 upstream.
    
    commit ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring
    callbacks") caused GFXOFF control to be used more heavily and the
    codepath that was removed from commit 0dee72639533 ("drm/amd: flush any
    delayed gfxoff on suspend entry") now can be exercised at suspend again.
    
    Users report that by using GNOME to suspend the lockscreen trigger will
    cause SDMA traffic and the system can deadlock.
    
    This reverts commit 0dee726395333fea833eaaf838bc80962df886c8.
    
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Fixes: ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring callbacks")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ring-buffer: Clean ring_buffer_poll_wait() error return [+ + +]
Author: Vincent Donnefort <vdonnefort@google.com>
Date:   Wed Jan 31 14:09:55 2024 +0000

    ring-buffer: Clean ring_buffer_poll_wait() error return
    
    commit 66bbea9ed6446b8471d365a22734dc00556c4785 upstream.
    
    The return type for ring_buffer_poll_wait() is __poll_t. This is behind
    the scenes an unsigned where we can set event bits. In case of a
    non-allocated CPU, we do return instead -EINVAL (0xffffffea). Lucky us,
    this ends up setting few error bits (EPOLLERR | EPOLLHUP | EPOLLNVAL), so
    user-space at least is aware something went wrong.
    
    Nonetheless, this is an incorrect code. Replace that -EINVAL with a
    proper EPOLLERR to clean that output. As this doesn't change the
    behaviour, there's no need to treat this change as a bug fix.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240131140955.3322792-1-vdonnefort@google.com
    
    Cc: stable@vger.kernel.org
    Fixes: 6721cb6002262 ("ring-buffer: Do not poll non allocated cpu buffers")
    Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/qeth: Fix potential loss of L3-IP@ in case of network issues [+ + +]
Author: Alexandra Winter <wintera@linux.ibm.com>
Date:   Tue Feb 6 09:58:49 2024 +0100

    s390/qeth: Fix potential loss of L3-IP@ in case of network issues
    
    commit 2fe8a236436fe40d8d26a1af8d150fc80f04ee1a upstream.
    
    Symptom:
    In case of a bad cable connection (e.g. dirty optics) a fast sequence of
    network DOWN-UP-DOWN-UP could happen. UP triggers recovery of the qeth
    interface. In case of a second DOWN while recovery is still ongoing, it
    can happen that the IP@ of a Layer3 qeth interface is lost and will not
    be recovered by the second UP.
    
    Problem:
    When registration of IP addresses with Layer 3 qeth devices fails, (e.g.
    because of bad address format) the respective IP address is deleted from
    its hash-table in the driver. If registration fails because of a ENETDOWN
    condition, the address should stay in the hashtable, so a subsequent
    recovery can restore it.
    
    3caa4af834df ("qeth: keep ip-address after LAN_OFFLINE failure")
    fixes this for registration failures during normal operation, but not
    during recovery.
    
    Solution:
    Keep L3-IP address in case of ENETDOWN in qeth_l3_recover_ip(). For
    consistency with qeth_l3_add_ip() we also keep it in case of EADDRINUSE,
    i.e. for some reason the card already/still has this address registered.
    
    Fixes: 4a71df50047f ("qeth: new qeth device driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240206085849.2902775-1-wintera@linux.ibm.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sched/membarrier: reduce the ability to hammer on sys_membarrier [+ + +]
Author: Linus Torvalds <torvalds@linuxfoundation.org>
Date:   Sun Feb 4 15:25:12 2024 +0000

    sched/membarrier: reduce the ability to hammer on sys_membarrier
    
    commit 944d5fe50f3f03daacfea16300e656a1691c4a23 upstream.
    
    On some systems, sys_membarrier can be very expensive, causing overall
    slowdowns for everything.  So put a lock on the path in order to
    serialize the accesses to prevent the ability for this to be called at
    too high of a frequency and saturate the machine.
    
    Reviewed-and-tested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Acked-by: Borislav Petkov <bp@alien8.de>
    Fixes: 22e4ebb97582 ("membarrier: Provide expedited private command")
    Fixes: c5f58bd58f43 ("membarrier: Provide GLOBAL_EXPEDITED command")
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
scs: add CONFIG_MMU dependency for vfree_atomic() [+ + +]
Author: Samuel Holland <samuel.holland@sifive.com>
Date:   Mon Jan 22 09:52:01 2024 -0800

    scs: add CONFIG_MMU dependency for vfree_atomic()
    
    commit 6f9dc684cae638dda0570154509884ee78d0f75c upstream.
    
    The shadow call stack implementation fails to build without CONFIG_MMU:
    
      ld.lld: error: undefined symbol: vfree_atomic
      >>> referenced by scs.c
      >>>               kernel/scs.o:(scs_free) in archive vmlinux.a
    
    Link: https://lkml.kernel.org/r/20240122175204.2371009-1-samuel.holland@sifive.com
    Fixes: a2abe7cbd8fe ("scs: switch to vmapped shadow stacks")
    Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
    Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock" [+ + +]
Author: Lee Duncan <lduncan@suse.com>
Date:   Fri Feb 9 10:07:34 2024 -0800

    scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock"
    
    commit 977fe773dcc7098d8eaf4ee6382cb51e13e784cb upstream.
    
    This reverts commit 1a1975551943f681772720f639ff42fbaa746212.
    
    This commit causes interrupts to be lost for FCoE devices, since it changed
    sping locks from "bh" to "irqsave".
    
    Instead, a work queue should be used, and will be addressed in a separate
    commit.
    
    Fixes: 1a1975551943 ("scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock")
    Signed-off-by: Lee Duncan <lduncan@suse.com>
    Link: https://lore.kernel.org/r/c578cdcd46b60470535c4c4a953e6a1feca0dffd.1707500786.git.lduncan@suse.com
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: storvsc: Fix ring buffer size calculation [+ + +]
Author: Michael Kelley <mhklinux@outlook.com>
Date:   Mon Jan 22 09:09:56 2024 -0800

    scsi: storvsc: Fix ring buffer size calculation
    
    commit f4469f3858352ad1197434557150b1f7086762a0 upstream.
    
    Current code uses the specified ring buffer size (either the default of 128
    Kbytes or a module parameter specified value) to encompass the one page
    ring buffer header plus the actual ring itself.  When the page size is 4K,
    carving off one page for the header isn't significant.  But when the page
    size is 64K on ARM64, only half of the default 128 Kbytes is left for the
    actual ring.  While this doesn't break anything, the smaller ring size
    could be a performance bottleneck.
    
    Fix this by applying the VMBUS_RING_SIZE macro to the specified ring buffer
    size.  This macro adds a page for the header, and rounds up the size to a
    page boundary, using the page size for which the kernel is built.  Use this
    new size for subsequent ring buffer calculations.  For example, on ARM64
    with 64K page size and the default ring size, this results in the actual
    ring being 128 Kbytes, which is intended.
    
    Cc: stable@vger.kernel.org # 5.15.x
    Signed-off-by: Michael Kelley <mhklinux@outlook.com>
    Link: https://lore.kernel.org/r/20240122170956.496436-1-mhklinux@outlook.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests/mm: ksm_tests should only MADV_HUGEPAGE valid memory [+ + +]
Author: Ryan Roberts <ryan.roberts@arm.com>
Date:   Mon Jan 22 12:05:54 2024 +0000

    selftests/mm: ksm_tests should only MADV_HUGEPAGE valid memory
    
    [ Upstream commit d021b442cf312664811783e92b3d5e4548e92a53 ]
    
    ksm_tests was previously mmapping a region of memory, aligning the
    returned pointer to a PMD boundary, then setting MADV_HUGEPAGE, but was
    setting it past the end of the mmapped area due to not taking the pointer
    alignment into consideration.  Fix this behaviour.
    
    Up until commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
    boundaries"), this buggy behavior was (usually) masked because the
    alignment difference was always less than PMD-size.  But since the
    mentioned commit, `ksm_tests -H -s 100` started failing.
    
    Link: https://lkml.kernel.org/r/20240122120554.3108022-1-ryan.roberts@arm.com
    Fixes: 325254899684 ("selftests: vm: add KSM huge pages merging time test")
    Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
    Cc: Pedro Demarchi Gomes <pedrodemargomes@gmail.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/mm: Update va_high_addr_switch.sh to check CPU for la57 flag [+ + +]
Author: Audra Mitchell <audra@redhat.com>
Date:   Fri Jan 19 15:58:01 2024 -0500

    selftests/mm: Update va_high_addr_switch.sh to check CPU for la57 flag
    
    [ Upstream commit 52e63d67b5bb423b33d7a262ac7f8bd375a90145 ]
    
    In order for the page table level 5 to be in use, the CPU must have the
    setting enabled in addition to the CONFIG option. Check for the flag to be
    set to avoid false test failures on systems that do not have this cpu flag
    set.
    
    The test does a series of mmap calls including three using the
    MAP_FIXED flag and specifying an address that is 1<<47 or 1<<48.  These
    addresses are only available if you are using level 5 page tables,
    which requires both the CPU to have the capabiltiy (la57 flag) and the
    kernel to be configured.  Currently the test only checks for the kernel
    configuration option, so this test can still report a false positive.
    Here are the three failing lines:
    
    $ ./va_high_addr_switch | grep FAILED
    mmap(ADDR_SWITCH_HINT, 2 * PAGE_SIZE, MAP_FIXED): 0xffffffffffffffff - FAILED
    mmap(HIGH_ADDR, MAP_FIXED): 0xffffffffffffffff - FAILED
    mmap(ADDR_SWITCH_HINT, 2 * PAGE_SIZE, MAP_FIXED): 0xffffffffffffffff - FAILED
    
    I thought (for about a second) refactoring the test so that these three
    mmap calls will only be run on systems with the level 5 page tables
    available, but the whole point of the test is to check the level 5
    feature...
    
    Link: https://lkml.kernel.org/r/20240119205801.62769-1-audra@redhat.com
    Fixes: 4f2930c6718a ("selftests/vm: only run 128TBswitch with 5-level paging")
    Signed-off-by: Audra Mitchell <audra@redhat.com>
    Cc: Rafael Aquini <raquini@redhat.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Adam Sindelar <adam@wowsignal.io>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: mptcp: add missing kconfig for NF Filter [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Jan 31 22:49:47 2024 +0100

    selftests: mptcp: add missing kconfig for NF Filter
    
    commit 3645c844902bd4e173d6704fc2a37e8746904d67 upstream.
    
    Since the commit mentioned below, 'mptcp_join' selftests is using
    IPTables to add rules to the Filter table.
    
    It is then required to have IP_NF_FILTER KConfig.
    
    This KConfig is usually enabled by default in many defconfig, but we
    recently noticed that some CI were running our selftests without them
    enabled.
    
    Fixes: 8d014eaa9254 ("selftests: mptcp: add ADD_ADDR timeout test case")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: add missing kconfig for NF Filter in v6 [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Jan 31 22:49:48 2024 +0100

    selftests: mptcp: add missing kconfig for NF Filter in v6
    
    commit 8c86fad2cecdc6bf7283ecd298b4d0555bd8b8aa upstream.
    
    Since the commit mentioned below, 'mptcp_join' selftests is using
    IPTables to add rules to the Filter table for IPv6.
    
    It is then required to have IP6_NF_FILTER KConfig.
    
    This KConfig is usually enabled by default in many defconfig, but we
    recently noticed that some CI were running our selftests without them
    enabled.
    
    Fixes: 523514ed0a99 ("selftests: mptcp: add ADD_ADDR IPv6 test cases")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240131-upstream-net-20240131-mptcp-ci-issues-v1-3-4c1c11e571ff@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: add missing kconfig for NF Mangle [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Jan 31 22:49:49 2024 +0100

    selftests: mptcp: add missing kconfig for NF Mangle
    
    commit 2d41f10fa497182df9012d3e95d9cea24eb42e61 upstream.
    
    Since the commit mentioned below, 'mptcp_join' selftests is using
    IPTables to add rules to the Mangle table, only in IPv4.
    
    This KConfig is usually enabled by default in many defconfig, but we
    recently noticed that some CI were running our selftests without them
    enabled.
    
    Fixes: b6e074e171bc ("selftests: mptcp: add infinite map testcase")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240131-upstream-net-20240131-mptcp-ci-issues-v1-4-4c1c11e571ff@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: increase timeout to 30 min [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Jan 31 22:49:50 2024 +0100

    selftests: mptcp: increase timeout to 30 min
    
    commit 4d4dfb2019d7010efb65926d9d1c1793f9a367c6 upstream.
    
    On very slow environments -- e.g. when QEmu is used without KVM --,
    mptcp_join.sh selftest can take a bit more than 20 minutes. Bump the
    default timeout by 50% as it seems normal to take that long on some
    environments.
    
    When a debug kernel config is used, this selftest will take even longer,
    but that's certainly not a common test env to consider for the timeout.
    
    The Fixes tag that has been picked here is there simply to help having
    this patch backported to older stable versions. It is difficult to point
    to the exact commit that made some env reaching the timeout from time to
    time.
    
    Fixes: d17b968b9876 ("selftests: mptcp: increase timeout to 20 minutes")
    Cc: stable@vger.kernel.org
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240131-upstream-net-20240131-mptcp-ci-issues-v1-5-4c1c11e571ff@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
serial: max310x: fail probe if clock crystal is unstable [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Tue Jan 16 16:30:00 2024 -0500

    serial: max310x: fail probe if clock crystal is unstable
    
    commit 8afa6c6decea37e7cb473d2c60473f37f46cea35 upstream.
    
    A stable clock is really required in order to use this UART, so log an
    error message and bail out if the chip reports that the clock is not
    stable.
    
    Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
    Cc: stable@vger.kernel.org
    Suggested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
    Link: https://www.spinics.net/lists/linux-serial/msg35773.html
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20240116213001.3691629-4-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: max310x: improve crystal stable clock detection [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Tue Jan 16 16:29:59 2024 -0500

    serial: max310x: improve crystal stable clock detection
    
    commit 93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965 upstream.
    
    Some people are seeing a warning similar to this when using a crystal:
    
        max310x 11-006c: clock is not stable yet
    
    The datasheet doesn't mention the maximum time to wait for the clock to be
    stable when using a crystal, and it seems that the 10ms delay in the driver
    is not always sufficient.
    
    Jan Kundrát reported that it took three tries (each separated by 10ms) to
    get a stable clock.
    
    Modify behavior to check stable clock ready bit multiple times (20), and
    waiting 10ms between each try.
    
    Note: the first draft of the driver originally used a 50ms delay, without
    checking the clock stable bit.
    Then a loop with 1000 retries was implemented, each time reading the clock
    stable bit.
    
    Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
    Cc: stable@vger.kernel.org
    Suggested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
    Link: https://www.spinics.net/lists/linux-serial/msg35773.html
    Link: https://lore.kernel.org/all/20240110174015.6f20195fde08e5c9e64e5675@hugovil.com/raw
    Link: https://github.com/boundarydevices/linux/commit/e5dfe3e4a751392515d78051973190301a37ca9a
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20240116213001.3691629-3-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: max310x: prevent infinite while() loop in port startup [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Tue Jan 16 16:30:01 2024 -0500

    serial: max310x: prevent infinite while() loop in port startup
    
    commit b35f8dbbce818b02c730dc85133dc7754266e084 upstream.
    
    If there is a problem after resetting a port, the do/while() loop that
    checks the default value of DIVLSB register may run forever and spam the
    I2C bus.
    
    Add a delay before each read of DIVLSB, and a maximum number of tries to
    prevent that situation from happening.
    
    Also fail probe if port reset is unsuccessful.
    
    Fixes: 10d8b34a4217 ("serial: max310x: Driver rework")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20240116213001.3691629-5-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: max310x: set default value when reading clock ready bit [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Tue Jan 16 16:29:58 2024 -0500

    serial: max310x: set default value when reading clock ready bit
    
    commit 0419373333c2f2024966d36261fd82a453281e80 upstream.
    
    If regmap_read() returns a non-zero value, the 'val' variable can be left
    uninitialized.
    
    Clear it before calling regmap_read() to make sure we properly detect
    the clock ready bit.
    
    Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20240116213001.3691629-2-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smb: client: fix parsing of SMB3.1.1 POSIX create context [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Fri Jan 19 01:08:26 2024 -0300

    smb: client: fix parsing of SMB3.1.1 POSIX create context
    
    commit 76025cc2285d9ede3d717fe4305d66f8be2d9346 upstream.
    
    The data offset for the SMB3.1.1 POSIX create context will always be
    8-byte aligned so having the check 'noff + nlen >= doff' in
    smb2_parse_contexts() is wrong as it will lead to -EINVAL because noff
    + nlen == doff.
    
    Fix the sanity check to correctly handle aligned create context data.
    
    Fixes: af1689a9b770 ("smb: client: fix potential OOBs in smb2_parse_contexts()")
    Signed-off-by: Paulo Alcantara <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Guruswamy Basavaiah <guruswamy.basavaiah@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

smb: client: fix potential OOBs in smb2_parse_contexts() [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Mon Dec 11 10:26:41 2023 -0300

    smb: client: fix potential OOBs in smb2_parse_contexts()
    
    commit af1689a9b7701d9907dfc84d2a4b57c4bc907144 upstream.
    
    Validate offsets and lengths before dereferencing create contexts in
    smb2_parse_contexts().
    
    This fixes following oops when accessing invalid create contexts from
    server:
    
      BUG: unable to handle page fault for address: ffff8881178d8cc3
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      PGD 4a01067 P4D 4a01067 PUD 0
      Oops: 0000 [#1] PREEMPT SMP NOPTI
      CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
      rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
      RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]
      Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00
      00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7
      7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00
      RSP: 0018:ffffc900007939e0 EFLAGS: 00010216
      RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90
      RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000
      RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000
      R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000
      R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22
      FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0
      PKRU: 55555554
      Call Trace:
       <TASK>
       ? __die+0x23/0x70
       ? page_fault_oops+0x181/0x480
       ? search_module_extables+0x19/0x60
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? exc_page_fault+0x1b6/0x1c0
       ? asm_exc_page_fault+0x26/0x30
       ? smb2_parse_contexts+0xa0/0x3a0 [cifs]
       SMB2_open+0x38d/0x5f0 [cifs]
       ? smb2_is_path_accessible+0x138/0x260 [cifs]
       smb2_is_path_accessible+0x138/0x260 [cifs]
       cifs_is_path_remote+0x8d/0x230 [cifs]
       cifs_mount+0x7e/0x350 [cifs]
       cifs_smb3_do_mount+0x128/0x780 [cifs]
       smb3_get_tree+0xd9/0x290 [cifs]
       vfs_get_tree+0x2c/0x100
       ? capable+0x37/0x70
       path_mount+0x2d7/0xb80
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? _raw_spin_unlock_irqrestore+0x44/0x60
       __x64_sys_mount+0x11a/0x150
       do_syscall_64+0x47/0xf0
       entry_SYSCALL_64_after_hwframe+0x6f/0x77
      RIP: 0033:0x7f8737657b1e
    
    Reported-by: Robert Morris <rtm@csail.mit.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    [Guru: Modified the patch to be applicable to the cached_dir.c file.]
    Signed-off-by: Guruswamy Basavaiah <guruswamy.basavaiah@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
spi: ppc4xx: Drop write-only variable [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sat Feb 10 17:40:08 2024 +0100

    spi: ppc4xx: Drop write-only variable
    
    [ Upstream commit b3aa619a8b4706f35cb62f780c14e68796b37f3f ]
    
    Since commit 24778be20f87 ("spi: convert drivers to use
    bits_per_word_mask") the bits_per_word variable is only written to. The
    check that was there before isn't needed any more as the spi core
    ensures that only 8 bit transfers are used, so the variable can go away
    together with all assignments to it.
    
    Fixes: 24778be20f87 ("spi: convert drivers to use bits_per_word_mask")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20240210164006.208149-8-u.kleine-koenig@pengutronix.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
staging: iio: ad5933: fix type mismatch regression [+ + +]
Author: David Schiller <david.schiller@jku.at>
Date:   Mon Jan 22 14:49:17 2024 +0100

    staging: iio: ad5933: fix type mismatch regression
    
    commit 6db053cd949fcd6254cea9f2cd5d39f7bd64379c upstream.
    
    Commit 4c3577db3e4f ("Staging: iio: impedance-analyzer: Fix sparse
    warning") fixed a compiler warning, but introduced a bug that resulted
    in one of the two 16 bit IIO channels always being zero (when both are
    enabled).
    
    This is because int is 32 bits wide on most architectures and in the
    case of a little-endian machine the two most significant bytes would
    occupy the buffer for the second channel as 'val' is being passed as a
    void pointer to 'iio_push_to_buffers()'.
    
    Fix by defining 'val' as u16. Tested working on ARM64.
    
    Fixes: 4c3577db3e4f ("Staging: iio: impedance-analyzer: Fix sparse warning")
    Signed-off-by: David Schiller <david.schiller@jku.at>
    Link: https://lore.kernel.org/r/20240122134916.2137957-1-david.schiller@jku.at
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tls/sw: Use splice_eof() to flush [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Wed Jun 7 19:19:11 2023 +0100

    tls/sw: Use splice_eof() to flush
    
    [ Upstream commit df720d288dbb1793e82b6ccbfc670ec871e9def4 ]
    
    Allow splice to end a TLS record after prematurely ending a splice/sendfile
    due to getting an EOF condition (->splice_read() returned 0) after splice
    had called TLS with a sendmsg() with MSG_MORE set when the user didn't set
    MSG_MORE.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Link: https://lore.kernel.org/r/CAHk-=wh=V579PDYvkpnTobCLGczbgxpMgGmmhqiTyE34Cpi5Gg@mail.gmail.com/
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Jakub Kicinski <kuba@kernel.org>
    cc: Chuck Lever <chuck.lever@oracle.com>
    cc: Boris Pismenny <borisp@nvidia.com>
    cc: John Fastabend <john.fastabend@gmail.com>
    cc: Jens Axboe <axboe@kernel.dk>
    cc: Matthew Wilcox <willy@infradead.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: aec7961916f3 ("tls: fix race between async notify and socket close")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tls: extract context alloc/initialization out of tls_set_sw_offload [+ + +]
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Mon Oct 9 22:50:46 2023 +0200

    tls: extract context alloc/initialization out of tls_set_sw_offload
    
    [ Upstream commit 615580cbc99af0da2d1c7226fab43a3d5003eb97 ]
    
    Simplify tls_set_sw_offload a bit.
    
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: aec7961916f3 ("tls: fix race between async notify and socket close")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tls: fix NULL deref on tls_sw_splice_eof() with empty record [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Wed Nov 22 22:44:47 2023 +0100

    tls: fix NULL deref on tls_sw_splice_eof() with empty record
    
    commit 53f2cb491b500897a619ff6abd72f565933760f0 upstream.
    
    syzkaller discovered that if tls_sw_splice_eof() is executed as part of
    sendfile() when the plaintext/ciphertext sk_msg are empty, the send path
    gets confused because the empty ciphertext buffer does not have enough
    space for the encryption overhead. This causes tls_push_record() to go on
    the `split = true` path (which is only supposed to be used when interacting
    with an attached BPF program), and then get further confused and hit the
    tls_merge_open_record() path, which then assumes that there must be at
    least one populated buffer element, leading to a NULL deref.
    
    It is possible to have empty plaintext/ciphertext buffers if we previously
    bailed from tls_sw_sendmsg_locked() via the tls_trim_both_msgs() path.
    tls_sw_push_pending_record() already handles this case correctly; let's do
    the same check in tls_sw_splice_eof().
    
    Fixes: df720d288dbb ("tls/sw: Use splice_eof() to flush")
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+40d43509a099ea756317@syzkaller.appspotmail.com
    Signed-off-by: Jann Horn <jannh@google.com>
    Link: https://lore.kernel.org/r/20231122214447.675768-1-jannh@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tls: fix race between async notify and socket close [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Feb 6 17:18:19 2024 -0800

    tls: fix race between async notify and socket close
    
    [ Upstream commit aec7961916f3f9e88766e2688992da6980f11b8d ]
    
    The submitting thread (one which called recvmsg/sendmsg)
    may exit as soon as the async crypto handler calls complete()
    so any code past that point risks touching already freed data.
    
    Try to avoid the locking and extra flags altogether.
    Have the main thread hold an extra reference, this way
    we can depend solely on the atomic ref counter for
    synchronization.
    
    Don't futz with reiniting the completion, either, we are now
    tightly controlling when completion fires.
    
    Reported-by: valis <sec@valis.email>
    Fixes: 0cada33241d9 ("net/tls: fix race condition causing kernel panic")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools/rtla: Exit with EXIT_SUCCESS when help is invoked [+ + +]
Author: John Kacur <jkacur@redhat.com>
Date:   Fri Feb 2 19:16:07 2024 -0500

    tools/rtla: Exit with EXIT_SUCCESS when help is invoked
    
    commit b5f319360371087d52070d8f3fc7789e80ce69a6 upstream.
    
    Fix rtla so that the following commands exit with 0 when help is invoked
    
    rtla osnoise top -h
    rtla osnoise hist -h
    rtla timerlat top -h
    rtla timerlat hist -h
    
    Link: https://lore.kernel.org/linux-trace-devel/20240203001607.69703-1-jkacur@redhat.com
    
    Cc: stable@vger.kernel.org
    Fixes: 1eeb6328e8b3 ("rtla/timerlat: Add timerlat hist mode")
    Signed-off-by: John Kacur <jkacur@redhat.com>
    Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tools/rtla: Fix Makefile compiler options for clang [+ + +]
Author: Daniel Bristot de Oliveira <bristot@kernel.org>
Date:   Tue Feb 6 12:05:29 2024 +0100

    tools/rtla: Fix Makefile compiler options for clang
    
    commit bc4cbc9d260ba8358ca63662919f4bb223cb603b upstream.
    
    The following errors are showing up when compiling rtla with clang:
    
     $ make HOSTCC=clang CC=clang LLVM_IAS=1
     [...]
    
      clang -O -g -DVERSION=\"6.8.0-rc1\" -flto=auto -ffat-lto-objects
            -fexceptions -fstack-protector-strong
            -fasynchronous-unwind-tables -fstack-clash-protection  -Wall
            -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
            -Wp,-D_GLIBCXX_ASSERTIONS -Wno-maybe-uninitialized
            $(pkg-config --cflags libtracefs)    -c -o src/utils.o src/utils.c
    
      clang: warning: optimization flag '-ffat-lto-objects' is not supported [-Wignored-optimization-argument]
      warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
      1 warning generated.
    
      clang -o rtla -ggdb  src/osnoise.o src/osnoise_hist.o src/osnoise_top.o
      src/rtla.o src/timerlat_aa.o src/timerlat.o src/timerlat_hist.o
      src/timerlat_top.o src/timerlat_u.o src/trace.o src/utils.o $(pkg-config --libs libtracefs)
    
      src/osnoise.o: file not recognized: file format not recognized
      clang: error: linker command failed with exit code 1 (use -v to see invocation)
      make: *** [Makefile:110: rtla] Error 1
    
    Solve these issues by:
      - removing -ffat-lto-objects and -Wno-maybe-uninitialized if using clang
      - informing the linker about -flto=auto
    
    Link: https://lore.kernel.org/linux-trace-kernel/567ac1b94effc228ce9a0225b9df7232a9b35b55.1707217097.git.bristot@kernel.org
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Bill Wendling <morbo@google.com>
    Cc: Justin Stitt <justinstitt@google.com>
    Fixes: 1a7b22ab15eb ("tools/rtla: Build with EXTRA_{C,LD}FLAGS")
    Suggested-by: Donald Zickus <dzickus@redhat.com>
    Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tools/rtla: Fix uninitialized bucket/data->bucket_size warning [+ + +]
Author: Daniel Bristot de Oliveira <bristot@kernel.org>
Date:   Tue Feb 6 12:05:30 2024 +0100

    tools/rtla: Fix uninitialized bucket/data->bucket_size warning
    
    commit 64dc40f7523369912d7adb22c8cb655f71610505 upstream.
    
    When compiling rtla with clang, I am getting the following warnings:
    
    $ make HOSTCC=clang CC=clang LLVM_IAS=1
    
    [..]
    clang -O -g -DVERSION=\"6.8.0-rc3\" -flto=auto -fexceptions
            -fstack-protector-strong -fasynchronous-unwind-tables
            -fstack-clash-protection  -Wall -Werror=format-security
            -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
            $(pkg-config --cflags libtracefs)
            -c -o src/osnoise_hist.o src/osnoise_hist.c
    src/osnoise_hist.c:138:6: warning: variable 'bucket' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
      138 |         if (data->bucket_size)
          |             ^~~~~~~~~~~~~~~~~
    src/osnoise_hist.c:149:6: note: uninitialized use occurs here
      149 |         if (bucket < entries)
          |             ^~~~~~
    src/osnoise_hist.c:138:2: note: remove the 'if' if its condition is always true
      138 |         if (data->bucket_size)
          |         ^~~~~~~~~~~~~~~~~~~~~~
      139 |                 bucket = duration / data->bucket_size;
    src/osnoise_hist.c:132:12: note: initialize the variable 'bucket' to silence this warning
      132 |         int bucket;
          |                   ^
          |                    = 0
    1 warning generated.
    
    [...]
    
    clang -O -g -DVERSION=\"6.8.0-rc3\" -flto=auto -fexceptions
            -fstack-protector-strong -fasynchronous-unwind-tables
            -fstack-clash-protection  -Wall -Werror=format-security
            -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
            $(pkg-config --cflags libtracefs)
            -c -o src/timerlat_hist.o src/timerlat_hist.c
    src/timerlat_hist.c:181:6: warning: variable 'bucket' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
      181 |         if (data->bucket_size)
          |             ^~~~~~~~~~~~~~~~~
    src/timerlat_hist.c:204:6: note: uninitialized use occurs here
      204 |         if (bucket < entries)
          |             ^~~~~~
    src/timerlat_hist.c:181:2: note: remove the 'if' if its condition is always true
      181 |         if (data->bucket_size)
          |         ^~~~~~~~~~~~~~~~~~~~~~
      182 |                 bucket = latency / data->bucket_size;
    src/timerlat_hist.c:175:12: note: initialize the variable 'bucket' to silence this warning
      175 |         int bucket;
          |                   ^
          |                    = 0
    1 warning generated.
    
    This is a legit warning, but data->bucket_size is always > 0 (see
    timerlat_hist_parse_args()), so the if is not necessary.
    
    Remove the unneeded if (data->bucket_size) to avoid the warning.
    
    Link: https://lkml.kernel.org/r/6e1b1665cd99042ae705b3e0fc410858c4c42346.1707217097.git.bristot@kernel.org
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Bill Wendling <morbo@google.com>
    Cc: Justin Stitt <justinstitt@google.com>
    Cc: Donald Zickus <dzickus@redhat.com>
    Fixes: 1eeb6328e8b3 ("rtla/timerlat: Add timerlat hist mode")
    Fixes: 829a6c0b5698 ("rtla/osnoise: Add the hist mode")
    Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tools/rtla: Remove unused sched_getattr() function [+ + +]
Author: Daniel Bristot de Oliveira <bristot@kernel.org>
Date:   Tue Feb 6 12:05:32 2024 +0100

    tools/rtla: Remove unused sched_getattr() function
    
    commit 084ce16df0f060efd371092a09a7ae74a536dc11 upstream.
    
    Clang is reporting:
    
    $ make HOSTCC=clang CC=clang LLVM_IAS=1
    [...]
    clang -O -g -DVERSION=\"6.8.0-rc3\" -flto=auto -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection  -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS $(pkg-config --cflags libtracefs)    -c -o src/utils.o src/utils.c
    src/utils.c:241:19: warning: unused function 'sched_getattr' [-Wunused-function]
      241 | static inline int sched_getattr(pid_t pid, struct sched_attr *attr,
          |                   ^~~~~~~~~~~~~
    1 warning generated.
    
    Which is correct, so remove the unused function.
    
    Link: https://lkml.kernel.org/r/eaed7ba122c4ae88ce71277c824ef41cbf789385.1707217097.git.bristot@kernel.org
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Bill Wendling <morbo@google.com>
    Cc: Justin Stitt <justinstitt@google.com>
    Cc: Donald Zickus <dzickus@redhat.com>
    Fixes: b1696371d865 ("rtla: Helper functions for rtla")
    Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tools/rtla: Replace setting prio with nice for SCHED_OTHER [+ + +]
Author: limingming3 <limingming890315@gmail.com>
Date:   Wed Feb 7 14:51:42 2024 +0800

    tools/rtla: Replace setting prio with nice for SCHED_OTHER
    
    commit 14f08c976ffe0d2117c6199c32663df1cbc45c65 upstream.
    
    Since the sched_priority for SCHED_OTHER is always 0, it makes no
    sence to set it.
    Setting nice for SCHED_OTHER seems more meaningful.
    
    Link: https://lkml.kernel.org/r/20240207065142.1753909-1-limingming3@lixiang.com
    
    Cc: stable@vger.kernel.org
    Fixes: b1696371d865 ("rtla: Helper functions for rtla")
    Signed-off-by: limingming3 <limingming3@lixiang.com>
    Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing/trigger: Fix to return error if failed to alloc snapshot [+ + +]
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date:   Fri Jan 26 09:42:58 2024 +0900

    tracing/trigger: Fix to return error if failed to alloc snapshot
    
    commit 0958b33ef5a04ed91f61cef4760ac412080c4e08 upstream.
    
    Fix register_snapshot_trigger() to return error code if it failed to
    allocate a snapshot instead of 0 (success). Unless that, it will register
    snapshot trigger without an error.
    
    Link: https://lore.kernel.org/linux-trace-kernel/170622977792.270660.2789298642759362200.stgit@devnote2
    
    Fixes: 0bbe7f719985 ("tracing: Fix the race between registering 'snapshot' event trigger and triggering 'snapshot' operation")
    Cc: stable@vger.kernel.org
    Cc: Vincent Donnefort <vdonnefort@google.com>
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing: Fix wasted memory in saved_cmdlines logic [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Fri Feb 9 06:36:22 2024 -0500

    tracing: Fix wasted memory in saved_cmdlines logic
    
    commit 44dc5c41b5b1267d4dd037d26afc0c4d3a568acb upstream.
    
    While looking at improving the saved_cmdlines cache I found a huge amount
    of wasted memory that should be used for the cmdlines.
    
    The tracing data saves pids during the trace. At sched switch, if a trace
    occurred, it will save the comm of the task that did the trace. This is
    saved in a "cache" that maps pids to comms and exposed to user space via
    the /sys/kernel/tracing/saved_cmdlines file. Currently it only caches by
    default 128 comms.
    
    The structure that uses this creates an array to store the pids using
    PID_MAX_DEFAULT (which is usually set to 32768). This causes the structure
    to be of the size of 131104 bytes on 64 bit machines.
    
    In hex: 131104 = 0x20020, and since the kernel allocates generic memory in
    powers of two, the kernel would allocate 0x40000 or 262144 bytes to store
    this structure. That leaves 131040 bytes of wasted space.
    
    Worse, the structure points to an allocated array to store the comm names,
    which is 16 bytes times the amount of names to save (currently 128), which
    is 2048 bytes. Instead of allocating a separate array, make the structure
    end with a variable length string and use the extra space for that.
    
    This is similar to a recommendation that Linus had made about eventfs_inode names:
    
      https://lore.kernel.org/all/20240130190355.11486-5-torvalds@linux-foundation.org/
    
    Instead of allocating a separate string array to hold the saved comms,
    have the structure end with: char saved_cmdlines[]; and round up to the
    next power of two over sizeof(struct saved_cmdline_buffers) + num_cmdlines * TASK_COMM_LEN
    It will use this extra space for the saved_cmdline portion.
    
    Now, instead of saving only 128 comms by default, by using this wasted
    space at the end of the structure it can save over 8000 comms and even
    saves space by removing the need for allocating the other array.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240209063622.1f7b6d5f@rorschach.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Vincent Donnefort <vdonnefort@google.com>
    Cc: Sven Schnelle <svens@linux.ibm.com>
    Cc: Mete Durlu <meted@linux.ibm.com>
    Fixes: 939c7a4f04fcd ("tracing: Introduce saved_cmdlines_size file")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tracing: Inform kmemleak of saved_cmdlines allocation [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Wed Feb 14 11:20:46 2024 -0500

    tracing: Inform kmemleak of saved_cmdlines allocation
    
    commit 2394ac4145ea91b92271e675a09af2a9ea6840b7 upstream.
    
    The allocation of the struct saved_cmdlines_buffer structure changed from:
    
            s = kmalloc(sizeof(*s), GFP_KERNEL);
            s->saved_cmdlines = kmalloc_array(TASK_COMM_LEN, val, GFP_KERNEL);
    
    to:
    
            orig_size = sizeof(*s) + val * TASK_COMM_LEN;
            order = get_order(orig_size);
            size = 1 << (order + PAGE_SHIFT);
            page = alloc_pages(GFP_KERNEL, order);
            if (!page)
                    return NULL;
    
            s = page_address(page);
            memset(s, 0, sizeof(*s));
    
            s->saved_cmdlines = kmalloc_array(TASK_COMM_LEN, val, GFP_KERNEL);
    
    Where that s->saved_cmdlines allocation looks to be a dangling allocation
    to kmemleak. That's because kmemleak only keeps track of kmalloc()
    allocations. For allocations that use page_alloc() directly, the kmemleak
    needs to be explicitly informed about it.
    
    Add kmemleak_alloc() and kmemleak_free() around the page allocation so
    that it doesn't give the following false positive:
    
    unreferenced object 0xffff8881010c8000 (size 32760):
      comm "swapper", pid 0, jiffies 4294667296
      hex dump (first 32 bytes):
        ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
        ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
      backtrace (crc ae6ec1b9):
        [<ffffffff86722405>] kmemleak_alloc+0x45/0x80
        [<ffffffff8414028d>] __kmalloc_large_node+0x10d/0x190
        [<ffffffff84146ab1>] __kmalloc+0x3b1/0x4c0
        [<ffffffff83ed7103>] allocate_cmdlines_buffer+0x113/0x230
        [<ffffffff88649c34>] tracer_alloc_buffers.isra.0+0x124/0x460
        [<ffffffff8864a174>] early_trace_init+0x14/0xa0
        [<ffffffff885dd5ae>] start_kernel+0x12e/0x3c0
        [<ffffffff885f5758>] x86_64_start_reservations+0x18/0x30
        [<ffffffff885f582b>] x86_64_start_kernel+0x7b/0x80
        [<ffffffff83a001c3>] secondary_startup_64_no_verify+0x15e/0x16b
    
    Link: https://lore.kernel.org/linux-trace-kernel/87r0hfnr9r.fsf@kernel.org/
    Link: https://lore.kernel.org/linux-trace-kernel/20240214112046.09a322d6@gandalf.local.home
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Fixes: 44dc5c41b5b1 ("tracing: Fix wasted memory in saved_cmdlines logic")
    Reported-by: Kalle Valo <kvalo@kernel.org>
    Tested-by: Kalle Valo <kvalo@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
um: Fix adding '-no-pie' for clang [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Jan 23 15:59:54 2024 -0700

    um: Fix adding '-no-pie' for clang
    
    commit 846cfbeed09b45d985079a9173cf390cc053715b upstream.
    
    The kernel builds with -fno-PIE, so commit 883354afbc10 ("um: link
    vmlinux with -no-pie") added the compiler linker flag '-no-pie' via
    cc-option because '-no-pie' was only supported in GCC 6.1.0 and newer.
    
    While this works for GCC, this does not work for clang because cc-option
    uses '-c', which stops the pipeline right before linking, so '-no-pie'
    is unconsumed and clang warns, causing cc-option to fail just as it
    would if the option was entirely unsupported:
    
      $ clang -Werror -no-pie -c -o /dev/null -x c /dev/null
      clang-16: error: argument unused during compilation: '-no-pie' [-Werror,-Wunused-command-line-argument]
    
    A recent version of clang exposes this because it generates a relocation
    under '-mcmodel=large' that is not supported in PIE mode:
    
      /usr/sbin/ld: init/main.o: relocation R_X86_64_32 against symbol `saved_command_line' can not be used when making a PIE object; recompile with -fPIE
      /usr/sbin/ld: failed to set dynamic section sizes: bad value
      clang: error: linker command failed with exit code 1 (use -v to see invocation)
    
    Remove the cc-option check altogether. It is wasteful to invoke the
    compiler to check for '-no-pie' because only one supported compiler
    version does not support it, GCC 5.x (as it is supported with the
    minimum version of clang and GCC 6.1.0+). Use a combination of the
    gcc-min-version macro and CONFIG_CC_IS_CLANG to unconditionally add
    '-no-pie' with CONFIG_LD_SCRIPT_DYN=y, so that it is enabled with all
    compilers that support this. Furthermore, using gcc-min-version can help
    turn this back into
    
      LINK-$(CONFIG_LD_SCRIPT_DYN) += -no-pie
    
    when the minimum version of GCC is bumped past 6.1.0.
    
    Cc: stable@vger.kernel.org
    Closes: https://github.com/ClangBuiltLinux/linux/issues/1982
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: update workarounds for gcc "asm goto" issue [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Feb 15 11:14:33 2024 -0800

    update workarounds for gcc "asm goto" issue
    
    commit 68fb3ca0e408e00db1c3f8fccdfa19e274c033be upstream.
    
    In commit 4356e9f841f7 ("work around gcc bugs with 'asm goto' with
    outputs") I did the gcc workaround unconditionally, because the cause of
    the bad code generation wasn't entirely clear.
    
    In the meantime, Jakub Jelinek debugged the issue, and has come up with
    a fix in gcc [2], which also got backported to the still maintained
    branches of gcc-11, gcc-12 and gcc-13.
    
    Note that while the fix technically wasn't in the original gcc-14
    branch, Jakub says:
    
     "while it is true that no GCC 14 snapshots until today (or whenever the
      fix will be committed) have the fix, for GCC trunk it is up to the
      distros to use the latest snapshot if they use it at all and would
      allow better testing of the kernel code without the workaround, so
      that if there are other issues they won't be discovered years later.
      Most userland code doesn't actually use asm goto with outputs..."
    
    so we will consider gcc-14 to be fixed - if somebody is using gcc
    snapshots of the gcc-14 before the fix, they should upgrade.
    
    Note that while the bug goes back to gcc-11, in practice other gcc
    changes seem to have effectively hidden it since gcc-12.1 as per a
    bisect by Jakub.  So even a gcc-14 snapshot without the fix likely
    doesn't show actual problems.
    
    Also, make the default 'asm_goto_output()' macro mark the asm as
    volatile by hand, because of an unrelated gcc issue [1] where it doesn't
    match the documented behavior ("asm goto is always volatile").
    
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103979 [1]
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 [2]
    Link: https://lore.kernel.org/all/20240208220604.140859-1-seanjc@google.com/
    Requested-by: Jakub Jelinek <jakub@redhat.com>
    Cc: Uros Bizjak <ubizjak@gmail.com>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Andrew Pinski <quic_apinski@quicinc.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend [+ + +]
Author: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
Date:   Fri Jan 19 15:18:25 2024 +0530

    usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend
    
    commit 61a348857e869432e6a920ad8ea9132e8d44c316 upstream.
    
    In current scenario if Plug-out and Plug-In performed continuously
    there could be a chance while checking for dwc->gadget_driver in
    dwc3_gadget_suspend, a NULL pointer dereference may occur.
    
    Call Stack:
    
            CPU1:                           CPU2:
            gadget_unbind_driver            dwc3_suspend_common
            dwc3_gadget_stop                dwc3_gadget_suspend
                                            dwc3_disconnect_gadget
    
    CPU1 basically clears the variable and CPU2 checks the variable.
    Consider CPU1 is running and right before gadget_driver is cleared
    and in parallel CPU2 executes dwc3_gadget_suspend where it finds
    dwc->gadget_driver which is not NULL and resumes execution and then
    CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where
    it checks dwc->gadget_driver is already NULL because of which the
    NULL pointer deference occur.
    
    Cc: stable@vger.kernel.org
    Fixes: 9772b47a4c29 ("usb: dwc3: gadget: Fix suspend/resume during device mode")
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
    Link: https://lore.kernel.org/r/20240119094825.26530-1-quic_uaggarwa@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: f_mass_storage: forbid async queue when shutdown happen [+ + +]
Author: yuan linyu <yuanlinyu@hihonor.com>
Date:   Tue Jan 23 11:48:29 2024 +0800

    usb: f_mass_storage: forbid async queue when shutdown happen
    
    commit b2d2d7ea0dd09802cf5a0545bf54d8ad8987d20c upstream.
    
    When write UDC to empty and unbind gadget driver from gadget device, it is
    possible that there are many queue failures for mass storage function.
    
    The root cause is mass storage main thread alaways try to queue request to
    receive a command from host if running flag is on, on platform like dwc3,
    if pull down called, it will not queue request again and return
    -ESHUTDOWN, but it not affect running flag of mass storage function.
    
    Check return code from mass storage function and clear running flag if it
    is -ESHUTDOWN, also indicate start in/out transfer failure to break loops.
    
    Cc: stable <stable@kernel.org>
    Signed-off-by: yuan linyu <yuanlinyu@hihonor.com>
    Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20240123034829.3848409-1-yuanlinyu@hihonor.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: hub: check for alternate port before enabling A_ALT_HNP_SUPPORT [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Mon Jan 22 16:35:32 2024 +0100

    USB: hub: check for alternate port before enabling A_ALT_HNP_SUPPORT
    
    commit f17c34ffc792bbb520e4b61baa16b6cfc7d44b13 upstream.
    
    The OTG 1.3 spec has the feature A_ALT_HNP_SUPPORT, which tells
    a device that it is connected to the wrong port. Some devices
    refuse to operate if you enable that feature, because it indicates
    to them that they ought to request to be connected to another port.
    
    According to the spec this feature may be used based only the following
    three conditions:
    
    6.5.3 a_alt_hnp_support
    Setting this feature indicates to the B-device that it is connected to
    an A-device port that is not capable of HNP, but that the A-device does
    have an alternate port that is capable of HNP.
    The A-device is required to set this feature under the following conditions:
    • the A-device has multiple receptacles
    • the A-device port that connects to the B-device does not support HNP
    • the A-device has another port that does support HNP
    
    A check for the third and first condition is missing. Add it.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@kernel.org>
    Fixes: 7d2d641c44269 ("usb: otg: don't set a_alt_hnp_support feature for OTG 2.0 device")
    Link: https://lore.kernel.org/r/20240122153545.12284-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: ucsi: Add missing ppm_lock [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Sun Jan 21 21:41:21 2024 +0100

    usb: ucsi: Add missing ppm_lock
    
    commit c9aed03a0a683fd1600ea92f2ad32232d4736272 upstream.
    
    Calling ->sync_write must be done while holding the PPM lock as
    the mailbox logic does not support concurrent commands.
    
    At least since the addition of partner task this means that
    ucsi_acknowledge_connector_change should be called with the
    PPM lock held as it calls ->sync_write.
    
    Thus protect the only call to ucsi_acknowledge_connector_change
    with the PPM. All other calls to ->sync_write already happen
    under the PPM lock.
    
    Fixes: b9aa02ca39a4 ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking")
    Cc: stable@vger.kernel.org
    Signed-off-by: "Christian A. Ehrhardt" <lk@c--e.de>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240121204123.275441-2-lk@c--e.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: ucsi_acpi: Fix command completion handling [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Sun Jan 21 21:41:22 2024 +0100

    usb: ucsi_acpi: Fix command completion handling
    
    commit 2840143e393a4ddc1caab4372969ea337371168c upstream.
    
    In case of a spurious or otherwise delayed notification it is
    possible that CCI still reports the previous completion. The
    UCSI spec is aware of this and provides two completion bits in
    CCI, one for normal commands and one for acks. As acks and commands
    alternate the notification handler can determine if the completion
    bit is from the current command.
    
    The initial UCSI code correctly handled this but the distinction
    between the two completion bits was lost with the introduction of
    the new API.
    
    To fix this revive the ACK_PENDING bit for ucsi_acpi and only complete
    commands if the completion bit matches.
    
    Fixes: f56de278e8ec ("usb: typec: ucsi: acpi: Move to the new API")
    Cc: stable@vger.kernel.org
    Signed-off-by: "Christian A. Ehrhardt" <lk@c--e.de>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240121204123.275441-3-lk@c--e.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: ulpi: Fix debugfs directory leak [+ + +]
Author: Sean Anderson <sean.anderson@seco.com>
Date:   Fri Jan 26 17:38:00 2024 -0500

    usb: ulpi: Fix debugfs directory leak
    
    commit 3caf2b2ad7334ef35f55b95f3e1b138c6f77b368 upstream.
    
    The ULPI per-device debugfs root is named after the ulpi device's
    parent, but ulpi_unregister_interface tries to remove a debugfs
    directory named after the ulpi device itself. This results in the
    directory sticking around and preventing subsequent (deferred) probes
    from succeeding. Change the directory name to match the ulpi device.
    
    Fixes: bd0a0a024f2a ("usb: ulpi: Add debugfs support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Anderson <sean.anderson@seco.com>
    Link: https://lore.kernel.org/r/20240126223800.2864613-1-sean.anderson@seco.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
userfaultfd: fix mmap_changing checking in mfill_atomic_hugetlb [+ + +]
Author: Lokesh Gidra <lokeshgidra@google.com>
Date:   Wed Jan 17 14:37:29 2024 -0800

    userfaultfd: fix mmap_changing checking in mfill_atomic_hugetlb
    
    commit 67695f18d55924b2013534ef3bdc363bc9e14605 upstream.
    
    In mfill_atomic_hugetlb(), mmap_changing isn't being checked
    again if we drop mmap_lock and reacquire it. When the lock is not held,
    mmap_changing could have been incremented. This is also inconsistent
    with the behavior in mfill_atomic().
    
    Link: https://lkml.kernel.org/r/20240117223729.1444522-1-lokeshgidra@google.com
    Fixes: df2cc96e77011 ("userfaultfd: prevent non-cooperative events vs mcopy_atomic races")
    Signed-off-by: Lokesh Gidra <lokeshgidra@google.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Mike Rapoport <rppt@kernel.org>
    Cc: Axel Rasmussen <axelrasmussen@google.com>
    Cc: Brian Geffon <bgeffon@google.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Kalesh Singh <kaleshsingh@google.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Nicolas Geoffray <ngeoffray@google.com>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: cfg80211: fix wiphy delayed work queueing [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Jan 25 09:51:09 2024 +0100

    wifi: cfg80211: fix wiphy delayed work queueing
    
    commit b743287d7a0007493f5cada34ed2085d475050b4 upstream.
    
    When a wiphy work is queued with timer, and then again
    without a delay, it's started immediately but *also*
    started again after the timer expires. This can lead,
    for example, to warnings in mac80211's offchannel code
    as reported by Jouni. Running the same work twice isn't
    expected, of course. Fix this by deleting the timer at
    this point, when queuing immediately due to delay=0.
    
    Cc: stable@vger.kernel.org
    Reported-by: Jouni Malinen <j@w1.fi>
    Fixes: a3ee4dc84c4e ("wifi: cfg80211: add a work abstraction with special semantics")
    Link: https://msgid.link/20240125095108.2feb0eaaa446.I4617f3210ed0e7f252290d5970dac6a876aa595b@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: iwlwifi: Fix some error codes [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Feb 8 13:17:06 2024 +0300

    wifi: iwlwifi: Fix some error codes
    
    [ Upstream commit c6ebb5b67641994de8bc486b33457fe0b681d6fe ]
    
    This saves the error as PTR_ERR(wifi_pkg).  The problem is that
    "wifi_pkg" is a valid pointer, not an error pointer.  Set the error code
    to -EINVAL instead.
    
    Fixes: 2a8084147bff ("iwlwifi: acpi: support reading and storing WRDS revision 1 and 2")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://msgid.link/9620bb77-2d7c-4d76-b255-ad824ebf8e35@moroto.mountain
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: uninitialized variable in iwl_acpi_get_ppag_table() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Feb 8 13:17:31 2024 +0300

    wifi: iwlwifi: uninitialized variable in iwl_acpi_get_ppag_table()
    
    [ Upstream commit 65c6ee90455053cfd3067c17aaa4a42b0c766543 ]
    
    This is an error path and Smatch complains that "tbl_rev" is uninitialized
    on this path.  All the other functions follow this same patter where they
    set the error code and goto out_free so that's probably what was intended
    here as well.
    
    Fixes: e8e10a37c51c ("iwlwifi: acpi: move ppag code from mvm to fw/acpi")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://msgid.link/09900c01-6540-4a32-9451-563da0029cb6@moroto.mountain
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: reload info pointer in ieee80211_tx_dequeue() [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jan 31 16:49:10 2024 +0100

    wifi: mac80211: reload info pointer in ieee80211_tx_dequeue()
    
    commit c98d8836b817d11fdff4ca7749cbbe04ff7f0c64 upstream.
    
    This pointer can change here since the SKB can change, so we
    actually later open-coded IEEE80211_SKB_CB() again. Reload
    the pointer where needed, so the monitor-mode case using it
    gets fixed, and then use info-> later as well.
    
    Cc: stable@vger.kernel.org
    Fixes: 531682159092 ("mac80211: fix VLAN handling with TXQs")
    Link: https://msgid.link/20240131164910.b54c28d583bc.I29450cec84ea6773cff5d9c16ff92b836c331471@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: mwifiex: add extra delay for firmware ready [+ + +]
Author: David Lin <yu-hao.lin@nxp.com>
Date:   Sat Dec 9 07:40:29 2023 +0800

    wifi: mwifiex: add extra delay for firmware ready
    
    [ Upstream commit 1c5d463c0770c6fa2037511a24fb17966fd07d97 ]
    
    For SDIO IW416, due to a bug, FW may return ready before complete full
    initialization. Command timeout may occur at driver load after reboot.
    Workaround by adding 100ms delay at checking FW status.
    
    Signed-off-by: David Lin <yu-hao.lin@nxp.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Acked-by: Brian Norris <briannorris@chromium.org>
    Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # Verdin AM62 (IW416)
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231208234029.2197-1-yu-hao.lin@nxp.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mwifiex: fix uninitialized firmware_stat [+ + +]
Author: David Lin <yu-hao.lin@nxp.com>
Date:   Thu Dec 21 09:55:11 2023 +0800

    wifi: mwifiex: fix uninitialized firmware_stat
    
    [ Upstream commit 3df95e265924ac898c1a38a0c01846dd0bd3b354 ]
    
    Variable firmware_stat is possible to be used without initialization.
    
    Signed-off-by: David Lin <yu-hao.lin@nxp.com>
    Fixes: 1c5d463c0770 ("wifi: mwifiex: add extra delay for firmware ready")
    Cc: stable@vger.kernel.org
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Closes: https://lore.kernel.org/r/202312192236.ZflaWYCw-lkp@intel.com/
    Acked-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231221015511.1032128-1-yu-hao.lin@nxp.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mwifiex: Support SD8978 chipset [+ + +]
Author: Lukas Wunner <lukas@wunner.de>
Date:   Fri Jan 27 15:02:00 2023 +0100

    wifi: mwifiex: Support SD8978 chipset
    
    [ Upstream commit bba047f15851c8b053221f1b276eb7682d59f755 ]
    
    The Marvell SD8978 (aka NXP IW416) uses identical registers as SD8987,
    so reuse the existing mwifiex_reg_sd8987 definition.
    
    Note that mwifiex_reg_sd8977 and mwifiex_reg_sd8997 are likewise
    identical, save for the fw_dump_ctrl register:  They define it as 0xf0
    whereas mwifiex_reg_sd8987 defines it as 0xf9.  I've verified that
    0xf9 is the correct value on SD8978.  NXP's out-of-tree driver uses
    0xf9 for all of them, so there's a chance that 0xf0 is not correct
    in the mwifiex_reg_sd8977 and mwifiex_reg_sd8997 definitions.  I cannot
    test that for lack of hardware, hence am leaving it as is.
    
    NXP has only released a firmware which runs Bluetooth over UART.
    Perhaps Bluetooth over SDIO is unsupported by this chipset.
    Consequently, only an "sdiouart" firmware image is referenced, not an
    alternative "sdsd" image.
    
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/536b4f17a72ca460ad1b07045757043fb0778988.1674827105.git.lukas@wunner.de
    Stable-dep-of: 1c5d463c0770 ("wifi: mwifiex: add extra delay for firmware ready")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
work around gcc bugs with : 'asm goto' with outputs [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Feb 9 12:39:31 2024 -0800

    work around gcc bugs with 'asm goto' with outputs
    
    commit 68fb3ca0e408e00db1c3f8fccdfa19e274c033be upstream.
    
    We've had issues with gcc and 'asm goto' before, and we created a
    'asm_volatile_goto()' macro for that in the past: see commits
    3f0116c3238a ("compiler/gcc4: Add quirk for 'asm goto' miscompilation
    bug") and a9f180345f53 ("compiler/gcc4: Make quirk for
    asm_volatile_goto() unconditional").
    
    Then, much later, we ended up removing the workaround in commit
    43c249ea0b1e ("compiler-gcc.h: remove ancient workaround for gcc PR
    58670") because we no longer supported building the kernel with the
    affected gcc versions, but we left the macro uses around.
    
    Now, Sean Christopherson reports a new version of a very similar
    problem, which is fixed by re-applying that ancient workaround.  But the
    problem in question is limited to only the 'asm goto with outputs'
    cases, so instead of re-introducing the old workaround as-is, let's
    rename and limit the workaround to just that much less common case.
    
    It looks like there are at least two separate issues that all hit in
    this area:
    
     (a) some versions of gcc don't mark the asm goto as 'volatile' when it
         has outputs:
    
            https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98619
            https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110420
    
         which is easy to work around by just adding the 'volatile' by hand.
    
     (b) Internal compiler errors:
    
            https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110422
    
         which are worked around by adding the extra empty 'asm' as a
         barrier, as in the original workaround.
    
    but the problem Sean sees may be a third thing since it involves bad
    code generation (not an ICE) even with the manually added 'volatile'.
    
    The same old workaround works for this case, even if this feels a
    bit like voodoo programming and may only be hiding the issue.
    
    Reported-and-tested-by: Sean Christopherson <seanjc@google.com>
    Link: https://lore.kernel.org/all/20240208220604.140859-1-seanjc@google.com/
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Uros Bizjak <ubizjak@gmail.com>
    Cc: Jakub Jelinek <jakub@redhat.com>
    Cc: Andrew Pinski <quic_apinski@quicinc.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
x86/fpu: Stop relying on userspace for info to fault in xsave buffer [+ + +]
Author: Andrei Vagin <avagin@google.com>
Date:   Mon Jan 29 22:36:03 2024 -0800

    x86/fpu: Stop relying on userspace for info to fault in xsave buffer
    
    commit d877550eaf2dc9090d782864c96939397a3c6835 upstream.
    
    Before this change, the expected size of the user space buffer was
    taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed
    from user-space, so it is possible construct a sigreturn frame where:
    
     * fx_sw->xstate_size is smaller than the size required by valid bits in
       fx_sw->xfeatures.
     * user-space unmaps parts of the sigrame fpu buffer so that not all of
       the buffer required by xrstor is accessible.
    
    In this case, xrstor tries to restore and accesses the unmapped area
    which results in a fault. But fault_in_readable succeeds because buf +
    fx_sw->xstate_size is within the still mapped area, so it goes back and
    tries xrstor again. It will spin in this loop forever.
    
    Instead, fault in the maximum size which can be touched by XRSTOR (taken
    from fpstate->user_size).
    
    [ dhansen: tweak subject / changelog ]
    
    Fixes: fcb3635f5018 ("x86/fpu/signal: Handle #PF in the direct restore path")
    Reported-by: Konstantin Bogomolov <bogomolov@google.com>
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Andrei Vagin <avagin@google.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Cc:stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20240130063603.3392627-1-avagin%40google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/Kconfig: Transmeta Crusoe is CPU family 5, not 6 [+ + +]
Author: Aleksander Mazur <deweloper@wp.pl>
Date:   Tue Jan 23 14:43:00 2024 +0100

    x86/Kconfig: Transmeta Crusoe is CPU family 5, not 6
    
    commit f6a1892585cd19e63c4ef2334e26cd536d5b678d upstream.
    
    The kernel built with MCRUSOE is unbootable on Transmeta Crusoe.  It shows
    the following error message:
    
      This kernel requires an i686 CPU, but only detected an i586 CPU.
      Unable to boot - please use a kernel appropriate for your CPU.
    
    Remove MCRUSOE from the condition introduced in commit in Fixes, effectively
    changing X86_MINIMUM_CPU_FAMILY back to 5 on that machine, which matches the
    CPU family given by CPUID.
    
      [ bp: Massage commit message. ]
    
    Fixes: 25d76ac88821 ("x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig")
    Signed-off-by: Aleksander Mazur <deweloper@wp.pl>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/20240123134309.1117782-1-deweloper@wp.pl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/mm/ident_map: Use gbpages only where full GB page should be mapped. [+ + +]
Author: Steve Wahl <steve.wahl@hpe.com>
Date:   Fri Jan 26 10:48:41 2024 -0600

    x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
    
    commit d794734c9bbfe22f86686dc2909c25f5ffe1a572 upstream.
    
    When ident_pud_init() uses only gbpages to create identity maps, large
    ranges of addresses not actually requested can be included in the
    resulting table; a 4K request will map a full GB.  On UV systems, this
    ends up including regions that will cause hardware to halt the system
    if accessed (these are marked "reserved" by BIOS).  Even processor
    speculation into these regions is enough to trigger the system halt.
    
    Only use gbpages when map creation requests include the full GB page
    of space.  Fall back to using smaller 2M pages when only portions of a
    GB page are included in the request.
    
    No attempt is made to coalesce mapping requests. If a request requires
    a map entry at the 2M (pmd) level, subsequent mapping requests within
    the same 1G region will also be at the pmd level, even if adjacent or
    overlapping such requests could have been combined to map a full
    gbpage.  Existing usage starts with larger regions and then adds
    smaller regions, so this should not have any great consequence.
    
    [ dhansen: fix up comment formatting, simplifty changelog ]
    
    Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20240126164841.170866-1-steve.wahl%40hpe.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xen-netback: properly sync TX responses [+ + +]
Author: Jan Beulich <jbeulich@suse.com>
Date:   Mon Jan 29 14:03:08 2024 +0100

    xen-netback: properly sync TX responses
    
    commit 7b55984c96ffe9e236eb9c82a2196e0b1f84990d upstream.
    
    Invoking the make_tx_response() / push_tx_responses() pair with no lock
    held would be acceptable only if all such invocations happened from the
    same context (NAPI instance or dealloc thread). Since this isn't the
    case, and since the interface "spec" also doesn't demand that multicast
    operations may only be performed with no in-flight transmits,
    MCAST_{ADD,DEL} processing also needs to acquire the response lock
    around the invocations.
    
    To prevent similar mistakes going forward, "downgrade" the present
    functions to private helpers of just the two remaining ones using them
    directly, with no forward declarations anymore. This involves renaming
    what so far was make_tx_response(), for the new function of that name
    to serve the new (wrapper) purpose.
    
    While there,
    - constify the txp parameters,
    - correct xenvif_idx_release()'s status parameter's type,
    - rename {,_}make_tx_response()'s status parameters for consistency with
      xenvif_idx_release()'s.
    
    Fixes: 210c34dcd8d9 ("xen-netback: add support for multicast control")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Paul Durrant <paul@xen.org>
    Link: https://lore.kernel.org/r/980c6c3d-e10e-4459-8565-e8fbde122f00@suse.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xfrm: Remove inner/outer modes from input path [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Mar 10 17:26:05 2023 +0800

    xfrm: Remove inner/outer modes from input path
    
    commit 5f24f41e8ea62a6a9095f9bbafb8b3aebe265c68 upstream.
    
    The inner/outer modes were added to abstract out common code that
    were once duplicated between IPv4 and IPv6.  As time went on the
    abstractions have been removed and we are now left with empty
    shells that only contain duplicate information.  These can be
    removed one-by-one as the same information is already present
    elsewhere in the xfrm_state object.
    
    Removing them from the input path actually allows certain valid
    combinations that are currently disallowed.  In particular, when
    a transport mode SA sits beneath a tunnel mode SA that changes
    address families, at present the transport mode SA cannot have
    AF_UNSPEC as its selector because it will be erroneously be treated
    as inter-family itself even though it simply sits beneath one.
    
    This is a serious problem because you can't set the selector to
    non-AF_UNSPEC either as that will cause the selector match to
    fail as we always match selectors to the inner-most traffic.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Sri Sakthi <srisakthi.s@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xfrm: Remove inner/outer modes from output path [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Mar 10 17:40:32 2023 +0800

    xfrm: Remove inner/outer modes from output path
    
    commit f4796398f21b9844017a2dac883b1dd6ad6edd60 upstream.
    
    The inner/outer modes were added to abstract out common code that
    were once duplicated between IPv4 and IPv6.  As time went on the
    abstractions have been removed and we are now left with empty
    shells that only contain duplicate information.  These can be
    removed one-by-one as the same information is already present
    elsewhere in the xfrm_state object.
    
    Just like the input-side, removing this from the output code
    makes it possible to use transport-mode SAs underneath an
    inter-family tunnel mode SA.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Sri Sakthi <srisakthi.s@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xfrm: Silence warnings triggerable by bad packets [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Jul 4 08:53:49 2023 +0800

    xfrm: Silence warnings triggerable by bad packets
    
    commit 57010b8ece2821a1fdfdba2197d14a022f3769db upstream.
    
    After the elimination of inner modes, a couple of warnings that
    were previously unreachable can now be triggered by malformed
    inbound packets.
    
    Fix this by:
    
    1. Moving the setting of skb->protocol into the decap functions.
    2. Returning -EINVAL when unexpected protocol is seen.
    
    Reported-by: Maciej Żenczykowski<maze@google.com>
    Fixes: 5f24f41e8ea6 ("xfrm: Remove inner/outer modes from input path")
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Reviewed-by: Maciej Żenczykowski <maze@google.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xfrm: Use xfrm_state selector for BEET input [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Wed Jun 7 16:38:47 2023 +0800

    xfrm: Use xfrm_state selector for BEET input
    
    commit 842665a9008a53ff13ac22a4e4b8ae2f10e92aca upstream.
    
    For BEET the inner address and therefore family is stored in the
    xfrm_state selector.  Use that when decapsulating an input packet
    instead of incorrectly relying on a non-existent tunnel protocol.
    
    Fixes: 5f24f41e8ea6 ("xfrm: Remove inner/outer modes from input path")
    Reported-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
zonefs: Improve error handling [+ + +]
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Thu Feb 8 17:26:59 2024 +0900

    zonefs: Improve error handling
    
    commit 14db5f64a971fce3d8ea35de4dfc7f443a3efb92 upstream.
    
    Write error handling is racy and can sometime lead to the error recovery
    path wrongly changing the inode size of a sequential zone file to an
    incorrect value  which results in garbage data being readable at the end
    of a file. There are 2 problems:
    
    1) zonefs_file_dio_write() updates a zone file write pointer offset
       after issuing a direct IO with iomap_dio_rw(). This update is done
       only if the IO succeed for synchronous direct writes. However, for
       asynchronous direct writes, the update is done without waiting for
       the IO completion so that the next asynchronous IO can be
       immediately issued. However, if an asynchronous IO completes with a
       failure right before the i_truncate_mutex lock protecting the update,
       the update may change the value of the inode write pointer offset
       that was corrected by the error path (zonefs_io_error() function).
    
    2) zonefs_io_error() is called when a read or write error occurs. This
       function executes a report zone operation using the callback function
       zonefs_io_error_cb(), which does all the error recovery handling
       based on the current zone condition, write pointer position and
       according to the mount options being used. However, depending on the
       zoned device being used, a report zone callback may be executed in a
       context that is different from the context of __zonefs_io_error(). As
       a result, zonefs_io_error_cb() may be executed without the inode
       truncate mutex lock held, which can lead to invalid error processing.
    
    Fix both problems as follows:
    - Problem 1: Perform the inode write pointer offset update before a
      direct write is issued with iomap_dio_rw(). This is safe to do as
      partial direct writes are not supported (IOMAP_DIO_PARTIAL is not
      set) and any failed IO will trigger the execution of zonefs_io_error()
      which will correct the inode write pointer offset to reflect the
      current state of the one on the device.
    - Problem 2: Change zonefs_io_error_cb() into zonefs_handle_io_error()
      and call this function directly from __zonefs_io_error() after
      obtaining the zone information using blkdev_report_zones() with a
      simple callback function that copies to a local stack variable the
      struct blk_zone obtained from the device. This ensures that error
      handling is performed holding the inode truncate mutex.
      This change also simplifies error handling for conventional zone files
      by bypassing the execution of report zones entirely. This is safe to
      do because the condition of conventional zones cannot be read-only or
      offline and conventional zone files are always fully mapped with a
      constant file size.
    
    Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Fixes: 8dcc1a9d90c1 ("fs: New zonefs file system")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>