Changelog in Linux kernel 6.9.10

 
ACPI: processor_idle: Fix invalid comparison with insertion sort for latency [+ + +]
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Date:   Tue Jul 2 04:56:39 2024 +0800

    ACPI: processor_idle: Fix invalid comparison with insertion sort for latency
    
    commit 233323f9b9f828cd7cd5145ad811c1990b692542 upstream.
    
    The acpi_cst_latency_cmp() comparison function currently used for
    sorting C-state latencies does not satisfy transitivity, causing
    incorrect sorting results.
    
    Specifically, if there are two valid acpi_processor_cx elements A and B
    and one invalid element C, it may occur that A < B, A = C, and B = C.
    Sorting algorithms assume that if A < B and A = C, then C < B, leading
    to incorrect ordering.
    
    Given the small size of the array (<=8), we replace the library sort
    function with a simple insertion sort that properly ignores invalid
    elements and sorts valid ones based on latency. This change ensures
    correct ordering of the C-state latencies.
    
    Fixes: 65ea8f2c6e23 ("ACPI: processor idle: Fix up C-state latency if not ordered")
    Reported-by: Julian Sikorski <belegdol@gmail.com>
    Closes: https://lore.kernel.org/lkml/70674dc7-5586-4183-8953-8095567e73df@gmail.com
    Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
    Tested-by: Julian Sikorski <belegdol@gmail.com>
    Cc: All applicable <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240701205639.117194-1-visitorckw@gmail.com
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ALSA: hda/realtek: add quirk for Clevo V5[46]0TU [+ + +]
Author: Michał Kopeć <michal.kopec@3mdeb.com>
Date:   Mon Jul 1 13:10:09 2024 +0200

    ALSA: hda/realtek: add quirk for Clevo V5[46]0TU
    
    commit e1c6db864599be341cd3bcc041540383215ce05e upstream.
    
    Apply quirk to fix combo jack detection on a new Clevo model: V5[46]0TU
    
    Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240701111010.1496569-1-michal.kopec@3mdeb.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 250 G7 [+ + +]
Author: Nazar Bilinskyi <nbilinskyi@gmail.com>
Date:   Tue Jul 9 11:05:46 2024 +0300

    ALSA: hda/realtek: Enable Mute LED on HP 250 G7
    
    commit b46953029c52bd3a3306ff79f631418b75384656 upstream.
    
    HP 250 G7 has a mute LED that can be made to work using quirk
    ALC269_FIXUP_HP_LINE1_MIC1_LED. Enable already existing quirk.
    
    Signed-off-by: Nazar Bilinskyi <nbilinskyi@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240709080546.18344-1-nbilinskyi@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Limit mic boost on VAIO PRO PX [+ + +]
Author: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Date:   Fri Jul 5 11:10:12 2024 -0300

    ALSA: hda/realtek: Limit mic boost on VAIO PRO PX
    
    commit 6db03b1929e207d2c6e84e75a9cd78124b3d6c6d upstream.
    
    The internal mic boost on the VAIO models VJFE-CL and VJFE-IL is too high.
    Fix this by applying the ALC269_FIXUP_LIMIT_INT_MIC_BOOST fixup to the machine
    to limit the gain.
    
    Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240705141012.5368-1-edson.drosdeck@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arm64: dts: allwinner: Fix PMIC interrupt number [+ + +]
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Thu May 16 00:48:52 2024 +0100

    arm64: dts: allwinner: Fix PMIC interrupt number
    
    [ Upstream commit 5b36166e599b5c1332a1147271d2130cece4bb24 ]
    
    The "r_intc" interrupt controller on the A64 uses a mapping scheme, so
    the first (and only) NMI interrupt #0 appears as interrupt number 32
    (cf. the top comment in drivers/irqchip/irq-sun6i-r.c).
    
    Fix that number in the interrupts property to properly forward PMIC
    interrupts to the CPU.
    
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Fixes: 4d39a8eb07eb ("arm64: dts: allwinner: Add Jide Remix Mini PC support")
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Link: https://lore.kernel.org/r/20240515234852.26929-1-andre.przywara@arm.com
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: qdu1000: Fix LLCC reg property [+ + +]
Author: Komal Bajaj <quic_kbajaj@quicinc.com>
Date:   Wed Jun 19 11:46:40 2024 +0530

    arm64: dts: qcom: qdu1000: Fix LLCC reg property
    
    [ Upstream commit af355e799b3dc3dd0ed8bf2143641af05d8cd3d4 ]
    
    The LLCC binding and driver was corrected to handle the stride
    varying between platforms. Switch to the new format to ensure
    accesses are done in the right place.
    
    Fixes: b0e0290bc47d ("arm64: dts: qcom: qdu1000: correct LLCC reg entries")
    Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
    Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20240619061641.5261-2-quic_kbajaj@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sa8775p: Correct IRQ number of EL2 non-secure physical timer [+ + +]
Author: Cong Zhang <quic_congzhan@quicinc.com>
Date:   Tue Jun 4 16:59:29 2024 +0800

    arm64: dts: qcom: sa8775p: Correct IRQ number of EL2 non-secure physical timer
    
    commit 41fca5930afb36453cc90d4002841edd9990d0ad upstream.
    
    The INTID of EL2 non-secure physical timer is 26. In linux, the IRQ
    number has a fixed 16 offset for PPIs. Therefore, the linux IRQ number
    of EL2 non-secure physical timer should be 10 (26 - 16).
    
    Fixes: 603f96d4c9d0 ("arm64: dts: qcom: add initial support for qcom sa8775p-ride")
    Signed-off-by: Cong Zhang <quic_congzhan@quicinc.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240604085929.49227-1-quic_congzhan@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sc8180x: Fix LLCC reg property again [+ + +]
Author: Bjorn Andersson <quic_bjorande@quicinc.com>
Date:   Sat May 25 10:44:11 2024 -0700

    arm64: dts: qcom: sc8180x: Fix LLCC reg property again
    
    [ Upstream commit 3df1627d8370a9c420b49743976b3eeba32afbbc ]
    
    Commit '74cf6675c35e ("arm64: dts: qcom: sc8180x: Fix LLCC reg
    property")' transitioned the SC8180X LLCC node to describe each memory
    region individually, but did not include all the regions.
    
    The result is that Linux fails to find the last regions, so extend the
    definition to cover all the blocks.
    
    This also corrects the related DeviceTree validation error.
    
    Fixes: 74cf6675c35e ("arm64: dts: qcom: sc8180x: Fix LLCC reg property")
    Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240525-sc8180x-llcc-reg-fixup-v1-1-0c13d4ea94f2@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc8280xp-x13s: fix touchscreen power on [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Tue May 7 16:48:19 2024 +0200

    arm64: dts: qcom: sc8280xp-x13s: fix touchscreen power on
    
    commit 7bfb6a4289b0a63d67ec7d4ce3018cb4a7442f6a upstream.
    
    The Elan eKTH5015M touch controller on the X13s requires a 300 ms delay
    before sending commands after having deasserted reset during power on.
    
    Switch to the Elan specific binding so that the OS can determine the
    required power-on sequence and make sure that the controller is always
    detected during boot.
    
    Note that the always-on 1.8 V supply (s10b) is not used by the
    controller directly and should not be described.
    
    Fixes: 32c231385ed4 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree")
    Cc: stable@vger.kernel.org      # 6.0
    Tested-by: Steev Klimaszewski <steev@kali.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20240507144821.12275-6-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sm6115: add iommu for sdhc_1 [+ + +]
Author: Caleb Connolly <caleb.connolly@linaro.org>
Date:   Wed Jun 19 22:33:38 2024 +0200

    arm64: dts: qcom: sm6115: add iommu for sdhc_1
    
    [ Upstream commit 94ea124aeefe1ef271263f176634034e22c49311 ]
    
    The first SDHC can do DMA like most other peripherals, add the missing
    iommus entry which is required to set this up.
    
    This may have been working on Linux before since the bootloader
    configures it and it may not be full torn down. But other software like
    U-Boot needs this to initialize the eMMC properly.
    
    Fixes: 97e563bf5ba1 ("arm64: dts: qcom: sm6115: Add basic soc dtsi")
    Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240619-rb2-fixes-v1-1-1d2b1d711969@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: x1e80100-*: Allocate some CMA buffers [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed May 22 13:40:09 2024 +0200

    arm64: dts: qcom: x1e80100-*: Allocate some CMA buffers
    
    [ Upstream commit 50b0516030fd549c9fd4498c9ac1f3a665521b2e ]
    
    In a fashion identical to commit 5f84c7c35d49 ("arm64: dts: qcom:
    sc8280xp: Define CMA region for CRD and X13s"), there exists a need for
    more than the default 32 MiB of CMA, namely for the ath12k_pci device.
    
    Reserve a 128MiB chunk to make boot-time failures like:
     cma: cma_alloc: reserved: alloc failed, req-size: 128 pages, ret: -12
    go away.
    
    Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts")
    Fixes: bd50b1f5b6f3 ("arm64: dts: qcom: x1e80100: Add Compute Reference Device")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20240522-topic-x1e_cma-v1-1-b69e3b467452@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: x1e80100-crd: fix DAI used for headset recording [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Tue Jun 11 16:25:55 2024 +0200

    arm64: dts: qcom: x1e80100-crd: fix DAI used for headset recording
    
    commit 74de2ecf1c418c96d2bffa7770953b8991425dd2 upstream.
    
    The SWR2 Soundwire instance has 1 output and 4 input ports, so for the
    headset recording (via the WCD9385 codec and the TX macro codec) we want
    to use the next DAI, not the first one (see qcom,dout-ports and
    qcom,din-ports for soundwire@6d30000 node).
    
    Original code was copied from other devices like SM8450 and SM8550.  On
    the SM8450 this was a correct setting, however on the SM8550 this worked
    probably only by coincidence, because the DTS defined no output ports on
    SWR2 Soundwire.
    
    This is a necessary fix for proper audio recording via analogue
    microphones connected to WCD9385 codec (e.g. headset AMIC2).
    
    Fixes: 4442a67eedc1 ("arm64: dts: qcom: x1e80100-crd: add sound card")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20240611142555.994675-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100-crd: fix WCD audio codec TX port mapping [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Tue Jun 11 16:25:54 2024 +0200

    arm64: dts: qcom: x1e80100-crd: fix WCD audio codec TX port mapping
    
    commit dfce1771680c70a437556bc81e3e1e22088b67de upstream.
    
    Starting with the LPASS v11 (SM8550 also X1E80100), there is an
    additional output port on SWR2 Soundwire instance, thus WCD9385 audio
    codec TX port mapping should be shifted by one.  This is a necessary fix
    for proper audio recording via analogue microphones connected to WCD9385
    codec (e.g. headset AMIC2).
    
    Fixes: 229c9ce0fd11 ("arm64: dts: qcom: x1e80100-crd: add WCD9385 Audio Codec")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20240611142555.994675-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: x1e80100: Fix PCIe 6a reg offsets and add MHI [+ + +]
Author: Abel Vesa <abel.vesa@linaro.org>
Date:   Tue Jun 4 18:20:24 2024 +0300

    arm64: dts: qcom: x1e80100: Fix PCIe 6a reg offsets and add MHI
    
    [ Upstream commit 8e99e770f7eab8f8127098df7824373c4b4e8b5c ]
    
    The actual size of the DBI region is 0xf20 and the start of the
    ELBI region is 0xf40, according to the documentation. So fix them.
    While at it, add the MHI region as well.
    
    Fixes: 5eb83fc10289 ("arm64: dts: qcom: x1e80100: Add PCIe nodes")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20240604-x1e80100-dts-fixes-pcie6a-v2-1-0b4d8c6256e5@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: davinci: Convert comma to semicolon [+ + +]
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Wed Jul 10 16:16:48 2024 +0800

    ARM: davinci: Convert comma to semicolon
    
    [ Upstream commit acc3815db1a02d654fbc19726ceaadca0d7dd81c ]
    
    Replace a comma between expression statements by a semicolon.
    
    Fixes: efc1bb8a6fd5 ("davinci: add power management support")
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: SOF: Intel: hda: fix null deref on system suspend entry [+ + +]
Author: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Date:   Thu Jul 4 10:57:08 2024 +0200

    ASoC: SOF: Intel: hda: fix null deref on system suspend entry
    
    [ Upstream commit 9065693dcc13f287b9e4991f43aee70cf5538fdd ]
    
    When system enters suspend with an active stream, SOF core
    calls hw_params_upon_resume(). On Intel platforms with HDA DMA used
    to manage the link DMA, this leads to call chain of
    
       hda_dsp_set_hw_params_upon_resume()
     -> hda_dsp_dais_suspend()
     -> hda_dai_suspend()
     -> hda_ipc4_post_trigger()
    
    A bug is hit in hda_dai_suspend() as hda_link_dma_cleanup() is run first,
    which clears hext_stream->link_substream, and then hda_ipc4_post_trigger()
    is called with a NULL snd_pcm_substream pointer.
    
    Fixes: 2b009fa0823c ("ASoC: SOF: Intel: hda: Unify DAI drv ops for IPC3 and IPC4")
    Link: https://github.com/thesofproject/linux/issues/5080
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://patch.msgid.link/20240704085708.371414-1-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Defer work in bpf_timer_cancel_and_free [+ + +]
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date:   Tue Jul 9 18:54:39 2024 +0000

    bpf: Defer work in bpf_timer_cancel_and_free
    
    [ Upstream commit a6fcd19d7eac1335eb76bc16b6a66b7f574d1d69 ]
    
    Currently, the same case as previous patch (two timer callbacks trying
    to cancel each other) can be invoked through bpf_map_update_elem as
    well, or more precisely, freeing map elements containing timers. Since
    this relies on hrtimer_cancel as well, it is prone to the same deadlock
    situation as the previous patch.
    
    It would be sufficient to use hrtimer_try_to_cancel to fix this problem,
    as the timer cannot be enqueued after async_cancel_and_free. Once
    async_cancel_and_free has been done, the timer must be reinitialized
    before it can be armed again. The callback running in parallel trying to
    arm the timer will fail, and freeing bpf_hrtimer without waiting is
    sufficient (given kfree_rcu), and bpf_timer_cb will return
    HRTIMER_NORESTART, preventing the timer from being rearmed again.
    
    However, there exists a UAF scenario where the callback arms the timer
    before entering this function, such that if cancellation fails (due to
    timer callback invoking this routine, or the target timer callback
    running concurrently). In such a case, if the timer expiration is
    significantly far in the future, the RCU grace period expiration
    happening before it will free the bpf_hrtimer state and along with it
    the struct hrtimer, that is enqueued.
    
    Hence, it is clear cancellation needs to occur after
    async_cancel_and_free, and yet it cannot be done inline due to deadlock
    issues. We thus modify bpf_timer_cancel_and_free to defer work to the
    global workqueue, adding a work_struct alongside rcu_head (both used at
    _different_ points of time, so can share space).
    
    Update existing code comments to reflect the new state of affairs.
    
    Fixes: b00628b1c7d5 ("bpf: Introduce bpf timers.")
    Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Link: https://lore.kernel.org/r/20240709185440.1104957-3-memxor@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fail bpf_timer_cancel when callback is being cancelled [+ + +]
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date:   Tue Jul 9 18:54:38 2024 +0000

    bpf: Fail bpf_timer_cancel when callback is being cancelled
    
    [ Upstream commit d4523831f07a267a943f0dde844bf8ead7495f13 ]
    
    Given a schedule:
    
    timer1 cb                       timer2 cb
    
    bpf_timer_cancel(timer2);       bpf_timer_cancel(timer1);
    
    Both bpf_timer_cancel calls would wait for the other callback to finish
    executing, introducing a lockup.
    
    Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps
    track of all in-flight cancellation requests for a given BPF timer.
    Whenever cancelling a BPF timer, we must check if we have outstanding
    cancellation requests, and if so, we must fail the operation with an
    error (-EDEADLK) since cancellation is synchronous and waits for the
    callback to finish executing. This implies that we can enter a deadlock
    situation involving two or more timer callbacks executing in parallel
    and attempting to cancel one another.
    
    Note that we avoid incrementing the cancelling counter for the target
    timer (the one being cancelled) if bpf_timer_cancel is not invoked from
    a callback, to avoid spurious errors. The whole point of detecting
    cur->cancelling and returning -EDEADLK is to not enter a busy wait loop
    (which may or may not lead to a lockup). This does not apply in case the
    caller is in a non-callback context, the other side can continue to
    cancel as it sees fit without running into errors.
    
    Background on prior attempts:
    
    Earlier versions of this patch used a bool 'cancelling' bit and used the
    following pattern under timer->lock to publish cancellation status.
    
    lock(t->lock);
    t->cancelling = true;
    mb();
    if (cur->cancelling)
            return -EDEADLK;
    unlock(t->lock);
    hrtimer_cancel(t->timer);
    t->cancelling = false;
    
    The store outside the critical section could overwrite a parallel
    requests t->cancelling assignment to true, to ensure the parallely
    executing callback observes its cancellation status.
    
    It would be necessary to clear this cancelling bit once hrtimer_cancel
    is done, but lack of serialization introduced races. Another option was
    explored where bpf_timer_start would clear the bit when (re)starting the
    timer under timer->lock. This would ensure serialized access to the
    cancelling bit, but may allow it to be cleared before in-flight
    hrtimer_cancel has finished executing, such that lockups can occur
    again.
    
    Thus, we choose an atomic counter to keep track of all outstanding
    cancellation requests and use it to prevent lockups in case callbacks
    attempt to cancel each other while executing in parallel.
    
    Reported-by: Dohyun Kim <dohyunkim@google.com>
    Reported-by: Neel Natu <neelnatu@google.com>
    Fixes: b00628b1c7d5 ("bpf: Introduce bpf timers.")
    Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Link: https://lore.kernel.org/r/20240709185440.1104957-2-memxor@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: fix order of args in call to bpf_map_kvcalloc [+ + +]
Author: Mohammad Shehar Yaar Tausif <sheharyaar48@gmail.com>
Date:   Wed Jul 10 12:05:22 2024 +0200

    bpf: fix order of args in call to bpf_map_kvcalloc
    
    [ Upstream commit af253aef183a31ce62d2e39fc520b0ebfb562bb9 ]
    
    The original function call passed size of smap->bucket before the number of
    buckets which raises the error 'calloc-transposed-args' on compilation.
    
    Vlastimil Babka added:
    
    The order of parameters can be traced back all the way to 6ac99e8f23d4
    ("bpf: Introduce bpf sk local storage") accross several refactorings,
    and that's why the commit is used as a Fixes: tag.
    
    In v6.10-rc1, a different commit 2c321f3f70bc ("mm: change inlined
    allocation helpers to account at the call site") however exposed the
    order of args in a way that gcc-14 has enough visibility to start
    warning about it, because (in !CONFIG_MEMCG case) bpf_map_kvcalloc is
    then a macro alias for kvcalloc instead of a static inline wrapper.
    
    To sum up the warning happens when the following conditions are all met:
    
    - gcc-14 is used (didn't see it with gcc-13)
    - commit 2c321f3f70bc is present
    - CONFIG_MEMCG is not enabled in .config
    - CONFIG_WERROR turns this from a compiler warning to error
    
    Fixes: 6ac99e8f23d4 ("bpf: Introduce bpf sk local storage")
    Reviewed-by: Andrii Nakryiko <andrii@kernel.org>
    Tested-by: Christian Kujau <lists@nerdbynature.de>
    Signed-off-by: Mohammad Shehar Yaar Tausif <sheharyaar48@gmail.com>
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Link: https://lore.kernel.org/r/20240710100521.15061-2-vbabka@suse.cz
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix too early release of tcx_entry [+ + +]
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Mon Jul 8 15:31:29 2024 +0200

    bpf: Fix too early release of tcx_entry
    
    [ Upstream commit 1cb6f0bae50441f4b4b32a28315853b279c7404e ]
    
    Pedro Pinto and later independently also Hyunwoo Kim and Wongi Lee reported
    an issue that the tcx_entry can be released too early leading to a use
    after free (UAF) when an active old-style ingress or clsact qdisc with a
    shared tc block is later replaced by another ingress or clsact instance.
    
    Essentially, the sequence to trigger the UAF (one example) can be as follows:
    
      1. A network namespace is created
      2. An ingress qdisc is created. This allocates a tcx_entry, and
         &tcx_entry->miniq is stored in the qdisc's miniqp->p_miniq. At the
         same time, a tcf block with index 1 is created.
      3. chain0 is attached to the tcf block. chain0 must be connected to
         the block linked to the ingress qdisc to later reach the function
         tcf_chain0_head_change_cb_del() which triggers the UAF.
      4. Create and graft a clsact qdisc. This causes the ingress qdisc
         created in step 1 to be removed, thus freeing the previously linked
         tcx_entry:
    
         rtnetlink_rcv_msg()
           => tc_modify_qdisc()
             => qdisc_create()
               => clsact_init() [a]
             => qdisc_graft()
               => qdisc_destroy()
                 => __qdisc_destroy()
                   => ingress_destroy() [b]
                     => tcx_entry_free()
                       => kfree_rcu() // tcx_entry freed
    
      5. Finally, the network namespace is closed. This registers the
         cleanup_net worker, and during the process of releasing the
         remaining clsact qdisc, it accesses the tcx_entry that was
         already freed in step 4, causing the UAF to occur:
    
         cleanup_net()
           => ops_exit_list()
             => default_device_exit_batch()
               => unregister_netdevice_many()
                 => unregister_netdevice_many_notify()
                   => dev_shutdown()
                     => qdisc_put()
                       => clsact_destroy() [c]
                         => tcf_block_put_ext()
                           => tcf_chain0_head_change_cb_del()
                             => tcf_chain_head_change_item()
                               => clsact_chain_head_change()
                                 => mini_qdisc_pair_swap() // UAF
    
    There are also other variants, the gist is to add an ingress (or clsact)
    qdisc with a specific shared block, then to replace that qdisc, waiting
    for the tcx_entry kfree_rcu() to be executed and subsequently accessing
    the current active qdisc's miniq one way or another.
    
    The correct fix is to turn the miniq_active boolean into a counter. What
    can be observed, at step 2 above, the counter transitions from 0->1, at
    step [a] from 1->2 (in order for the miniq object to remain active during
    the replacement), then in [b] from 2->1 and finally [c] 1->0 with the
    eventual release. The reference counter in general ranges from [0,2] and
    it does not need to be atomic since all access to the counter is protected
    by the rtnl mutex. With this in place, there is no longer a UAF happening
    and the tcx_entry is freed at the correct time.
    
    Fixes: e420bed02507 ("bpf: Add fd-based tcx multi-prog infra with link support")
    Reported-by: Pedro Pinto <xten@osec.io>
    Co-developed-by: Pedro Pinto <xten@osec.io>
    Signed-off-by: Pedro Pinto <xten@osec.io>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Hyunwoo Kim <v4bel@theori.io>
    Cc: Wongi Lee <qwerty@theori.io>
    Cc: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://lore.kernel.org/r/20240708133130.11609-1-daniel@iogearbox.net
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: make timer data struct more generic [+ + +]
Author: Benjamin Tissoires <bentiss@kernel.org>
Date:   Sat Apr 20 11:09:01 2024 +0200

    bpf: make timer data struct more generic
    
    [ Upstream commit be2749beff62e0d63cf97fe63cabc79a68443139 ]
    
    To be able to add workqueues and reuse most of the timer code, we need
    to make bpf_hrtimer more generic.
    
    There is no code change except that the new struct gets a new u64 flags
    attribute. We are still below 2 cache lines, so this shouldn't impact
    the current running codes.
    
    The ordering is also changed. Everything related to async callback
    is now on top of bpf_hrtimer.
    
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Link: https://lore.kernel.org/r/20240420-bpf_wq-v2-1-6c986a5a741f@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Stable-dep-of: d4523831f07a ("bpf: Fail bpf_timer_cancel when callback is being cancelled")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: replace bpf_timer_init with a generic helper [+ + +]
Author: Benjamin Tissoires <bentiss@kernel.org>
Date:   Sat Apr 20 11:09:02 2024 +0200

    bpf: replace bpf_timer_init with a generic helper
    
    [ Upstream commit 56b4a177ae6322173360a93ea828ad18570a5a14 ]
    
    No code change except for the new flags argument being stored in the
    local data struct.
    
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Link: https://lore.kernel.org/r/20240420-bpf_wq-v2-2-6c986a5a741f@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Stable-dep-of: d4523831f07a ("bpf: Fail bpf_timer_cancel when callback is being cancelled")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cachefiles: add missing lock protection when polling [+ + +]
Author: Jingbo Xu <jefflexu@linux.alibaba.com>
Date:   Fri Jun 28 14:29:30 2024 +0800

    cachefiles: add missing lock protection when polling
    
    [ Upstream commit cf5bb09e742a9cf6349127e868329a8f69b7a014 ]
    
    Add missing lock protection in poll routine when iterating xarray,
    otherwise:
    
    Even with RCU read lock held, only the slot of the radix tree is
    ensured to be pinned there, while the data structure (e.g. struct
    cachefiles_req) stored in the slot has no such guarantee.  The poll
    routine will iterate the radix tree and dereference cachefiles_req
    accordingly.  Thus RCU read lock is not adequate in this case and
    spinlock is needed here.
    
    Fixes: b817e22b2e91 ("cachefiles: narrow the scope of triggering EPOLLIN events in ondemand mode")
    Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Link: https://lore.kernel.org/r/20240628062930.2467993-10-libaokun@huaweicloud.com
    Acked-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Jia Zhu <zhujia.zj@bytedance.com>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cachefiles: cancel all requests for the object that is being dropped [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Fri Jun 28 14:29:27 2024 +0800

    cachefiles: cancel all requests for the object that is being dropped
    
    [ Upstream commit 751f524635a4f076117d714705eeddadaf6748ee ]
    
    Because after an object is dropped, requests for that object are useless,
    cancel them to avoid causing other problems.
    
    This prepares for the later addition of cancel_work_sync(). After the
    reopen requests is generated, cancel it to avoid cancel_work_sync()
    blocking by waiting for daemon to complete the reopen requests.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Link: https://lore.kernel.org/r/20240628062930.2467993-7-libaokun@huaweicloud.com
    Acked-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Reviewed-by: Jia Zhu <zhujia.zj@bytedance.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Stable-dep-of: 12e009d60852 ("cachefiles: wait for ondemand_object_worker to finish when dropping object")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cachefiles: cyclic allocation of msg_id to avoid reuse [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Fri Jun 28 14:29:29 2024 +0800

    cachefiles: cyclic allocation of msg_id to avoid reuse
    
    [ Upstream commit 19f4f399091478c95947f6bd7ad61622300c30d9 ]
    
    Reusing the msg_id after a maliciously completed reopen request may cause
    a read request to remain unprocessed and result in a hung, as shown below:
    
           t1       |      t2       |      t3
    -------------------------------------------------
    cachefiles_ondemand_select_req
     cachefiles_ondemand_object_is_close(A)
     cachefiles_ondemand_set_object_reopening(A)
     queue_work(fscache_object_wq, &info->work)
                    ondemand_object_worker
                     cachefiles_ondemand_init_object(A)
                      cachefiles_ondemand_send_req(OPEN)
                        // get msg_id 6
                        wait_for_completion(&req_A->done)
    cachefiles_ondemand_daemon_read
     // read msg_id 6 req_A
     cachefiles_ondemand_get_fd
     copy_to_user
                                    // Malicious completion msg_id 6
                                    copen 6,-1
                                    cachefiles_ondemand_copen
                                     complete(&req_A->done)
                                     // will not set the object to close
                                     // because ondemand_id && fd is valid.
    
                    // ondemand_object_worker() is done
                    // but the object is still reopening.
    
                                    // new open req_B
                                    cachefiles_ondemand_init_object(B)
                                     cachefiles_ondemand_send_req(OPEN)
                                     // reuse msg_id 6
    process_open_req
     copen 6,A.size
     // The expected failed copen was executed successfully
    
    Expect copen to fail, and when it does, it closes fd, which sets the
    object to close, and then close triggers reopen again. However, due to
    msg_id reuse resulting in a successful copen, the anonymous fd is not
    closed until the daemon exits. Therefore read requests waiting for reopen
    to complete may trigger hung task.
    
    To avoid this issue, allocate the msg_id cyclically to avoid reusing the
    msg_id for a very short duration of time.
    
    Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie")
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Link: https://lore.kernel.org/r/20240628062930.2467993-9-libaokun@huaweicloud.com
    Acked-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Reviewed-by: Jia Zhu <zhujia.zj@bytedance.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cachefiles: propagate errors from vfs_getxattr() to avoid infinite loop [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Fri Jun 28 14:29:25 2024 +0800

    cachefiles: propagate errors from vfs_getxattr() to avoid infinite loop
    
    [ Upstream commit 0ece614a52bc9d219b839a6a29282b30d10e0c48 ]
    
    In cachefiles_check_volume_xattr(), the error returned by vfs_getxattr()
    is not passed to ret, so it ends up returning -ESTALE, which leads to an
    endless loop as follows:
    
    cachefiles_acquire_volume
    retry:
      ret = cachefiles_check_volume_xattr
        ret = -ESTALE
        xlen = vfs_getxattr // return -EIO
        // The ret is not updated when xlen < 0, so -ESTALE is returned.
        return ret
      // Supposed to jump out of the loop at this judgement.
      if (ret != -ESTALE)
          goto error_dir;
      cachefiles_bury_object
        //  EIO causes rename failure
      goto retry;
    
    Hence propagate the error returned by vfs_getxattr() to avoid the above
    issue. Do the same in cachefiles_check_auxdata().
    
    Fixes: 32e150037dce ("fscache, cachefiles: Store the volume coherency data")
    Fixes: 72b957856b0c ("cachefiles: Implement metadata/coherency data storage in xattrs")
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Link: https://lore.kernel.org/r/20240628062930.2467993-5-libaokun@huaweicloud.com
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cachefiles: stop sending new request when dropping object [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Fri Jun 28 14:29:26 2024 +0800

    cachefiles: stop sending new request when dropping object
    
    [ Upstream commit b2415d1f4566b6939acacc69637eaa57815829c1 ]
    
    Added CACHEFILES_ONDEMAND_OBJSTATE_DROPPING indicates that the cachefiles
    object is being dropped, and is set after the close request for the dropped
    object completes, and no new requests are allowed to be sent after this
    state.
    
    This prepares for the later addition of cancel_work_sync(). It prevents
    leftover reopen requests from being sent, to avoid processing unnecessary
    requests and to avoid cancel_work_sync() blocking by waiting for daemon to
    complete the reopen requests.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Link: https://lore.kernel.org/r/20240628062930.2467993-6-libaokun@huaweicloud.com
    Acked-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Reviewed-by: Jia Zhu <zhujia.zj@bytedance.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Stable-dep-of: 12e009d60852 ("cachefiles: wait for ondemand_object_worker to finish when dropping object")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cachefiles: wait for ondemand_object_worker to finish when dropping object [+ + +]
Author: Hou Tao <houtao1@huawei.com>
Date:   Fri Jun 28 14:29:28 2024 +0800

    cachefiles: wait for ondemand_object_worker to finish when dropping object
    
    [ Upstream commit 12e009d60852f7bce0afc373ca0b320f14150418 ]
    
    When queuing ondemand_object_worker() to re-open the object,
    cachefiles_object is not pinned. The cachefiles_object may be freed when
    the pending read request is completed intentionally and the related
    erofs is umounted. If ondemand_object_worker() runs after the object is
    freed, it will incur use-after-free problem as shown below.
    
    process A  processs B  process C  process D
    
    cachefiles_ondemand_send_req()
    // send a read req X
    // wait for its completion
    
               // close ondemand fd
               cachefiles_ondemand_fd_release()
               // set object as CLOSE
    
                           cachefiles_ondemand_daemon_read()
                           // set object as REOPENING
                           queue_work(fscache_wq, &info->ondemand_work)
    
                                    // close /dev/cachefiles
                                    cachefiles_daemon_release
                                    cachefiles_flush_reqs
                                    complete(&req->done)
    
    // read req X is completed
    // umount the erofs fs
    cachefiles_put_object()
    // object will be freed
    cachefiles_ondemand_deinit_obj_info()
    kmem_cache_free(object)
                           // both info and object are freed
                           ondemand_object_worker()
    
    When dropping an object, it is no longer necessary to reopen the object,
    so use cancel_work_sync() to cancel or wait for ondemand_object_worker()
    to finish.
    
    Fixes: 0a7e54c1959c ("cachefiles: resend an open request if the read request's object is closed")
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Link: https://lore.kernel.org/r/20240628062930.2467993-8-libaokun@huaweicloud.com
    Acked-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Jia Zhu <zhujia.zj@bytedance.com>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cachestat: do not flush stats in recency check [+ + +]
Author: Nhat Pham <nphamcs@gmail.com>
Date:   Thu Jun 27 13:17:37 2024 -0700

    cachestat: do not flush stats in recency check
    
    commit 5a4d8944d6b1e1aaaa83ea42c116b520b4ed0394 upstream.
    
    syzbot detects that cachestat() is flushing stats, which can sleep, in its
    RCU read section (see [1]).  This is done in the workingset_test_recent()
    step (which checks if the folio's eviction is recent).
    
    Move the stat flushing step to before the RCU read section of cachestat,
    and skip stat flushing during the recency check.
    
    [1]: https://lore.kernel.org/cgroups/000000000000f71227061bdf97e0@google.com/
    
    Link: https://lkml.kernel.org/r/20240627201737.3506959-1-nphamcs@gmail.com
    Fixes: b00684722262 ("mm: workingset: move the stats flush into workingset_test_recent()")
    Signed-off-by: Nhat Pham <nphamcs@gmail.com>
    Reported-by: syzbot+b7f13b2d0cc156edf61a@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/cgroups/000000000000f71227061bdf97e0@google.com/
    Debugged-by: Johannes Weiner <hannes@cmpxchg.org>
    Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: "Huang, Ying" <ying.huang@intel.com>
    Cc: Kairui Song <kasong@tencent.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Ryan Roberts <ryan.roberts@arm.com>
    Cc: Yosry Ahmed <yosryahmed@google.com>
    Cc: <stable@vger.kernel.org>    [6.8+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cifs: fix setting SecurityFlags to true [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Tue Jul 9 18:07:35 2024 -0500

    cifs: fix setting SecurityFlags to true
    
    commit d2346e2836318a227057ed41061114cbebee5d2a upstream.
    
    If you try to set /proc/fs/cifs/SecurityFlags to 1 it
    will set them to CIFSSEC_MUST_NTLMV2 which no longer is
    relevant (the less secure ones like lanman have been removed
    from cifs.ko) and is also missing some flags (like for
    signing and encryption) and can even cause mount to fail,
    so change this to set it to Kerberos in this case.
    
    Also change the description of the SecurityFlags to remove mention
    of flags which are no longer supported.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cpufreq: ACPI: Mark boost policy as enabled when setting boost [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed Jun 26 15:47:23 2024 -0500

    cpufreq: ACPI: Mark boost policy as enabled when setting boost
    
    commit d92467ad9d9ee63a700934b9228a989ef671d511 upstream.
    
    When boost is set for CPUs using acpi-cpufreq, the policy is not
    updated which can cause boost to be incorrectly not reported.
    
    Fixes: 218a06a79d9a ("cpufreq: Support per-policy performance boost")
    Link: https://patch.msgid.link/20240626204723.6237-2-mario.limonciello@amd.com
    Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
    Suggested-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cpufreq: Allow drivers to advertise boost enabled [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed Jun 26 15:47:22 2024 -0500

    cpufreq: Allow drivers to advertise boost enabled
    
    commit 102fa9c4b439ca3bd93d13fb53f5b7592d96a109 upstream.
    
    The behavior introduced in commit f37a4d6b4a2c ("cpufreq: Fix per-policy
    boost behavior on SoCs using cpufreq_boost_set_sw()") sets up the boost
    policy incorrectly when boost has been enabled by the platform firmware
    initially even if a driver sets the policy up.
    
    This is because policy_has_boost_freq() assumes that there is a frequency
    table set up by the driver and that the boost frequencies are advertised
    in that table. This assumption doesn't work for acpi-cpufreq or
    amd-pstate. Only use this check to enable boost if it's not already
    enabled instead of also disabling it if alreayd enabled.
    
    Fixes: f37a4d6b4a2c ("cpufreq: Fix per-policy boost behavior on SoCs using cpufreq_boost_set_sw()")
    Link: https://patch.msgid.link/20240626204723.6237-1-mario.limonciello@amd.com
    Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com>
    Reviewed-by: Dhruva Gole <d-gole@ti.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
    Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
    Suggested-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dsa: lan9303: Fix mapping between DSA port number and PHY address [+ + +]
Author: Christian Eggers <ceggers@arri.de>
Date:   Wed Jul 3 16:57:17 2024 +0200

    dsa: lan9303: Fix mapping between DSA port number and PHY address
    
    [ Upstream commit 0005b2dc43f96b93fc5b0850d7ca3f7aeac9129c ]
    
    The 'phy' parameter supplied to lan9303_phy_read/_write was sometimes a
    DSA port number and sometimes a PHY address. This isn't a problem as
    long as they are equal.  But if the external phy_addr_sel_strap pin is
    wired to 'high', the PHY addresses change from 0-1-2 to 1-2-3 (CPU,
    slave0, slave1).  In this case, lan9303_phy_read/_write must translate
    between DSA port numbers and the corresponding PHY address.
    
    Fixes: a1292595e006 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303")
    Signed-off-by: Christian Eggers <ceggers@arri.de>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://patch.msgid.link/20240703145718.19951-1-ceggers@arri.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ethtool: netlink: do not return SQI value if link is down [+ + +]
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Tue Jul 9 08:19:43 2024 +0200

    ethtool: netlink: do not return SQI value if link is down
    
    [ Upstream commit c184cf94e73b04ff7048d045f5413899bc664788 ]
    
    Do not attach SQI value if link is down. "SQI values are only valid if
    link-up condition is present" per OpenAlliance specification of
    100Base-T1 Interoperability Test suite [1]. The same rule would apply
    for other link types.
    
    [1] https://opensig.org/automotive-ethernet-specifications/#
    
    Fixes: 806602191592 ("ethtool: provide UAPI for PHY Signal Quality Index (SQI)")
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Woojung Huh <woojung.huh@microchip.com>
    Link: https://patch.msgid.link/20240709061943.729381-1-o.rempel@pengutronix.de
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: avoid ptr null pointer dereference [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Tue Jul 16 17:29:29 2024 +0800

    ext4: avoid ptr null pointer dereference
    
    When commit 13df4d44a3aa ("ext4: fix slab-out-of-bounds in
    ext4_mb_find_good_group_avg_frag_lists()") was backported to stable, the
    commit f536808adcc3 ("ext4: refactor out ext4_generic_attr_store()") that
    uniformly determines if the ptr is null is not merged in, so it needs to
    be judged whether ptr is null or not in each case of the switch, otherwise
    null pointer dereferencing may occur.
    
    Fixes: b829687ae122 ("ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists()")
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
filelock: fix potential use-after-free in posix_lock_inode [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Tue Jul 2 18:44:48 2024 -0400

    filelock: fix potential use-after-free in posix_lock_inode
    
    [ Upstream commit 1b3ec4f7c03d4b07bad70697d7e2f4088d2cfe92 ]
    
    Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().
    The request pointer had been changed earlier to point to a lock entry
    that was added to the inode's list. However, before the tracepoint could
    fire, another task raced in and freed that lock.
    
    Fix this by moving the tracepoint inside the spinlock, which should
    ensure that this doesn't happen.
    
    Fixes: 74f6f5912693 ("locks: fix KASAN: use-after-free in trace_event_raw_event_filelock_lock")
    Link: https://lore.kernel.org/linux-fsdevel/724ffb0a2962e912ea62bb0515deadf39c325112.camel@kernel.org/
    Reported-by: Light Hsieh (謝明燈) <Light.Hsieh@mediatek.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Link: https://lore.kernel.org/r/20240702-filelock-6-10-v1-1-96e766aadc98@kernel.org
    Reviewed-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
filemap: replace pte_offset_map() with pte_offset_map_nolock() [+ + +]
Author: ZhangPeng <zhangpeng362@huawei.com>
Date:   Wed Mar 13 09:29:13 2024 +0800

    filemap: replace pte_offset_map() with pte_offset_map_nolock()
    
    commit 24be02a42181f0707be0498045c4c4b13273b16d upstream.
    
    The vmf->ptl in filemap_fault_recheck_pte_none() is still set from
    handle_pte_fault().  But at the same time, we did a pte_unmap(vmf->pte).
    After a pte_unmap(vmf->pte) unmap and rcu_read_unlock(), the page table
    may be racily changed and vmf->ptl maybe fails to protect the actual page
    table.  Fix this by replacing pte_offset_map() with
    pte_offset_map_nolock().
    
    As David said, the PTL pointer might be stale so if we continue to use
    it infilemap_fault_recheck_pte_none(), it might trigger UAF.  Also, if
    the PTL fails, the issue fixed by commit 58f327f2ce80 ("filemap: avoid
    unnecessary major faults in filemap_fault()") might reappear.
    
    Link: https://lkml.kernel.org/r/20240313012913.2395414-1-zhangpeng362@huawei.com
    Fixes: 58f327f2ce80 ("filemap: avoid unnecessary major faults in filemap_fault()")
    Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
    Suggested-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Cc: "Huang, Ying" <ying.huang@intel.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Nanyong Sun <sunnanyong@huawei.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: Yin Fengwei <fengwei.yin@intel.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
firmware: cs_dsp: Fix overflow checking of wmfw header [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Thu Jun 27 15:14:29 2024 +0100

    firmware: cs_dsp: Fix overflow checking of wmfw header
    
    [ Upstream commit 3019b86bce16fbb5bc1964f3544d0ce7d0137278 ]
    
    Fix the checking that firmware file buffer is large enough for the
    wmfw header, to prevent overrunning the buffer.
    
    The original code tested that the firmware data buffer contained
    enough bytes for the sums of the size of the structs
    
            wmfw_header + wmfw_adsp1_sizes + wmfw_footer
    
    But wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and
    Halo Core the equivalent struct is wmfw_adsp2_sizes, which is
    4 bytes longer. So the length check didn't guarantee that there
    are enough bytes in the firmware buffer for a header with
    wmfw_adsp2_sizes.
    
    This patch splits the length check into three separate parts. Each
    of the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked
    separately before they are used.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs")
    Link: https://patch.msgid.link/20240627141432.93056-2-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Thu Jun 27 15:14:32 2024 +0100

    firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers
    
    [ Upstream commit 2163aff6bebbb752edf73f79700f5e2095f3559e ]
    
    Check that all fields of a V2 algorithm header fit into the available
    firmware data buffer.
    
    The wmfw V2 format introduced variable-length strings in the algorithm
    block header. This means the overall header length is variable, and the
    position of most fields varies depending on the length of the string
    fields. Each field must be checked to ensure that it does not overflow
    the firmware data buffer.
    
    As this ia bugfix patch, the fixes avoid making any significant change to
    the existing code. This makes it easier to review and less likely to
    introduce new bugs.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs")
    Link: https://patch.msgid.link/20240627141432.93056-5-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: cs_dsp: Return error if block header overflows file [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Thu Jun 27 15:14:30 2024 +0100

    firmware: cs_dsp: Return error if block header overflows file
    
    [ Upstream commit 959fe01e85b7241e3ec305d657febbe82da16a02 ]
    
    Return an error from cs_dsp_power_up() if a block header is longer
    than the amount of data left in the file.
    
    The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loop
    while there was enough data left in the file for a valid region. This
    protected against overrunning the end of the file data, but it didn't
    abort the file processing with an error.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs")
    Link: https://patch.msgid.link/20240627141432.93056-3-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Mon Jul 8 15:48:55 2024 +0100

    firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files
    
    [ Upstream commit 680e126ec0400f6daecf0510c5bb97a55779ff03 ]
    
    Use strnlen() instead of strlen() on the algorithm and coefficient name
    string arrays in V1 wmfw files.
    
    In V1 wmfw files the name is a NUL-terminated string in a fixed-size
    array. cs_dsp should protect against overrunning the array if the NUL
    terminator is missing.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs")
    Link: https://patch.msgid.link/20240708144855.385332-1-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: cs_dsp: Validate payload length before processing block [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Thu Jun 27 15:14:31 2024 +0100

    firmware: cs_dsp: Validate payload length before processing block
    
    [ Upstream commit 6598afa9320b6ab13041616950ca5f8f938c0cf1 ]
    
    Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load()
    to be done before the block is processed.
    
    The check that the length of a block payload does not exceed the number
    of remaining bytes in the firwmware file buffer was being done near the
    end of the loop iteration. However, some code before that check used the
    length field without validating it.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs")
    Link: https://patch.msgid.link/20240627141432.93056-4-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Fix userfaultfd_api to return EINVAL as expected [+ + +]
Author: Audra Mitchell <audra@redhat.com>
Date:   Wed Jun 26 09:05:11 2024 -0400

    Fix userfaultfd_api to return EINVAL as expected
    
    commit 1723f04caacb32cadc4e063725d836a0c4450694 upstream.
    
    Currently if we request a feature that is not set in the Kernel config we
    fail silently and return all the available features.  However, the man
    page indicates we should return an EINVAL.
    
    We need to fix this issue since we can end up with a Kernel warning should
    a program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with
    the config not set with this feature.
    
     [  200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660
     [  200.820738] Modules linked in:
     [  200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8
     [  200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022
     [  200.885052] RIP: 0010:zap_pte_range+0x43d/0x660
    
    Link: https://lkml.kernel.org/r/20240626130513.120193-1-audra@redhat.com
    Fixes: e06f1e1dd499 ("userfaultfd: wp: enabled write protection in userfaultfd API")
    Signed-off-by: Audra Mitchell <audra@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Rafael Aquini <raquini@redhat.com>
    Cc: Shaohua Li <shli@fb.com>
    Cc: Shuah Khan <shuah@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>

 
fs/dcache: Re-use value stored to dentry->d_flags instead of re-reading [+ + +]
Author: linke li <lilinke99@qq.com>
Date:   Wed Apr 3 10:10:08 2024 +0800

    fs/dcache: Re-use value stored to dentry->d_flags instead of re-reading
    
    [ Upstream commit 8bfb40be31ddea0cb4664b352e1797cfe6c91976 ]
    
    Currently, the __d_clear_type_and_inode() writes the value flags to
    dentry->d_flags, then immediately re-reads it in order to use it in a if
    statement. This re-read is useless because no other update to
    dentry->d_flags can occur at this point.
    
    This commit therefore re-use flags in the if statement instead of
    re-reading dentry->d_flags.
    
    Signed-off-by: linke li <lilinke99@qq.com>
    Link: https://lore.kernel.org/r/tencent_5E187BD0A61BA28605E85405F15228254D0A@qq.com
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Stable-dep-of: aabfe57ebaa7 ("vfs: don't mod negative dentry count when on shrinker list")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hpet: Support 32-bit userspace [+ + +]
Author: He Zhe <zhe.he@windriver.com>
Date:   Thu Jun 6 20:39:08 2024 +0800

    hpet: Support 32-bit userspace
    
    commit 4e60131d0d36af65ab9c9144f4f163fe97ae36e8 upstream.
    
    hpet_compat_ioctl and read file operations failed to handle parameters from
    32-bit userspace and thus samples/timers/hpet_example.c fails as below.
    
    root@intel-x86-64:~# ./hpet_example-32.out poll /dev/hpet 1 2
    -hpet: executing poll
    hpet_poll: HPET_IRQFREQ failed
    
    This patch fixes cmd and arg handling in hpet_compat_ioctl and adds compat
    handling for 32-bit userspace in hpet_read.
    
    hpet_example now shows that it works for both 64-bit and 32-bit.
    
    root@intel-x86-64:~# ./hpet_example-32.out poll /dev/hpet 1 2
    -hpet: executing poll
    hpet_poll: info.hi_flags 0x0
    hpet_poll: expired time = 0xf4298
    hpet_poll: revents = 0x1
    hpet_poll: data 0x1
    hpet_poll: expired time = 0xf4235
    hpet_poll: revents = 0x1
    hpet_poll: data 0x1
    root@intel-x86-64:~# ./hpet_example-64.out poll /dev/hpet 1 2
    -hpet: executing poll
    hpet_poll: info.hi_flags 0x0
    hpet_poll: expired time = 0xf42a1
    hpet_poll: revents = 0x1
    hpet_poll: data 0x1
    hpet_poll: expired time = 0xf4232
    hpet_poll: revents = 0x1
    hpet_poll: data 0x1
    
    Cc: stable@vger.kernel.org
    Signed-off-by: He Zhe <zhe.he@windriver.com>
    Fixes: 54066a57c584 ("hpet: kill BKL, add compat_ioctl")
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240606123908.738733-1-zhe.he@windriver.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i2c: mark HostNotify target address as used [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Wed Jul 10 10:55:07 2024 +0200

    i2c: mark HostNotify target address as used
    
    [ Upstream commit bd9f5348089b65612e5ca976e2ae22f005340331 ]
    
    I2C core handles the local target for receiving HostNotify alerts. There
    is no separate driver bound to that address. That means userspace can
    access it if desired, leading to further complications if controllers
    are not capable of reading their own local target. Bind the local target
    to the dummy driver so it will be marked as "handled by the kernel" if
    the HostNotify feature is used. That protects aginst userspace access
    and prevents other drivers binding to it.
    
    Fixes: 2a71593da34d ("i2c: smbus: add core function handling SMBus host-notify")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: rcar: bring hardware to known state when probing [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Sun Jul 7 10:28:46 2024 +0200

    i2c: rcar: bring hardware to known state when probing
    
    [ Upstream commit 4e36c0f20cb1c74c7bd7ea31ba432c1c4a989031 ]
    
    When probing, the hardware is not brought into a known state. This may
    be a problem when a hypervisor restarts Linux without resetting the
    hardware, leaving an old state running. Make sure the hardware gets
    initialized, especially interrupts should be cleared and disabled.
    
    Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
    Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Closes: https://lore.kernel.org/r/20240702045535.2000393-1-dirk.behme@de.bosch.com
    Fixes: 6ccbe607132b ("i2c: add Renesas R-Car I2C driver")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: rcar: clear NO_RXDMA flag after resetting [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Wed Jul 10 13:03:00 2024 +0200

    i2c: rcar: clear NO_RXDMA flag after resetting
    
    [ Upstream commit fea6b5ebb71a2830b042e42de7ae255017ac3ce8 ]
    
    We should allow RXDMA only if the reset was really successful, so clear
    the flag after the reset call.
    
    Fixes: 0e864b552b23 ("i2c: rcar: reset controller is mandatory for Gen3+")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: rcar: ensure Gen3+ reset does not disturb local targets [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Thu Jul 11 10:30:44 2024 +0200

    i2c: rcar: ensure Gen3+ reset does not disturb local targets
    
    [ Upstream commit ea5ea84c9d3570dc06e8fc5ee2273eaa584aa3ac ]
    
    R-Car Gen3+ needs a reset before every controller transfer. That erases
    configuration of a potentially in parallel running local target
    instance. To avoid this disruption, avoid controller transfers if a
    local target is running. Also, disable SMBusHostNotify because it
    requires being a controller and local target at the same time.
    
    Fixes: 3b770017b03a ("i2c: rcar: handle RXDMA HW behaviour on Gen3")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: testunit: avoid re-issued work after read message [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Thu Jul 11 14:08:19 2024 +0200

    i2c: testunit: avoid re-issued work after read message
    
    [ Upstream commit 119736c7af442ab398dbb806865988c98ef60d46 ]
    
    The to-be-fixed commit rightfully prevented that the registers will be
    cleared. However, the index must be cleared. Otherwise a read message
    will re-issue the last work. Fix it and add a comment describing the
    situation.
    
    Fixes: c422b6a63024 ("i2c: testunit: don't erase registers after STOP")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: Fix XDP program unloading while removing the driver [+ + +]
Author: Michal Kubiak <michal.kubiak@intel.com>
Date:   Mon Jul 8 16:07:49 2024 -0700

    i40e: Fix XDP program unloading while removing the driver
    
    [ Upstream commit 01fc5142ae6b06b61ed51a624f2732d6525d8ea3 ]
    
    The commit 6533e558c650 ("i40e: Fix reset path while removing
    the driver") introduced a new PF state "__I40E_IN_REMOVE" to block
    modifying the XDP program while the driver is being removed.
    Unfortunately, such a change is useful only if the ".ndo_bpf()"
    callback was called out of the rmmod context because unloading the
    existing XDP program is also a part of driver removing procedure.
    In other words, from the rmmod context the driver is expected to
    unload the XDP program without reporting any errors. Otherwise,
    the kernel warning with callstack is printed out to dmesg.
    
    Example failing scenario:
     1. Load the i40e driver.
     2. Load the XDP program.
     3. Unload the i40e driver (using "rmmod" command).
    
    The example kernel warning log:
    
    [  +0.004646] WARNING: CPU: 94 PID: 10395 at net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870
    [...]
    [  +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/0x870
    [...]
    [  +0.002726] Call Trace:
    [  +0.002457]  <TASK>
    [  +0.002119]  ? __warn+0x80/0x120
    [  +0.003245]  ? unregister_netdevice_many_notify+0x7a9/0x870
    [  +0.005586]  ? report_bug+0x164/0x190
    [  +0.003678]  ? handle_bug+0x3c/0x80
    [  +0.003503]  ? exc_invalid_op+0x17/0x70
    [  +0.003846]  ? asm_exc_invalid_op+0x1a/0x20
    [  +0.004200]  ? unregister_netdevice_many_notify+0x7a9/0x870
    [  +0.005579]  ? unregister_netdevice_many_notify+0x3cc/0x870
    [  +0.005586]  unregister_netdevice_queue+0xf7/0x140
    [  +0.004806]  unregister_netdev+0x1c/0x30
    [  +0.003933]  i40e_vsi_release+0x87/0x2f0 [i40e]
    [  +0.004604]  i40e_remove+0x1a1/0x420 [i40e]
    [  +0.004220]  pci_device_remove+0x3f/0xb0
    [  +0.003943]  device_release_driver_internal+0x19f/0x200
    [  +0.005243]  driver_detach+0x48/0x90
    [  +0.003586]  bus_remove_driver+0x6d/0xf0
    [  +0.003939]  pci_unregister_driver+0x2e/0xb0
    [  +0.004278]  i40e_exit_module+0x10/0x5f0 [i40e]
    [  +0.004570]  __do_sys_delete_module.isra.0+0x197/0x310
    [  +0.005153]  do_syscall_64+0x85/0x170
    [  +0.003684]  ? syscall_exit_to_user_mode+0x69/0x220
    [  +0.004886]  ? do_syscall_64+0x95/0x170
    [  +0.003851]  ? exc_page_fault+0x7e/0x180
    [  +0.003932]  entry_SYSCALL_64_after_hwframe+0x71/0x79
    [  +0.005064] RIP: 0033:0x7f59dc9347cb
    [  +0.003648] Code: 73 01 c3 48 8b 0d 65 16 0c 00 f7 d8 64 89 01 48 83
    c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f
    05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 16 0c 00 f7 d8 64 89 01 48
    [  +0.018753] RSP: 002b:00007ffffac99048 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
    [  +0.007577] RAX: ffffffffffffffda RBX: 0000559b9bb2f6e0 RCX: 00007f59dc9347cb
    [  +0.007140] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000559b9bb2f748
    [  +0.007146] RBP: 00007ffffac99070 R08: 1999999999999999 R09: 0000000000000000
    [  +0.007133] R10: 00007f59dc9a5ac0 R11: 0000000000000206 R12: 0000000000000000
    [  +0.007141] R13: 00007ffffac992d8 R14: 0000559b9bb2f6e0 R15: 0000000000000000
    [  +0.007151]  </TASK>
    [  +0.002204] ---[ end trace 0000000000000000 ]---
    
    Fix this by checking if the XDP program is being loaded or unloaded.
    Then, block only loading a new program while "__I40E_IN_REMOVE" is set.
    Also, move testing "__I40E_IN_REMOVE" flag to the beginning of XDP_SETUP
    callback to avoid unnecessary operations and checks.
    
    Fixes: 6533e558c650 ("i40e: Fix reset path while removing the driver")
    Signed-off-by: Michal Kubiak <michal.kubiak@intel.com>
    Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://patch.msgid.link/20240708230750.625986-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i40e: fix: remove needless retries of NVM update [+ + +]
Author: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Date:   Wed Jul 10 15:44:54 2024 -0700

    i40e: fix: remove needless retries of NVM update
    
    [ Upstream commit 8b9b59e27aa88ba133fbac85def3f8be67f2d5a8 ]
    
    Remove wrong EIO to EGAIN conversion and pass all errors as is.
    
    After commit 230f3d53a547 ("i40e: remove i40e_status"), which should only
    replace F/W specific error codes with Linux kernel generic, all EIO errors
    suddenly started to be converted into EAGAIN which leads nvmupdate to retry
    until it timeouts and sometimes fails after more than 20 minutes in the
    middle of NVM update, so NVM becomes corrupted.
    
    The bug affects users only at the time when they try to update NVM, and
    only F/W versions that generate errors while nvmupdate. For example, X710DA2
    with 0x8000ECB7 F/W is affected, but there are probably more...
    
    Command for reproduction is just NVM update:
     ./nvmupdate64
    
    In the log instead of:
     i40e_nvmupd_exec_aq err I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_ENOMEM)
    appears:
     i40e_nvmupd_exec_aq err -EIO aq_err I40E_AQ_RC_ENOMEM
     i40e: eeprom check failed (-5), Tx/Rx traffic disabled
    
    The problematic code did silently convert EIO into EAGAIN which forced
    nvmupdate to ignore EAGAIN error and retry the same operation until timeout.
    That's why NVM update takes 20+ minutes to finish with the fail in the end.
    
    Fixes: 230f3d53a547 ("i40e: remove i40e_status")
    Co-developed-by: Kelvin Kang <kelvin.kang@intel.com>
    Signed-off-by: Kelvin Kang <kelvin.kang@intel.com>
    Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Tested-by: Tony Brelinski <tony.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Link: https://patch.msgid.link/20240710224455.188502-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: trigger: Fix condition for own trigger [+ + +]
Author: João Paulo Gonçalves <joao.goncalves@toradex.com>
Date:   Fri Jun 14 11:36:58 2024 -0300

    iio: trigger: Fix condition for own trigger
    
    commit 74cb21576ea5247efbbb7d92f71cafee12159cd9 upstream.
    
    The condition for checking if triggers belong to the same IIO device to
    set attached_own_device is currently inverted, causing
    iio_trigger_using_own() to return an incorrect value. Fix it by testing
    for the correct return value of iio_validate_own_trigger().
    
    Cc: stable@vger.kernel.org
    Fixes: 517985ebc531 ("iio: trigger: Add simple trigger_validation helper")
    Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com>
    Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
    Link: https://lore.kernel.org/r/20240614143658.3531097-1-jpaulo.silvagoncalves@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kbuild: Make ld-version.sh more robust against version string changes [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Sun Jul 7 22:06:47 2024 -0700

    kbuild: Make ld-version.sh more robust against version string changes
    
    [ Upstream commit 9852f47ac7c993990317570ff125e30ad901e213 ]
    
    After [1] in upstream LLVM, ld.lld's version output became slightly
    different when the cmake configuration option LLVM_APPEND_VC_REV is
    disabled.
    
    Before:
    
      Debian LLD 19.0.0 (compatible with GNU linkers)
    
    After:
    
      Debian LLD 19.0.0, compatible with GNU linkers
    
    This results in ld-version.sh failing with
    
      scripts/ld-version.sh: 18: arithmetic expression: expecting EOF: "10000 * 19 + 100 * 0 + 0,"
    
    because the trailing comma is included in the patch level part of the
    expression. While [1] has been partially reverted in [2] to avoid this
    breakage (as it impacts the configuration stage and it is present in all
    LTS branches), it would be good to make ld-version.sh more robust
    against such miniscule changes like this one.
    
    Use POSIX shell parameter expansion [3] to remove the largest suffix
    after just numbers and periods, replacing of the current removal of
    everything after a hyphen. ld-version.sh continues to work for a number
    of distributions (Arch Linux, Debian, and Fedora) and the kernel.org
    toolchains and no longer errors on a version of ld.lld with [1].
    
    Fixes: 02aff8592204 ("kbuild: check the minimum linker version in Kconfig")
    Link: https://github.com/llvm/llvm-project/commit/0f9fbbb63cfcd2069441aa2ebef622c9716f8dbb [1]
    Link: https://github.com/llvm/llvm-project/commit/649cdfc4b6781a350dfc87d9b2a4b5a4c3395909 [2]
    Link: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html [3]
    Suggested-by: Fangrui Song <maskray@google.com>
    Reviewed-by: Fangrui Song <maskray@google.com>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

kbuild: rpm-pkg: avoid the warnings with dtb's listed twice [+ + +]
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Date:   Thu Jul 11 18:49:19 2024 +0200

    kbuild: rpm-pkg: avoid the warnings with dtb's listed twice
    
    [ Upstream commit e3286434d220efb9a8b78f7241a5667974d2ec80 ]
    
    After 8d1001f7bdd0 (kbuild: rpm-pkg: fix build error with CONFIG_MODULES=n),
    the following warning "warning: File listed twice: *.dtb" is appearing for
    every dtb file that is included.
    The reason is that the commented commit already adds the folder
    /lib/modules/%{KERNELRELEASE} in kernel.list file so the folder
    /lib/modules/%{KERNELRELEASE}/dtb is no longer necessary, just remove it.
    
    Fixes: 8d1001f7bdd0 ("kbuild: rpm-pkg: fix build error with CONFIG_MODULES=n")
    Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ksmbd: discard write access to the directory open [+ + +]
Author: Hobin Woo <hobin.woo@samsung.com>
Date:   Fri Jul 5 12:27:25 2024 +0900

    ksmbd: discard write access to the directory open
    
    commit e2e33caa5dc2eae7bddf88b22ce11ec3d760e5cd upstream.
    
    may_open() does not allow a directory to be opened with the write access.
    However, some writing flags set by client result in adding write access
    on server, making ksmbd incompatible with FUSE file system. Simply, let's
    discard the write access when opening a directory.
    
    list_add corruption. next is NULL.
    ------------[ cut here ]------------
    kernel BUG at lib/list_debug.c:26!
    pc : __list_add_valid+0x88/0xbc
    lr : __list_add_valid+0x88/0xbc
    Call trace:
    __list_add_valid+0x88/0xbc
    fuse_finish_open+0x11c/0x170
    fuse_open_common+0x284/0x5e8
    fuse_dir_open+0x14/0x24
    do_dentry_open+0x2a4/0x4e0
    dentry_open+0x50/0x80
    smb2_open+0xbe4/0x15a4
    handle_ksmbd_work+0x478/0x5ec
    process_one_work+0x1b4/0x448
    worker_thread+0x25c/0x430
    kthread+0x104/0x1d4
    ret_from_fork+0x10/0x20
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Yoonho Shin <yoonho.shin@samsung.com>
    Signed-off-by: Hobin Woo <hobin.woo@samsung.com>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
libceph: fix race between delayed_work() and ceph_monc_stop() [+ + +]
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Mon Jul 8 22:37:29 2024 +0200

    libceph: fix race between delayed_work() and ceph_monc_stop()
    
    commit 69c7b2fe4c9cc1d3b1186d1c5606627ecf0de883 upstream.
    
    The way the delayed work is handled in ceph_monc_stop() is prone to
    races with mon_fault() and possibly also finish_hunting().  Both of
    these can requeue the delayed work which wouldn't be canceled by any of
    the following code in case that happens after cancel_delayed_work_sync()
    runs -- __close_session() doesn't mess with the delayed work in order
    to avoid interfering with the hunting interval logic.  This part was
    missed in commit b5d91704f53e ("libceph: behave in mon_fault() if
    cur_mon < 0") and use-after-free can still ensue on monc and objects
    that hang off of it, with monc->auth and monc->monmap being
    particularly susceptible to quickly being reused.
    
    To fix this:
    
    - clear monc->cur_mon and monc->hunting as part of closing the session
      in ceph_monc_stop()
    - bail from delayed_work() if monc->cur_mon is cleared, similar to how
      it's done in mon_fault() and finish_hunting() (based on monc->hunting)
    - call cancel_delayed_work_sync() after the session is closed
    
    Cc: stable@vger.kernel.org
    Link: https://tracker.ceph.com/issues/66857
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 6.9.10 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jul 18 13:22:56 2024 +0200

    Linux 6.9.10
    
    Link: https://lore.kernel.org/r/20240716152755.980289992@linuxfoundation.org
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Markus Reichelt <lkt+2023@mareichelt.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Link: https://lore.kernel.org/r/20240717063806.741977243@linuxfoundation.org
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mei: vsc: Enhance IVSC chipset stability during warm reboot [+ + +]
Author: Wentong Wu <wentong.wu@intel.com>
Date:   Tue Jun 25 16:10:43 2024 +0800

    mei: vsc: Enhance IVSC chipset stability during warm reboot
    
    commit 07de60a46ae9c0583df1c644bae6d3b22d1d903d upstream.
    
    During system shutdown, incorporate reset logic to ensure the IVSC
    chipset remains in a valid state. This adjustment guarantees that
    the IVSC chipset operates in a known state following a warm reboot.
    
    Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
    Cc: stable@vger.kernel.org # for 6.8+
    Signed-off-by: Wentong Wu <wentong.wu@intel.com>
    Tested-by: Jason Chen <jason.z.chen@intel.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240625081047.4178494-2-wentong.wu@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: vsc: Prevent timeout error with added delay post-firmware download [+ + +]
Author: Wentong Wu <wentong.wu@intel.com>
Date:   Tue Jun 25 16:10:44 2024 +0800

    mei: vsc: Prevent timeout error with added delay post-firmware download
    
    commit a9e8fe38195ae6f8e5b32907a17b397ff3ce3e48 upstream.
    
    After completing the firmware download, the firmware requires some
    time to become functional. This change introduces additional sleep
    time before the first read operation to prevent a confusing timeout
    error in vsc_tp_xfer().
    
    Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
    Cc: stable@vger.kernel.org # for 6.8+
    Signed-off-by: Wentong Wu <wentong.wu@intel.com>
    Tested-by: Jason Chen <jason.z.chen@intel.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240625081047.4178494-3-wentong.wu@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: vsc: Utilize the appropriate byte order swap function [+ + +]
Author: Wentong Wu <wentong.wu@intel.com>
Date:   Tue Jun 25 16:10:45 2024 +0800

    mei: vsc: Utilize the appropriate byte order swap function
    
    commit a896a8a127f45d00fb69fa7536955aa9b2e5d610 upstream.
    
    Switch from cpu_to_be32_array() to be32_to_cpu_array() for the
    received ROM data.
    
    Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
    Cc: stable@vger.kernel.org # for 6.8+
    Signed-off-by: Wentong Wu <wentong.wu@intel.com>
    Tested-by: Jason Chen <jason.z.chen@intel.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240625081047.4178494-4-wentong.wu@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
minixfs: Fix minixfs_rename with HIGHMEM [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Tue Jul 9 20:58:39 2024 +0100

    minixfs: Fix minixfs_rename with HIGHMEM
    
    [ Upstream commit 3d1bec293378700dddc087d4d862306702276c23 ]
    
    minixfs now uses kmap_local_page(), so we can't call kunmap() to
    undo it.  This one call was missed as part of the commit this fixes.
    
    Fixes: 6628f69ee66a (minixfs: Use dir_put_page() in minix_unlink() and minix_rename())
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Link: https://lore.kernel.org/r/20240709195841.1986374-1-willy@infradead.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
misc: fastrpc: Avoid updating PD type for capability request [+ + +]
Author: Ekansh Gupta <quic_ekangupt@quicinc.com>
Date:   Fri Jun 28 12:44:58 2024 +0100

    misc: fastrpc: Avoid updating PD type for capability request
    
    commit bfb6b07d2a30ffe98864d8cfc31fc00470063025 upstream.
    
    When user is requesting for DSP capability, the process pd type is
    getting updated to USER_PD which is incorrect as DSP will assume the
    process which is making the request is a user PD and this will never
    get updated back to the original value. The actual PD type should not
    be updated for capability request and it should be serviced by the
    respective PD on DSP side. Don't change process's PD type for DSP
    capability request.
    
    Fixes: 6c16fd8bdd40 ("misc: fastrpc: Add support to get DSP capabilities")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
    Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240628114501.14310-4-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: fastrpc: Copy the complete capability structure to user [+ + +]
Author: Ekansh Gupta <quic_ekangupt@quicinc.com>
Date:   Fri Jun 28 12:44:57 2024 +0100

    misc: fastrpc: Copy the complete capability structure to user
    
    commit e7f0be3f09c6e955dc8009129862b562d8b64513 upstream.
    
    User is passing capability ioctl structure(argp) to get DSP
    capabilities. This argp is copied to a local structure to get domain
    and attribute_id information. After getting the capability, only
    capability value is getting copied to user argp which will not be
    useful if the use is trying to get the capability by checking the
    capability member of fastrpc_ioctl_capability structure. Copy the
    complete capability structure so that user can get the capability
    value from the expected member of the structure.
    
    Fixes: 6c16fd8bdd40 ("misc: fastrpc: Add support to get DSP capabilities")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240628114501.14310-3-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: fastrpc: Fix DSP capabilities request [+ + +]
Author: Ekansh Gupta <quic_ekangupt@quicinc.com>
Date:   Fri Jun 28 12:44:56 2024 +0100

    misc: fastrpc: Fix DSP capabilities request
    
    commit 4cb7915f0a35e2fcc4be60b912c4be35cd830957 upstream.
    
    The DSP capability request call expects 2 arguments. First is the
    information about the total number of attributes to be copied from
    DSP and second is the information about the buffer where the DSP
    needs to copy the information. The current design is passing the
    information about the size to be copied from DSP which would be
    considered as a bad argument to the call by DSP causing a failure
    suggesting the same. The second argument carries the information
    about the buffer where the DSP needs to copy the capability
    information and the size to be copied. As the first entry of
    capability attribute is getting skipped, same should also be
    considered while sending the information to DSP. Add changes to
    pass proper arguments to DSP.
    
    Fixes: 6c16fd8bdd40 ("misc: fastrpc: Add support to get DSP capabilities")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240628114501.14310-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: fastrpc: Fix memory leak in audio daemon attach operation [+ + +]
Author: Ekansh Gupta <quic_ekangupt@quicinc.com>
Date:   Fri Jun 28 12:44:59 2024 +0100

    misc: fastrpc: Fix memory leak in audio daemon attach operation
    
    commit ad0bd973a033003ca578c42a760d1dc77aeea15e upstream.
    
    Audio PD daemon send the name as part of the init IOCTL call. This
    name needs to be copied to kernel for which memory is allocated.
    This memory is never freed which might result in memory leak. Free
    the memory when it is not needed.
    
    Fixes: 0871561055e6 ("misc: fastrpc: Add support for audiopd")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240628114501.14310-5-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: fastrpc: Fix ownership reassignment of remote heap [+ + +]
Author: Ekansh Gupta <quic_ekangupt@quicinc.com>
Date:   Fri Jun 28 12:45:00 2024 +0100

    misc: fastrpc: Fix ownership reassignment of remote heap
    
    commit a6f2f158f1ac4893a4967993105712bf3dad32d9 upstream.
    
    Audio PD daemon will allocate memory for audio PD dynamic loading
    usage when it is attaching for the first time to audio PD. As
    part of this, the memory ownership is moved to the VM where
    audio PD can use it. In case daemon process is killed without any
    impact to DSP audio PD, the daemon process will retry to attach to
    audio PD and in this case memory won't be reallocated. If the invoke
    fails due to any reason, as part of err_invoke, the memory ownership
    is getting reassigned to HLOS even when the memory was not allocated.
    At this time the audio PD might still be using the memory and an
    attemp of ownership reassignment would result in memory issue.
    
    Fixes: 0871561055e6 ("misc: fastrpc: Add support for audiopd")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240628114501.14310-6-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: fastrpc: Restrict untrusted app to attach to privileged PD [+ + +]
Author: Ekansh Gupta <quic_ekangupt@quicinc.com>
Date:   Fri Jun 28 12:45:01 2024 +0100

    misc: fastrpc: Restrict untrusted app to attach to privileged PD
    
    commit bab2f5e8fd5d2f759db26b78d9db57412888f187 upstream.
    
    Untrusted application with access to only non-secure fastrpc device
    node can attach to root_pd or static PDs if it can make the respective
    init request. This can cause problems as the untrusted application
    can send bad requests to root_pd or static PDs. Add changes to reject
    attach to privileged PDs if the request is being made using non-secure
    fastrpc device node.
    
    Fixes: 0871561055e6 ("misc: fastrpc: Add support for audiopd")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240628114501.14310-7-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: microchip: pci1xxxx: Fix return value of nvmem callbacks [+ + +]
Author: Joy Chakraborty <joychakr@google.com>
Date:   Wed Jun 12 07:00:30 2024 +0000

    misc: microchip: pci1xxxx: Fix return value of nvmem callbacks
    
    commit a6a0f04e7d28378c181f76d32e4f965aa6a8b0a5 upstream.
    
    Read/write callbacks registered with nvmem core expect 0 to be returned
    on success and a negative value to be returned on failure.
    
    Currently pci1xxxx_otp_read()/pci1xxxx_otp_write() and
    pci1xxxx_eeprom_read()/pci1xxxx_eeprom_write() return the number of
    bytes read/written on success.
    Fix to return 0 on success.
    
    Fixes: 9ab5465349c0 ("misc: microchip: pci1xxxx: Add support to read and write into PCI1XXXX EEPROM via NVMEM sysfs")
    Fixes: 0969001569e4 ("misc: microchip: pci1xxxx: Add support to read and write into PCI1XXXX OTP via NVMEM sysfs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Joy Chakraborty <joychakr@google.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/20240612070031.1215558-1-joychakr@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/damon/core: merge regions aggressively when max_nr_regions is unmet [+ + +]
Author: SeongJae Park <sj@kernel.org>
Date:   Mon Jun 24 10:58:14 2024 -0700

    mm/damon/core: merge regions aggressively when max_nr_regions is unmet
    
    commit 310d6c15e9104c99d5d9d0ff8e5383a79da7d5e6 upstream.
    
    DAMON keeps the number of regions under max_nr_regions by skipping regions
    split operations when doing so can make the number higher than the limit.
    It works well for preventing violation of the limit.  But, if somehow the
    violation happens, it cannot recovery well depending on the situation.  In
    detail, if the real number of regions having different access pattern is
    higher than the limit, the mechanism cannot reduce the number below the
    limit.  In such a case, the system could suffer from high monitoring
    overhead of DAMON.
    
    The violation can actually happen.  For an example, the user could reduce
    max_nr_regions while DAMON is running, to be lower than the current number
    of regions.  Fix the problem by repeating the merge operations with
    increasing aggressiveness in kdamond_merge_regions() for the case, until
    the limit is met.
    
    [sj@kernel.org: increase regions merge aggressiveness while respecting min_nr_regions]
      Link: https://lkml.kernel.org/r/20240626164753.46270-1-sj@kernel.org
    [sj@kernel.org: ensure max threshold attempt for max_nr_regions violation]
      Link: https://lkml.kernel.org/r/20240627163153.75969-1-sj@kernel.org
    Link: https://lkml.kernel.org/r/20240624175814.89611-1-sj@kernel.org
    Fixes: b9a6ac4e4ede ("mm/damon: adaptively adjust regions")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>    [5.15+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray [+ + +]
Author: Gavin Shan <gshan@redhat.com>
Date:   Thu Jun 27 10:39:49 2024 +1000

    mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray
    
    commit 099d90642a711caae377f53309abfe27e8724a8b upstream.
    
    Patch series "mm/filemap: Limit page cache size to that supported by
    xarray", v2.
    
    Currently, xarray can't support arbitrary page cache size.  More details
    can be found from the WARN_ON() statement in xas_split_alloc().  In our
    test whose code is attached below, we hit the WARN_ON() on ARM64 system
    where the base page size is 64KB and huge page size is 512MB.  The issue
    was reported long time ago and some discussions on it can be found here
    [1].
    
    [1] https://www.spinics.net/lists/linux-xfs/msg75404.html
    
    In order to fix the issue, we need to adjust MAX_PAGECACHE_ORDER to one
    supported by xarray and avoid PMD-sized page cache if needed.  The code
    changes are suggested by David Hildenbrand.
    
    PATCH[1] adjusts MAX_PAGECACHE_ORDER to that supported by xarray
    PATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path
    PATCH[4] avoids PMD-sized page cache for shmem files if needed
    
    Test program
    ============
    # cat test.c
    #define _GNU_SOURCE
    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <string.h>
    #include <fcntl.h>
    #include <errno.h>
    #include <sys/syscall.h>
    #include <sys/mman.h>
    
    #define TEST_XFS_FILENAME       "/tmp/data"
    #define TEST_SHMEM_FILENAME     "/dev/shm/data"
    #define TEST_MEM_SIZE           0x20000000
    
    int main(int argc, char **argv)
    {
            const char *filename;
            int fd = 0;
            void *buf = (void *)-1, *p;
            int pgsize = getpagesize();
            int ret;
    
            if (pgsize != 0x10000) {
                    fprintf(stderr, "64KB base page size is required\n");
                    return -EPERM;
            }
    
            system("echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled");
            system("rm -fr /tmp/data");
            system("rm -fr /dev/shm/data");
            system("echo 1 > /proc/sys/vm/drop_caches");
    
            /* Open xfs or shmem file */
            filename = TEST_XFS_FILENAME;
            if (argc > 1 && !strcmp(argv[1], "shmem"))
                    filename = TEST_SHMEM_FILENAME;
    
            fd = open(filename, O_CREAT | O_RDWR | O_TRUNC);
            if (fd < 0) {
                    fprintf(stderr, "Unable to open <%s>\n", filename);
                    return -EIO;
            }
    
            /* Extend file size */
            ret = ftruncate(fd, TEST_MEM_SIZE);
            if (ret) {
                    fprintf(stderr, "Error %d to ftruncate()\n", ret);
                    goto cleanup;
            }
    
            /* Create VMA */
            buf = mmap(NULL, TEST_MEM_SIZE,
                       PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
            if (buf == (void *)-1) {
                    fprintf(stderr, "Unable to mmap <%s>\n", filename);
                    goto cleanup;
            }
    
            fprintf(stdout, "mapped buffer at 0x%p\n", buf);
            ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE);
            if (ret) {
                    fprintf(stderr, "Unable to madvise(MADV_HUGEPAGE)\n");
                    goto cleanup;
            }
    
            /* Populate VMA */
            ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_WRITE);
            if (ret) {
                    fprintf(stderr, "Error %d to madvise(MADV_POPULATE_WRITE)\n", ret);
                    goto cleanup;
            }
    
            /* Punch the file to enforce xarray split */
            ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,
                            TEST_MEM_SIZE - pgsize, pgsize);
            if (ret)
                    fprintf(stderr, "Error %d to fallocate()\n", ret);
    
    cleanup:
            if (buf != (void *)-1)
                    munmap(buf, TEST_MEM_SIZE);
            if (fd > 0)
                    close(fd);
    
            return 0;
    }
    
    # gcc test.c -o test
    # cat /proc/1/smaps | grep KernelPageSize | head -n 1
    KernelPageSize:       64 kB
    # ./test shmem
       :
    ------------[ cut here ]------------
    WARNING: CPU: 17 PID: 5253 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128
    Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib  \
    nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct    \
    nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4    \
    ip_set nf_tables rfkill nfnetlink vfat fat virtio_balloon          \
    drm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64  \
    virtio_net sha1_ce net_failover failover virtio_console virtio_blk \
    dimlib virtio_mmio
    CPU: 17 PID: 5253 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #12
    Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024
    pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
    pc : xas_split_alloc+0xf8/0x128
    lr : split_huge_page_to_list_to_order+0x1c4/0x720
    sp : ffff80008a92f5b0
    x29: ffff80008a92f5b0 x28: ffff80008a92f610 x27: ffff80008a92f728
    x26: 0000000000000cc0 x25: 000000000000000d x24: ffff0000cf00c858
    x23: ffff80008a92f610 x22: ffffffdfc0600000 x21: 0000000000000000
    x20: 0000000000000000 x19: ffffffdfc0600000 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000018000000000 x15: 3374004000000000
    x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020
    x11: 3374000000000000 x10: 3374e1c0ffff6000 x9 : ffffb463a84c681c
    x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff00011c976ce0
    x5 : ffffb463aa47e378 x4 : 0000000000000000 x3 : 0000000000000cc0
    x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000
    Call trace:
     xas_split_alloc+0xf8/0x128
     split_huge_page_to_list_to_order+0x1c4/0x720
     truncate_inode_partial_folio+0xdc/0x160
     shmem_undo_range+0x2bc/0x6a8
     shmem_fallocate+0x134/0x430
     vfs_fallocate+0x124/0x2e8
     ksys_fallocate+0x4c/0xa0
     __arm64_sys_fallocate+0x24/0x38
     invoke_syscall.constprop.0+0x7c/0xd8
     do_el0_svc+0xb4/0xd0
     el0_svc+0x44/0x1d8
     el0t_64_sync_handler+0x134/0x150
     el0t_64_sync+0x17c/0x180
    
    
    This patch (of 4):
    
    The largest page cache order can be HPAGE_PMD_ORDER (13) on ARM64 with
    64KB base page size.  The xarray entry with this order can't be split as
    the following error messages indicate.
    
    ------------[ cut here ]------------
    WARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128
    Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib  \
    nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct    \
    nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4    \
    ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm      \
    fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64      \
    sha1_ce virtio_net net_failover virtio_console virtio_blk failover \
    dimlib virtio_mmio
    CPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9
    Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024
    pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
    pc : xas_split_alloc+0xf8/0x128
    lr : split_huge_page_to_list_to_order+0x1c4/0x720
    sp : ffff800087a4f6c0
    x29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff
    x26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858
    x23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000
    x20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000
    x17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000
    x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020
    x11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28
    x8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8
    x5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40
    x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000
    Call trace:
     xas_split_alloc+0xf8/0x128
     split_huge_page_to_list_to_order+0x1c4/0x720
     truncate_inode_partial_folio+0xdc/0x160
     truncate_inode_pages_range+0x1b4/0x4a8
     truncate_pagecache_range+0x84/0xa0
     xfs_flush_unmap_range+0x70/0x90 [xfs]
     xfs_file_fallocate+0xfc/0x4d8 [xfs]
     vfs_fallocate+0x124/0x2e8
     ksys_fallocate+0x4c/0xa0
     __arm64_sys_fallocate+0x24/0x38
     invoke_syscall.constprop.0+0x7c/0xd8
     do_el0_svc+0xb4/0xd0
     el0_svc+0x44/0x1d8
     el0t_64_sync_handler+0x134/0x150
     el0t_64_sync+0x17c/0x180
    
    Fix it by decreasing MAX_PAGECACHE_ORDER to the largest supported order
    by xarray. For this specific case, MAX_PAGECACHE_ORDER is dropped from
    13 to 11 when CONFIG_BASE_SMALL is disabled.
    
    Link: https://lkml.kernel.org/r/20240627003953.1262512-1-gshan@redhat.com
    Link: https://lkml.kernel.org/r/20240627003953.1262512-2-gshan@redhat.com
    Fixes: 793917d997df ("mm/readahead: Add large folio readahead")
    Signed-off-by: Gavin Shan <gshan@redhat.com>
    Suggested-by: David Hildenbrand <david@redhat.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Darrick J. Wong <djwong@kernel.org>
    Cc: Don Dutile <ddutile@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Ryan Roberts <ryan.roberts@arm.com>
    Cc: William Kucharski <william.kucharski@oracle.com>
    Cc: Zhenyu Zhang <zhenyzha@redhat.com>
    Cc: <stable@vger.kernel.org>    [5.18+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm/filemap: skip to create PMD-sized page cache if needed [+ + +]
Author: Gavin Shan <gshan@redhat.com>
Date:   Thu Jun 27 10:39:51 2024 +1000

    mm/filemap: skip to create PMD-sized page cache if needed
    
    commit 3390916aca7af1893ed2ebcdfee1d6fdb65bb058 upstream.
    
    On ARM64, HPAGE_PMD_ORDER is 13 when the base page size is 64KB.  The
    PMD-sized page cache can't be supported by xarray as the following error
    messages indicate.
    
    ------------[ cut here ]------------
    WARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128
    Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib  \
    nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct    \
    nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4    \
    ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm      \
    fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64      \
    sha1_ce virtio_net net_failover virtio_console virtio_blk failover \
    dimlib virtio_mmio
    CPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9
    Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024
    pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
    pc : xas_split_alloc+0xf8/0x128
    lr : split_huge_page_to_list_to_order+0x1c4/0x720
    sp : ffff800087a4f6c0
    x29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff
    x26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858
    x23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000
    x20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000
    x17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000
    x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020
    x11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28
    x8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8
    x5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40
    x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000
    Call trace:
     xas_split_alloc+0xf8/0x128
     split_huge_page_to_list_to_order+0x1c4/0x720
     truncate_inode_partial_folio+0xdc/0x160
     truncate_inode_pages_range+0x1b4/0x4a8
     truncate_pagecache_range+0x84/0xa0
     xfs_flush_unmap_range+0x70/0x90 [xfs]
     xfs_file_fallocate+0xfc/0x4d8 [xfs]
     vfs_fallocate+0x124/0x2e8
     ksys_fallocate+0x4c/0xa0
     __arm64_sys_fallocate+0x24/0x38
     invoke_syscall.constprop.0+0x7c/0xd8
     do_el0_svc+0xb4/0xd0
     el0_svc+0x44/0x1d8
     el0t_64_sync_handler+0x134/0x150
     el0t_64_sync+0x17c/0x180
    
    Fix it by skipping to allocate PMD-sized page cache when its size is
    larger than MAX_PAGECACHE_ORDER.  For this specific case, we will fall to
    regular path where the readahead window is determined by BDI's sysfs file
    (read_ahead_kb).
    
    Link: https://lkml.kernel.org/r/20240627003953.1262512-4-gshan@redhat.com
    Fixes: 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings")
    Signed-off-by: Gavin Shan <gshan@redhat.com>
    Suggested-by: David Hildenbrand <david@redhat.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Darrick J. Wong <djwong@kernel.org>
    Cc: Don Dutile <ddutile@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Ryan Roberts <ryan.roberts@arm.com>
    Cc: William Kucharski <william.kucharski@oracle.com>
    Cc: Zhenyu Zhang <zhenyzha@redhat.com>
    Cc: <stable@vger.kernel.org>    [5.18+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/readahead: limit page cache size in page_cache_ra_order() [+ + +]
Author: Gavin Shan <gshan@redhat.com>
Date:   Thu Jun 27 10:39:50 2024 +1000

    mm/readahead: limit page cache size in page_cache_ra_order()
    
    commit 1f789a45c3f1aa77531db21768fca70b66c0eeb1 upstream.
    
    In page_cache_ra_order(), the maximal order of the page cache to be
    allocated shouldn't be larger than MAX_PAGECACHE_ORDER.  Otherwise, it's
    possible the large page cache can't be supported by xarray when the
    corresponding xarray entry is split.
    
    For example, HPAGE_PMD_ORDER is 13 on ARM64 when the base page size is
    64KB.  The PMD-sized page cache can't be supported by xarray.
    
    Link: https://lkml.kernel.org/r/20240627003953.1262512-3-gshan@redhat.com
    Fixes: 793917d997df ("mm/readahead: Add large folio readahead")
    Signed-off-by: Gavin Shan <gshan@redhat.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Darrick J. Wong <djwong@kernel.org>
    Cc: Don Dutile <ddutile@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Ryan Roberts <ryan.roberts@arm.com>
    Cc: William Kucharski <william.kucharski@oracle.com>
    Cc: Zhenyu Zhang <zhenyzha@redhat.com>
    Cc: <stable@vger.kernel.org>    [5.18+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/shmem: disable PMD-sized page cache if needed [+ + +]
Author: Gavin Shan <gshan@redhat.com>
Date:   Thu Jun 27 10:39:52 2024 +1000

    mm/shmem: disable PMD-sized page cache if needed
    
    commit 9fd154ba926b34c833b7bfc4c14ee2e931b3d743 upstream.
    
    For shmem files, it's possible that PMD-sized page cache can't be
    supported by xarray.  For example, 512MB page cache on ARM64 when the base
    page size is 64KB can't be supported by xarray.  It leads to errors as the
    following messages indicate when this sort of xarray entry is split.
    
    WARNING: CPU: 34 PID: 7578 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128
    Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6   \
    nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject        \
    nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4  \
    ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse xfs  \
    libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_net \
    net_failover virtio_console virtio_blk failover dimlib virtio_mmio
    CPU: 34 PID: 7578 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9
    Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024
    pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
    pc : xas_split_alloc+0xf8/0x128
    lr : split_huge_page_to_list_to_order+0x1c4/0x720
    sp : ffff8000882af5f0
    x29: ffff8000882af5f0 x28: ffff8000882af650 x27: ffff8000882af768
    x26: 0000000000000cc0 x25: 000000000000000d x24: ffff00010625b858
    x23: ffff8000882af650 x22: ffffffdfc0900000 x21: 0000000000000000
    x20: 0000000000000000 x19: ffffffdfc0900000 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000018000000000 x15: 52f8004000000000
    x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020
    x11: 52f8000000000000 x10: 52f8e1c0ffff6000 x9 : ffffbeb9619a681c
    x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff00010b02ddb0
    x5 : ffffbeb96395e378 x4 : 0000000000000000 x3 : 0000000000000cc0
    x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000
    Call trace:
     xas_split_alloc+0xf8/0x128
     split_huge_page_to_list_to_order+0x1c4/0x720
     truncate_inode_partial_folio+0xdc/0x160
     shmem_undo_range+0x2bc/0x6a8
     shmem_fallocate+0x134/0x430
     vfs_fallocate+0x124/0x2e8
     ksys_fallocate+0x4c/0xa0
     __arm64_sys_fallocate+0x24/0x38
     invoke_syscall.constprop.0+0x7c/0xd8
     do_el0_svc+0xb4/0xd0
     el0_svc+0x44/0x1d8
     el0t_64_sync_handler+0x134/0x150
     el0t_64_sync+0x17c/0x180
    
    Fix it by disabling PMD-sized page cache when HPAGE_PMD_ORDER is larger
    than MAX_PAGECACHE_ORDER.  As Matthew Wilcox pointed, the page cache in a
    shmem file isn't represented by a multi-index entry and doesn't have this
    limitation when the xarry entry is split until commit 6b24ca4a1a8d ("mm:
    Use multi-index entries in the page cache").
    
    Link: https://lkml.kernel.org/r/20240627003953.1262512-5-gshan@redhat.com
    Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache")
    Signed-off-by: Gavin Shan <gshan@redhat.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Darrick J. Wong <djwong@kernel.org>
    Cc: Don Dutile <ddutile@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Ryan Roberts <ryan.roberts@arm.com>
    Cc: William Kucharski <william.kucharski@oracle.com>
    Cc: Zhenyu Zhang <zhenyzha@redhat.com>
    Cc: <stable@vger.kernel.org>    [5.17+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: fix crashes from deferred split racing folio migration [+ + +]
Author: Hugh Dickins <hughd@google.com>
Date:   Tue Jul 2 00:40:55 2024 -0700

    mm: fix crashes from deferred split racing folio migration
    
    commit be9581ea8c058d81154251cb0695987098996cad upstream.
    
    Even on 6.10-rc6, I've been seeing elusive "Bad page state"s (often on
    flags when freeing, yet the flags shown are not bad: PG_locked had been
    set and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from
    deferred_split_scan()'s folio_put(), and a variety of other BUG and WARN
    symptoms implying double free by deferred split and large folio migration.
    
    6.7 commit 9bcef5973e31 ("mm: memcg: fix split queue list crash when large
    folio migration") was right to fix the memcg-dependent locking broken in
    85ce2c517ade ("memcontrol: only transfer the memcg data for migration"),
    but missed a subtlety of deferred_split_scan(): it moves folios to its own
    local list to work on them without split_queue_lock, during which time
    folio->_deferred_list is not empty, but even the "right" lock does nothing
    to secure the folio and the list it is on.
    
    Fortunately, deferred_split_scan() is careful to use folio_try_get(): so
    folio_migrate_mapping() can avoid the race by folio_undo_large_rmappable()
    while the old folio's reference count is temporarily frozen to 0 - adding
    such a freeze in the !mapping case too (originally, folio lock and
    unmapping and no swap cache left an anon folio unreachable, so no freezing
    was needed there: but the deferred split queue offers a way to reach it).
    
    Link: https://lkml.kernel.org/r/29c83d1a-11ca-b6c9-f92e-6ccb322af510@google.com
    Fixes: 9bcef5973e31 ("mm: memcg: fix split queue list crash when large folio migration")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
    Cc: Barry Song <baohua@kernel.org>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Nhat Pham <nphamcs@gmail.com>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: Zi Yan <ziy@nvidia.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: prevent derefencing NULL ptr in pfn_section_valid() [+ + +]
Author: Waiman Long <longman@redhat.com>
Date:   Tue Jun 25 20:16:39 2024 -0400

    mm: prevent derefencing NULL ptr in pfn_section_valid()
    
    [ Upstream commit 82f0b6f041fad768c28b4ad05a683065412c226e ]
    
    Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing
    memory_section->usage") changed pfn_section_valid() to add a READ_ONCE()
    call around "ms->usage" to fix a race with section_deactivate() where
    ms->usage can be cleared.  The READ_ONCE() call, by itself, is not enough
    to prevent NULL pointer dereference.  We need to check its value before
    dereferencing it.
    
    Link: https://lkml.kernel.org/r/20240626001639.1350646-1-longman@redhat.com
    Fixes: 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memory_section->usage")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Cc: Charan Teja Kalla <quic_charante@quicinc.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
mm: vmalloc: check if a hash-index is in cpu_possible_mask [+ + +]
Author: Uladzislau Rezki (Sony) <urezki@gmail.com>
Date:   Wed Jun 26 16:03:30 2024 +0200

    mm: vmalloc: check if a hash-index is in cpu_possible_mask
    
    commit a34acf30b19bc4ee3ba2f1082756ea2604c19138 upstream.
    
    The problem is that there are systems where cpu_possible_mask has gaps
    between set CPUs, for example SPARC.  In this scenario addr_to_vb_xa()
    hash function can return an index which accesses to not-possible and not
    setup CPU area using per_cpu() macro.  This results in an oops on SPARC.
    
    A per-cpu vmap_block_queue is also used as hash table, incorrectly
    assuming the cpu_possible_mask has no gaps.  Fix it by adjusting an index
    to a next possible CPU.
    
    Link: https://lkml.kernel.org/r/20240626140330.89836-1-urezki@gmail.com
    Fixes: 062eacf57ad9 ("mm: vmalloc: remove a global vmap_blocks xarray")
    Reported-by: Nick Bowler <nbowler@draconx.ca>
    Closes: https://lore.kernel.org/linux-kernel/ZntjIE6msJbF8zTa@MiWiFi-R3L-srv/T/
    Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Reviewed-by: Baoquan He <bhe@redhat.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Hailong.Liu <hailong.liu@oppo.com>
    Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sony.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: davinci_mmc: Prevent transmitted data size from exceeding sgm's length [+ + +]
Author: Bastien Curutchet <bastien.curutchet@bootlin.com>
Date:   Thu Jul 11 10:18:37 2024 +0200

    mmc: davinci_mmc: Prevent transmitted data size from exceeding sgm's length
    
    commit 16198eef11c1929374381d7f6271b4bf6aa44615 upstream.
    
    No check is done on the size of the data to be transmiited. This causes
    a kernel panic when this size exceeds the sg_miter's length.
    
    Limit the number of transmitted bytes to sgm->length.
    
    Cc: stable@vger.kernel.org
    Fixes: ed01d210fd91 ("mmc: davinci_mmc: Use sg_miter for PIO")
    Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
    Link: https://lore.kernel.org/r/20240711081838.47256-2-bastien.curutchet@bootlin.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: sdhci: Fix max_seg_size for 64KiB PAGE_SIZE [+ + +]
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Wed Jul 10 21:07:37 2024 +0300

    mmc: sdhci: Fix max_seg_size for 64KiB PAGE_SIZE
    
    commit 63d20a94f24fc1cbaf44d0e7c0e0a8077fde0aef upstream.
    
    blk_queue_max_segment_size() ensured:
    
            if (max_size < PAGE_SIZE)
                    max_size = PAGE_SIZE;
    
    whereas:
    
    blk_validate_limits() makes it an error:
    
            if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE))
                    return -EINVAL;
    
    The change from one to the other, exposed sdhci which was setting maximum
    segment size too low in some circumstances.
    
    Fix the maximum segment size when it is too low.
    
    Fixes: 616f87661792 ("mmc: pass queue_limits to blk_mq_alloc_disk")
    Cc: stable@vger.kernel.org
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Link: https://lore.kernel.org/r/20240710180737.142504-1-adrian.hunter@intel.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket [+ + +]
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Thu Jul 4 08:41:57 2024 +0200

    net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
    
    [ Upstream commit 626dfed5fa3bfb41e0dffd796032b555b69f9cde ]
    
    When using a BPF program on kernel_connect(), the call can return -EPERM. This
    causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing
    the kernel to potentially freeze up.
    
    Neil suggested:
    
      This will propagate -EPERM up into other layers which might not be ready
      to handle it. It might be safer to map EPERM to an error we would be more
      likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.
    
    ECONNREFUSED as error seems reasonable. For programs setting a different error
    can be out of reach (see handling in 4fbac77d2d09) in particular on kernels
    which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err
    instead of allow boolean"), thus given that it is better to simply remap for
    consistent behavior. UDP does handle EPERM in xs_udp_send_request().
    
    Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect")
    Fixes: 4fbac77d2d09 ("bpf: Hooks for sys_bind")
    Co-developed-by: Lex Siegel <usiegl00@gmail.com>
    Signed-off-by: Lex Siegel <usiegl00@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Neil Brown <neilb@suse.de>
    Cc: Trond Myklebust <trondmy@kernel.org>
    Cc: Anna Schumaker <anna@kernel.org>
    Link: https://github.com/cilium/cilium/issues/33395
    Link: https://lore.kernel.org/bpf/171374175513.12877.8993642908082014881@noble.neil.brown.name
    Link: https://patch.msgid.link/9069ec1d59e4b2129fc23433349fd5580ad43921.1720075070.git.daniel@iogearbox.net
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: Fix UAF when resolving a clash [+ + +]
Author: Chengen Du <chengen.du@canonical.com>
Date:   Wed Jul 10 13:37:47 2024 +0800

    net/sched: Fix UAF when resolving a clash
    
    [ Upstream commit 26488172b0292bed837b95a006a3f3431d1898c3 ]
    
    KASAN reports the following UAF:
    
     BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]
     Read of size 1 at addr ffff888c07603600 by task handler130/6469
    
     Call Trace:
      <IRQ>
      dump_stack_lvl+0x48/0x70
      print_address_description.constprop.0+0x33/0x3d0
      print_report+0xc0/0x2b0
      kasan_report+0xd0/0x120
      __asan_load1+0x6c/0x80
      tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]
      tcf_ct_act+0x886/0x1350 [act_ct]
      tcf_action_exec+0xf8/0x1f0
      fl_classify+0x355/0x360 [cls_flower]
      __tcf_classify+0x1fd/0x330
      tcf_classify+0x21c/0x3c0
      sch_handle_ingress.constprop.0+0x2c5/0x500
      __netif_receive_skb_core.constprop.0+0xb25/0x1510
      __netif_receive_skb_list_core+0x220/0x4c0
      netif_receive_skb_list_internal+0x446/0x620
      napi_complete_done+0x157/0x3d0
      gro_cell_poll+0xcf/0x100
      __napi_poll+0x65/0x310
      net_rx_action+0x30c/0x5c0
      __do_softirq+0x14f/0x491
      __irq_exit_rcu+0x82/0xc0
      irq_exit_rcu+0xe/0x20
      common_interrupt+0xa1/0xb0
      </IRQ>
      <TASK>
      asm_common_interrupt+0x27/0x40
    
     Allocated by task 6469:
      kasan_save_stack+0x38/0x70
      kasan_set_track+0x25/0x40
      kasan_save_alloc_info+0x1e/0x40
      __kasan_krealloc+0x133/0x190
      krealloc+0xaa/0x130
      nf_ct_ext_add+0xed/0x230 [nf_conntrack]
      tcf_ct_act+0x1095/0x1350 [act_ct]
      tcf_action_exec+0xf8/0x1f0
      fl_classify+0x355/0x360 [cls_flower]
      __tcf_classify+0x1fd/0x330
      tcf_classify+0x21c/0x3c0
      sch_handle_ingress.constprop.0+0x2c5/0x500
      __netif_receive_skb_core.constprop.0+0xb25/0x1510
      __netif_receive_skb_list_core+0x220/0x4c0
      netif_receive_skb_list_internal+0x446/0x620
      napi_complete_done+0x157/0x3d0
      gro_cell_poll+0xcf/0x100
      __napi_poll+0x65/0x310
      net_rx_action+0x30c/0x5c0
      __do_softirq+0x14f/0x491
    
     Freed by task 6469:
      kasan_save_stack+0x38/0x70
      kasan_set_track+0x25/0x40
      kasan_save_free_info+0x2b/0x60
      ____kasan_slab_free+0x180/0x1f0
      __kasan_slab_free+0x12/0x30
      slab_free_freelist_hook+0xd2/0x1a0
      __kmem_cache_free+0x1a2/0x2f0
      kfree+0x78/0x120
      nf_conntrack_free+0x74/0x130 [nf_conntrack]
      nf_ct_destroy+0xb2/0x140 [nf_conntrack]
      __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack]
      nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack]
      __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack]
      tcf_ct_act+0x12ad/0x1350 [act_ct]
      tcf_action_exec+0xf8/0x1f0
      fl_classify+0x355/0x360 [cls_flower]
      __tcf_classify+0x1fd/0x330
      tcf_classify+0x21c/0x3c0
      sch_handle_ingress.constprop.0+0x2c5/0x500
      __netif_receive_skb_core.constprop.0+0xb25/0x1510
      __netif_receive_skb_list_core+0x220/0x4c0
      netif_receive_skb_list_internal+0x446/0x620
      napi_complete_done+0x157/0x3d0
      gro_cell_poll+0xcf/0x100
      __napi_poll+0x65/0x310
      net_rx_action+0x30c/0x5c0
      __do_softirq+0x14f/0x491
    
    The ct may be dropped if a clash has been resolved but is still passed to
    the tcf_ct_flow_table_process_conn function for further usage. This issue
    can be fixed by retrieving ct from skb again after confirming conntrack.
    
    Fixes: 0cc254e5aa37 ("net/sched: act_ct: Offload connections with commit action")
    Co-developed-by: Gerald Yang <gerald.yang@canonical.com>
    Signed-off-by: Gerald Yang <gerald.yang@canonical.com>
    Signed-off-by: Chengen Du <chengen.du@canonical.com>
    Link: https://patch.msgid.link/20240710053747.13223-1-chengen.du@canonical.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: bcmasp: Fix error code in probe() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Jul 4 10:19:44 2024 -0500

    net: bcmasp: Fix error code in probe()
    
    [ Upstream commit 0c754d9d86ffdf2f86b4272b25d759843fb62fd8 ]
    
    Return an error code if bcmasp_interface_create() fails.  Don't return
    success.
    
    Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Reviewed-by: Justin Chen <justin.chen@broadcom.com>
    Link: https://patch.msgid.link/ZoWKBkHH9D1fqV4r@stanley.mountain
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: lantiq_etop: fix double free in detach [+ + +]
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Date:   Mon Jul 8 22:58:26 2024 +0200

    net: ethernet: lantiq_etop: fix double free in detach
    
    [ Upstream commit e1533b6319ab9c3a97dad314dd88b3783bc41b69 ]
    
    The number of the currently released descriptor is never incremented
    which results in the same skb being released multiple times.
    
    Fixes: 504d4721ee8e ("MIPS: Lantiq: Add ethernet driver")
    Reported-by: Joe Perches <joe@perches.com>
    Closes: https://lore.kernel.org/all/fc1bf93d92bb5b2f99c6c62745507cc22f3a7b2d.camel@perches.com/
    Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://patch.msgid.link/20240708205826.5176-1-olek2@wp.pl
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: mtk-star-emac: set mac_managed_pm when probing [+ + +]
Author: Jian Hui Lee <jianhui.lee@canonical.com>
Date:   Mon Jul 8 14:52:09 2024 +0800

    net: ethernet: mtk-star-emac: set mac_managed_pm when probing
    
    [ Upstream commit 8c6790b5c25dfac11b589cc37346bcf9e23ad468 ]
    
    The below commit introduced a warning message 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")
    
    mtk-star-emac doesn't need mdiobus suspend/resume. To fix the warning
    message during resume, indicate the phy resume/suspend is managed by the
    mac when probing.
    
    Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
    Signed-off-by: Jian Hui Lee <jianhui.lee@canonical.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Link: https://patch.msgid.link/20240708065210.4178980-1-jianhui.lee@canonical.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethtool: Fix RSS setting [+ + +]
Author: Saeed Mahameed <saeedm@nvidia.com>
Date:   Wed Jul 10 15:55:38 2024 -0700

    net: ethtool: Fix RSS setting
    
    [ Upstream commit 503757c809281a24d50ac2538401d3b1302b301c ]
    
    When user submits a rxfh set command without touching XFRM_SYM_XOR,
    rxfh.input_xfrm is set to RXH_XFRM_NO_CHANGE, which is equal to 0xff.
    
    Testing if (rxfh.input_xfrm & RXH_XFRM_SYM_XOR &&
                !ops->cap_rss_sym_xor_supported)
                    return -EOPNOTSUPP;
    
    Will always be true on devices that don't set cap_rss_sym_xor_supported,
    since rxfh.input_xfrm & RXH_XFRM_SYM_XOR is always true, if input_xfrm
    was not set, i.e RXH_XFRM_NO_CHANGE=0xff, which will result in failure
    of any command that doesn't require any change of XFRM, e.g RSS context
    or hash function changes.
    
    To avoid this breakage, test if rxfh.input_xfrm != RXH_XFRM_NO_CHANGE
    before testing other conditions. Note that the problem will only trigger
    with XFRM-aware userspace, old ethtool CLI would continue to work.
    
    Fixes: 0dd415d15505 ("net: ethtool: add a NO_CHANGE uAPI for new RXFH's input_xfrm")
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Reviewed-by: Ahmed Zaki <ahmed.zaki@intel.com>
    Link: https://patch.msgid.link/20240710225538.43368-1-saeed@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: fix rc7's __skb_datagram_iter() [+ + +]
Author: Hugh Dickins <hughd@google.com>
Date:   Mon Jul 8 07:46:00 2024 -0700

    net: fix rc7's __skb_datagram_iter()
    
    [ Upstream commit f153831097b4435f963e385304cc0f1acba1c657 ]
    
    X would not start in my old 32-bit partition (and the "n"-handling looks
    just as wrong on 64-bit, but for whatever reason did not show up there):
    "n" must be accumulated over all pages before it's added to "offset" and
    compared with "copy", immediately after the skb_frag_foreach_page() loop.
    
    Fixes: d2d30a376d9c ("net: allow skb_datagram_iter to be called from any context")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Link: https://patch.msgid.link/fef352e8-b89a-da51-f8ce-04bc39ee6481@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ks8851: Fix deadlock with the SPI chip variant [+ + +]
Author: Ronald Wahl <ronald.wahl@raritan.com>
Date:   Sat Jul 6 12:13:37 2024 +0200

    net: ks8851: Fix deadlock with the SPI chip variant
    
    commit 0913ec336a6c0c4a2b296bd9f74f8e41c4c83c8c upstream.
    
    When SMP is enabled and spinlocks are actually functional then there is
    a deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi
    and ks8851_irq:
    
        watchdog: BUG: soft lockup - CPU#0 stuck for 27s!
        call trace:
          queued_spin_lock_slowpath+0x100/0x284
          do_raw_spin_lock+0x34/0x44
          ks8851_start_xmit_spi+0x30/0xb8
          ks8851_start_xmit+0x14/0x20
          netdev_start_xmit+0x40/0x6c
          dev_hard_start_xmit+0x6c/0xbc
          sch_direct_xmit+0xa4/0x22c
          __qdisc_run+0x138/0x3fc
          qdisc_run+0x24/0x3c
          net_tx_action+0xf8/0x130
          handle_softirqs+0x1ac/0x1f0
          __do_softirq+0x14/0x20
          ____do_softirq+0x10/0x1c
          call_on_irq_stack+0x3c/0x58
          do_softirq_own_stack+0x1c/0x28
          __irq_exit_rcu+0x54/0x9c
          irq_exit_rcu+0x10/0x1c
          el1_interrupt+0x38/0x50
          el1h_64_irq_handler+0x18/0x24
          el1h_64_irq+0x64/0x68
          __netif_schedule+0x6c/0x80
          netif_tx_wake_queue+0x38/0x48
          ks8851_irq+0xb8/0x2c8
          irq_thread_fn+0x2c/0x74
          irq_thread+0x10c/0x1b0
          kthread+0xc8/0xd8
          ret_from_fork+0x10/0x20
    
    This issue has not been identified earlier because tests were done on
    a device with SMP disabled and so spinlocks were actually NOPs.
    
    Now use spin_(un)lock_bh for TX queue related locking to avoid execution
    of softirq work synchronously that would lead to a deadlock.
    
    Fixes: 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overrun")
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Simon Horman <horms@kernel.org>
    Cc: netdev@vger.kernel.org
    Cc: stable@vger.kernel.org # 5.10+
    Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20240706101337.854474-1-rwahl@gmx.de
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: ks8851: Fix potential TX stall after interface reopen [+ + +]
Author: Ronald Wahl <ronald.wahl@raritan.com>
Date:   Tue Jul 9 21:58:45 2024 +0200

    net: ks8851: Fix potential TX stall after interface reopen
    
    commit 7a99afef17af66c276c1d6e6f4dbcac223eaf6ac upstream.
    
    The amount of TX space in the hardware buffer is tracked in the tx_space
    variable. The initial value is currently only set during driver probing.
    
    After closing the interface and reopening it the tx_space variable has
    the last value it had before close. If it is smaller than the size of
    the first send packet after reopeing the interface the queue will be
    stopped. The queue is woken up after receiving a TX interrupt but this
    will never happen since we did not send anything.
    
    This commit moves the initialization of the tx_space variable to the
    ks8851_net_open function right before starting the TX queue. Also query
    the value from the hardware instead of using a hard coded value.
    
    Only the SPI chip variant is affected by this issue because only this
    driver variant actually depends on the tx_space variable in the xmit
    function.
    
    Fixes: 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overrun")
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Simon Horman <horms@kernel.org>
    Cc: netdev@vger.kernel.org
    Cc: stable@vger.kernel.org # 5.10+
    Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Link: https://patch.msgid.link/20240709195845.9089-1-rwahl@gmx.de
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: phy: microchip: lan87xx: reinit PHY after cable test [+ + +]
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Fri Jul 5 10:49:54 2024 +0200

    net: phy: microchip: lan87xx: reinit PHY after cable test
    
    [ Upstream commit 30f747b8d53bc73555f268d0f48f56174fa5bf10 ]
    
    Reinit PHY after cable test, otherwise link can't be established on
    tested port. This issue is reproducible on LAN9372 switches with
    integrated 100BaseT1 PHYs.
    
    Fixes: 788050256c411 ("net: phy: microchip_t1: add cable test support for lan87xx phy")
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://patch.msgid.link/20240705084954.83048-1-o.rempel@pengutronix.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: nf_tables: prefer nft_chain_validate [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Jul 11 11:06:39 2024 +0200

    netfilter: nf_tables: prefer nft_chain_validate
    
    [ Upstream commit cff3bd012a9512ac5ed858d38e6ed65f6391008c ]
    
    nft_chain_validate already performs loop detection because a cycle will
    result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).
    
    It also follows maps via ->validate callback in nft_lookup, so there
    appears no reason to iterate the maps again.
    
    nf_tables_check_loops() and all its helper functions can be removed.
    This improves ruleset load time significantly, from 23s down to 12s.
    
    This also fixes a crash bug. Old loop detection code can result in
    unbounded recursion:
    
    BUG: TASK stack guard page was hit at ....
    Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN
    CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1
    [..]
    
    with a suitable ruleset during validation of register stores.
    
    I can't see any actual reason to attempt to check for this from
    nft_validate_register_store(), at this point the transaction is still in
    progress, so we don't have a full picture of the rule graph.
    
    For nf-next it might make sense to either remove it or make this depend
    on table->validate_state in case we could catch an error earlier
    (for improved error reporting to userspace).
    
    Fixes: 20a69341f2d0 ("netfilter: nf_tables: add netlink set API")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nfnetlink_queue: drop bogus WARN_ON [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Jul 9 02:02:26 2024 +0200

    netfilter: nfnetlink_queue: drop bogus WARN_ON
    
    [ Upstream commit 631a4b3ddc7831b20442c59c28b0476d0704c9af ]
    
    Happens when rules get flushed/deleted while packet is out, so remove
    this WARN_ON.
    
    This WARN exists in one form or another since v4.14, no need to backport
    this to older releases, hence use a more recent fixes tag.
    
    Fixes: 3f8019688894 ("netfilter: move nf_reinject into nfnetlink_queue modules")
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Closes: https://lore.kernel.org/oe-lkp/202407081453.11ac0f63-lkp@intel.com
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nilfs2: fix kernel bug on rename operation of broken directory [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sat Jun 29 01:51:07 2024 +0900

    nilfs2: fix kernel bug on rename operation of broken directory
    
    commit a9e1ddc09ca55746079cc479aa3eb6411f0d99d4 upstream.
    
    Syzbot reported that in rename directory operation on broken directory on
    nilfs2, __block_write_begin_int() called to prepare block write may fail
    BUG_ON check for access exceeding the folio/page size.
    
    This is because nilfs_dotdot(), which gets parent directory reference
    entry ("..") of the directory to be moved or renamed, does not check
    consistency enough, and may return location exceeding folio/page size for
    broken directories.
    
    Fix this issue by checking required directory entries ("." and "..") in
    the first chunk of the directory in nilfs_dotdot().
    
    Link: https://lkml.kernel.org/r/20240628165107.9006-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+d3abed1ad3d367fa2627@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=d3abed1ad3d367fa2627
    Fixes: 2ba466d74ed7 ("nilfs2: directory entry operations")
    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>

 
nvmem: core: limit cell sysfs permissions to main attribute ones [+ + +]
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Fri Jun 28 12:37:04 2024 +0100

    nvmem: core: limit cell sysfs permissions to main attribute ones
    
    commit 6bef98bafd82903a8d461463f9594f19f1fd6a85 upstream.
    
    The cell sysfs attribute should not provide more access to the nvmem
    data than the main attribute itself.
    For example if nvme_config::root_only was set, the cell attribute
    would still provide read access to everybody.
    
    Mask out permissions not available on the main attribute.
    
    Fixes: 0331c611949f ("nvmem: core: Expose cells through sysfs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240628113704.13742-5-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nvmem: core: only change name to fram for current attribute [+ + +]
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Fri Jun 28 12:37:03 2024 +0100

    nvmem: core: only change name to fram for current attribute
    
    commit 0ba424c934fd43dccf0d597e1ae8851f07cb2edf upstream.
    
    bin_attr_nvmem_eeprom_compat is the template from which all future
    compat attributes are created.
    Changing it means to change all subsquent compat attributes, too.
    
    Instead only use the "fram" name for the currently registered attribute.
    
    Fixes: fd307a4ad332 ("nvmem: prepare basics for FRAM support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240628113704.13742-4-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nvmem: meson-efuse: Fix return value of nvmem callbacks [+ + +]
Author: Joy Chakraborty <joychakr@google.com>
Date:   Fri Jun 28 12:37:02 2024 +0100

    nvmem: meson-efuse: Fix return value of nvmem callbacks
    
    commit 7a0a6d0a7c805f9380381f4deedffdf87b93f408 upstream.
    
    Read/write callbacks registered with nvmem core expect 0 to be returned
    on success and a negative value to be returned on failure.
    
    meson_efuse_read() and meson_efuse_write() call into
    meson_sm_call_read() and meson_sm_call_write() respectively which return
    the number of bytes read or written on success as per their api
    description.
    
    Fix to return error if meson_sm_call_read()/meson_sm_call_write()
    returns an error else return 0.
    
    Fixes: a29a63bdaf6f ("nvmem: meson-efuse: simplify read callback")
    Cc: stable@vger.kernel.org
    Signed-off-by: Joy Chakraborty <joychakr@google.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240628113704.13742-3-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nvmem: rmem: Fix return value of rmem_read() [+ + +]
Author: Joy Chakraborty <joychakr@google.com>
Date:   Fri Jun 28 12:37:01 2024 +0100

    nvmem: rmem: Fix return value of rmem_read()
    
    commit 28b008751aa295612318a0fbb2f22dd4f6a83139 upstream.
    
    reg_read() callback registered with nvmem core expects 0 on success and
    a negative value on error but rmem_read() returns the number of bytes
    read which is treated as an error at the nvmem core.
    
    This does not break when rmem is accessed using sysfs via
    bin_attr_nvmem_read()/write() but causes an error when accessed from
    places like nvmem_access_with_keepouts(), etc.
    
    Change to return 0 on success and error in case
    memory_read_from_buffer() returns an error or -EIO if bytes read do not
    match what was requested.
    
    Fixes: 5a3fa75a4d9c ("nvmem: Add driver to expose reserved memory as nvmem")
    Cc: stable@vger.kernel.org
    Signed-off-by: Joy Chakraborty <joychakr@google.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240628113704.13742-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
octeontx2-af: fix a issue with cpt_lf_alloc mailbox [+ + +]
Author: Srujana Challa <schalla@marvell.com>
Date:   Wed Jul 10 13:21:24 2024 +0530

    octeontx2-af: fix a issue with cpt_lf_alloc mailbox
    
    [ Upstream commit 845fe19139ab5a1ee303a3bee327e3191c3938af ]
    
    This patch fixes CPT_LF_ALLOC mailbox error due to
    incompatible mailbox message format. Specifically, it
    corrects the `blkaddr` field type from `int` to `u8`.
    
    Fixes: de2854c87c64 ("octeontx2-af: Mailbox changes for 98xx CPT block")
    Signed-off-by: Srujana Challa <schalla@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-af: fix detection of IP layer [+ + +]
Author: Michal Mazur <mmazur2@marvell.com>
Date:   Wed Jul 10 13:21:25 2024 +0530

    octeontx2-af: fix detection of IP layer
    
    [ Upstream commit 404dc0fd6fb0bb942b18008c6f8c0320b80aca20 ]
    
    Checksum and length checks are not enabled for IPv4 header with
    options and IPv6 with extension headers.
    To fix this a change in enum npc_kpu_lc_ltype is required which will
    allow adjustment of LTYPE_MASK to detect all types of IP headers.
    
    Fixes: 21e6699e5cd6 ("octeontx2-af: Add NPC KPU profile")
    Signed-off-by: Michal Mazur <mmazur2@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-af: Fix incorrect value output on error path in rvu_check_rsrc_availability() [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Fri Jul 5 12:53:17 2024 +0300

    octeontx2-af: Fix incorrect value output on error path in rvu_check_rsrc_availability()
    
    [ Upstream commit 442e26af9aa8115c96541026cbfeaaa76c85d178 ]
    
    In rvu_check_rsrc_availability() in case of invalid SSOW req, an incorrect
    data is printed to error log. 'req->sso' value is printed instead of
    'req->ssow'. Looks like "copy-paste" mistake.
    
    Fix this mistake by replacing 'req->sso' with 'req->ssow'.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 746ea74241fa ("octeontx2-af: Add RVU block LF provisioning support")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20240705095317.12640-1-amishin@t-argos.ru
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-af: fix issue with IPv4 match for RSS [+ + +]
Author: Satheesh Paul <psatheesh@marvell.com>
Date:   Wed Jul 10 13:21:27 2024 +0530

    octeontx2-af: fix issue with IPv4 match for RSS
    
    [ Upstream commit 60795bbf047654c9f8ae88d34483233a56033578 ]
    
    While performing RSS based on IPv4, packets with
    IPv4 options are not being considered. Adding changes
    to match both plain IPv4 and IPv4 with option header.
    
    Fixes: 41a7aa7b800d ("octeontx2-af: NIX Rx flowkey configuration for RSS")
    Signed-off-by: Satheesh Paul <psatheesh@marvell.com>
    Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-af: fix issue with IPv6 ext match for RSS [+ + +]
Author: Kiran Kumar K <kirankumark@marvell.com>
Date:   Wed Jul 10 13:21:26 2024 +0530

    octeontx2-af: fix issue with IPv6 ext match for RSS
    
    [ Upstream commit e23ac1095b9eb8ac48f98c398d81d6ba062c9b5d ]
    
    While performing RSS based on IPv6, extension ltype
    is not being considered. This will be problem for
    fragmented packets or packets with extension header.
    Adding changes to match IPv6 ext header along with IPv6
    ltype.
    
    Fixes: 41a7aa7b800d ("octeontx2-af: NIX Rx flowkey configuration for RSS")
    Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
    Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-af: replace cpt slot with lf id on reg write [+ + +]
Author: Nithin Dabilpuram <ndabilpuram@marvell.com>
Date:   Wed Jul 10 13:21:23 2024 +0530

    octeontx2-af: replace cpt slot with lf id on reg write
    
    [ Upstream commit bc35e28af7890085dcbe5cc32373647dfb4d9af9 ]
    
    Replace slot id with global CPT lf id on reg read/write as
    CPTPF/VF driver would send slot number instead of global
    lf id in the reg offset. And also update the mailbox response
    with the global lf's register offset.
    
    Fixes: ae454086e3c2 ("octeontx2-af: add mailbox interface for CPT")
    Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: toshiba_acpi: Fix array out-of-bounds access [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Tue Jul 9 16:38:51 2024 +0200

    platform/x86: toshiba_acpi: Fix array out-of-bounds access
    
    commit b6e02c6b0377d4339986e07aeb696c632cd392aa upstream.
    
    In order to use toshiba_dmi_quirks[] together with the standard DMI
    matching functions, it must be terminated by a empty entry.
    
    Since this entry is missing, an array out-of-bounds access occurs
    every time the quirk list is processed.
    
    Fix this by adding the terminating empty entry.
    
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Closes: https://lore.kernel.org/oe-lkp/202407091536.8b116b3d-lkp@intel.com
    Fixes: 3cb1f40dfdc3 ("drivers/platform: toshiba_acpi: Call HCI_PANEL_POWER_ON on resume on some models")
    Cc: stable@vger.kernel.org
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20240709143851.10097-1-W_Armin@gmx.de
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pmdomain: qcom: rpmhpd: Skip retention level for Power Domains [+ + +]
Author: Taniya Das <quic_tdas@quicinc.com>
Date:   Tue Jun 25 10:03:11 2024 +0530

    pmdomain: qcom: rpmhpd: Skip retention level for Power Domains
    
    commit ddab91f4b2de5c5b46e312a90107d9353087d8ea upstream.
    
    In the cases where the power domain connected to logics is allowed to
    transition from a level(L)-->power collapse(0)-->retention(1) or
    vice versa retention(1)-->power collapse(0)-->level(L)  will cause the
    logic to lose the configurations. The ARC does not support retention
    to collapse transition on MxC rails.
    
    The targets from SM8450 onwards the PLL logics of clock controllers are
    connected to MxC rails and the recommended configurations are carried
    out during the clock controller probes. The MxC transition as mentioned
    above should be skipped to ensure the PLL settings are intact across
    clock controller power on & off.
    
    On older targets that do not split MX into MxA and MxC does not collapse
    the logic and it is parked always at RETENTION, thus this issue is never
    observed on those targets.
    
    Cc: stable@vger.kernel.org # v5.17
    Reviewed-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
    Link: https://lore.kernel.org/r/20240625-avoid_mxc_retention-v2-1-af9c2f549a5f@quicinc.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ppp: reject claimed-as-LCP but actually malformed packets [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Mon Jul 8 14:56:15 2024 +0300

    ppp: reject claimed-as-LCP but actually malformed packets
    
    [ Upstream commit f2aeb7306a898e1cbd03963d376f4b6656ca2b55 ]
    
    Since 'ppp_async_encode()' assumes valid LCP packets (with code
    from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that
    LCP packet has an actual body beyond PPP_LCP header bytes, and
    reject claimed-as-LCP but actually malformed data otherwise.
    
    Reported-by: syzbot+ec0723ba9605678b14bf@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=ec0723ba9605678b14bf
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "dt-bindings: cache: qcom,llcc: correct QDU1000 reg entries" [+ + +]
Author: Komal Bajaj <quic_kbajaj@quicinc.com>
Date:   Wed Jun 19 11:46:41 2024 +0530

    Revert "dt-bindings: cache: qcom,llcc: correct QDU1000 reg entries"
    
    commit e227c11179dfb6970360c95a8d7b007eb3b223d6 upstream.
    
    This reverts commit f0f99f371822c48847e02e56d6e7de507e18f186.
    
    QDU1000 has 7 register regions. The earlier commit 8e2506d01231
    ("dt-bindings: cache: qcom,llcc: Add LLCC compatible for QDU1000/QRU1000")
    to add llcc compatible was reflecting the same, but dtsi change for
    QDU1000 was not aligning with its binding. Later, commit f0f99f371822
    ("dt-bindings: cache: qcom,llcc: correct QDU1000 reg entries") was merged
    intended to fix this misalignment.
    
    After the LLCC driver refactor, each LLCC bank/channel need to be
    represented as one register space to avoid mapping to the region where
    access is not there. Hence, revert the commit f0f99f371822 ("dt-bindings:
    cache: qcom,llcc: correct QDU1000 reg entries") to align QDU1000 llcc
    binding with its dtsi node.
    
    Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20240619061641.5261-3-quic_kbajaj@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "sched/fair: Make sure to try to detach at least one movable task" [+ + +]
Author: Josh Don <joshdon@google.com>
Date:   Thu Jun 20 14:44:50 2024 -0700

    Revert "sched/fair: Make sure to try to detach at least one movable task"
    
    commit 2feab2492deb2f14f9675dd6388e9e2bf669c27a upstream.
    
    This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.
    
    b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if
    all tasks examined to that point were pinned. The goal of the patch was
    to make it more likely to be able to detach a task buried in a long list
    of pinned tasks. However, this has the unfortunate side effect of
    creating an O(n) iteration in detach_tasks(), as we now must fully
    iterate every task on a cpu if all or most are pinned. Since this load
    balance code is done with rq lock held, and often in softirq context, it
    is very easy to trigger hard lockups. We observed such hard lockups with
    a user who affined O(10k) threads to a single cpu.
    
    When I discussed this with Vincent he initially suggested that we keep
    the limit on the number of tasks to detach, but increase the number of
    tasks we can search. However, after some back and forth on the mailing
    list, he recommended we instead revert the original patch, as it seems
    likely no one was actually getting hit by the original issue.
    
    Fixes: b0defa7ae03e ("sched/fair: Make sure to try to detach at least one movable task")
    Signed-off-by: Josh Don <joshdon@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://lore.kernel.org/r/20240620214450.316280-1-joshdon@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/mm: Add NULL pointer check to crst_table_free() base_crst_free() [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Tue Jul 9 08:50:56 2024 +0200

    s390/mm: Add NULL pointer check to crst_table_free() base_crst_free()
    
    commit b5efb63acf7bddaf20eacfcac654c25c446eabe8 upstream.
    
    crst_table_free() used to work with NULL pointers before the conversion
    to ptdescs.  Since crst_table_free() can be called with a NULL pointer
    (error handling in crst_table_upgrade() add an explicit check.
    
    Also add the same check to base_crst_free() for consistency reasons.
    
    In real life this should not happen, since order two GFP_KERNEL
    allocations will not fail, unless FAIL_PAGE_ALLOC is enabled and used.
    
    Reported-by: Yunseong Kim <yskelg@gmail.com>
    Fixes: 6326c26c1514 ("s390: convert various pgalloc functions to use ptdescs")
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sched/deadline: Fix task_struct reference leak [+ + +]
Author: Wander Lairson Costa <wander@redhat.com>
Date:   Thu Jun 20 09:56:17 2024 -0300

    sched/deadline: Fix task_struct reference leak
    
    [ Upstream commit b58652db66c910c2245f5bee7deca41c12d707b9 ]
    
    During the execution of the following stress test with linux-rt:
    
    stress-ng --cyclic 30 --timeout 30 --minimize --quiet
    
    kmemleak frequently reported a memory leak concerning the task_struct:
    
    unreferenced object 0xffff8881305b8000 (size 16136):
      comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s)
      object hex dump (first 32 bytes):
        02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .@..............
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      debug hex dump (first 16 bytes):
        53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00  S...............
      backtrace:
        [<00000000046b6790>] dup_task_struct+0x30/0x540
        [<00000000c5ca0f0b>] copy_process+0x3d9/0x50e0
        [<00000000ced59777>] kernel_clone+0xb0/0x770
        [<00000000a50befdc>] __do_sys_clone+0xb6/0xf0
        [<000000001dbf2008>] do_syscall_64+0x5d/0xf0
        [<00000000552900ff>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    The issue occurs in start_dl_timer(), which increments the task_struct
    reference count and sets a timer. The timer callback, dl_task_timer,
    is supposed to decrement the reference count upon expiration. However,
    if enqueue_task_dl() is called before the timer expires and cancels it,
    the reference count is not decremented, leading to the leak.
    
    This patch fixes the reference leak by ensuring the task_struct
    reference count is properly decremented when the timer is canceled.
    
    Fixes: feff2e65efd8 ("sched/deadline: Unthrottle PI boosted threads while enqueuing")
    Signed-off-by: Wander Lairson Costa <wander@redhat.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Juri Lelli <juri.lelli@redhat.com>
    Link: https://lore.kernel.org/r/20240620125618.11419-1-wander@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: ufs: core: Fix ufshcd_abort_one racing issue [+ + +]
Author: Peter Wang <peter.wang@mediatek.com>
Date:   Fri Jun 28 15:00:30 2024 +0800

    scsi: ufs: core: Fix ufshcd_abort_one racing issue
    
    [ Upstream commit 74736103fb4123c71bf11fb7a6abe7c884c5269e ]
    
    When ufshcd_abort_one is racing with the completion ISR, the completed tag
    of the request's mq_hctx pointer will be set to NULL by ISR.  Return
    success when request is completed by ISR because ufshcd_abort_one does not
    need to do anything.
    
    The racing flow is:
    
    Thread A
    ufshcd_err_handler                                      step 1
            ...
            ufshcd_abort_one
                    ufshcd_try_to_abort_task
                            ufshcd_cmd_inflight(true)       step 3
                    ufshcd_mcq_req_to_hwq
                            blk_mq_unique_tag
                                    rq->mq_hctx->queue_num  step 5
    
    Thread B
    ufs_mtk_mcq_intr(cq complete ISR)                       step 2
            scsi_done
                    ...
                    __blk_mq_free_request
                            rq->mq_hctx = NULL;             step 4
    
    Below is KE back trace.
      ufshcd_try_to_abort_task: cmd at tag 41 not pending in the device.
      ufshcd_try_to_abort_task: cmd at tag=41 is cleared.
      Aborting tag 41 / CDB 0x28 succeeded
      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194
      pc : [0xffffffddd7a79bf8] blk_mq_unique_tag+0x8/0x14
      lr : [0xffffffddd6155b84] ufshcd_mcq_req_to_hwq+0x1c/0x40 [ufs_mediatek_mod_ise]
       do_mem_abort+0x58/0x118
       el1_abort+0x3c/0x5c
       el1h_64_sync_handler+0x54/0x90
       el1h_64_sync+0x68/0x6c
       blk_mq_unique_tag+0x8/0x14
       ufshcd_err_handler+0xae4/0xfa8 [ufs_mediatek_mod_ise]
       process_one_work+0x208/0x4fc
       worker_thread+0x228/0x438
       kthread+0x104/0x1d4
       ret_from_fork+0x10/0x20
    
    Fixes: 93e6c0e19d5b ("scsi: ufs: core: Clear cmd if abort succeeds in MCQ mode")
    Suggested-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Peter Wang <peter.wang@mediatek.com>
    Link: https://lore.kernel.org/r/20240628070030.30929-3-peter.wang@mediatek.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: core: Fix ufshcd_clear_cmd racing issue [+ + +]
Author: Peter Wang <peter.wang@mediatek.com>
Date:   Fri Jun 28 15:00:29 2024 +0800

    scsi: ufs: core: Fix ufshcd_clear_cmd racing issue
    
    [ Upstream commit 9307a998cb9846a2557fdca286997430bee36a2a ]
    
    When ufshcd_clear_cmd is racing with the completion ISR, the completed tag
    of the request's mq_hctx pointer will be set to NULL by the ISR.  And
    ufshcd_clear_cmd's call to ufshcd_mcq_req_to_hwq will get NULL pointer KE.
    Return success when the request is completed by ISR because sq does not
    need cleanup.
    
    The racing flow is:
    
    Thread A
    ufshcd_err_handler                                      step 1
            ufshcd_try_to_abort_task
                    ufshcd_cmd_inflight(true)               step 3
                    ufshcd_clear_cmd
                            ...
                            ufshcd_mcq_req_to_hwq
                            blk_mq_unique_tag
                                    rq->mq_hctx->queue_num  step 5
    
    Thread B
    ufs_mtk_mcq_intr(cq complete ISR)                       step 2
            scsi_done
                    ...
                    __blk_mq_free_request
                            rq->mq_hctx = NULL;             step 4
    
    Below is KE back trace:
    
      ufshcd_try_to_abort_task: cmd pending in the device. tag = 6
      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194
       pc : [0xffffffd589679bf8] blk_mq_unique_tag+0x8/0x14
       lr : [0xffffffd5862f95b4] ufshcd_mcq_sq_cleanup+0x6c/0x1cc [ufs_mediatek_mod_ise]
       Workqueue: ufs_eh_wq_0 ufshcd_err_handler [ufs_mediatek_mod_ise]
       Call trace:
        dump_backtrace+0xf8/0x148
        show_stack+0x18/0x24
        dump_stack_lvl+0x60/0x7c
        dump_stack+0x18/0x3c
        mrdump_common_die+0x24c/0x398 [mrdump]
        ipanic_die+0x20/0x34 [mrdump]
        notify_die+0x80/0xd8
        die+0x94/0x2b8
        __do_kernel_fault+0x264/0x298
        do_page_fault+0xa4/0x4b8
        do_translation_fault+0x38/0x54
        do_mem_abort+0x58/0x118
        el1_abort+0x3c/0x5c
        el1h_64_sync_handler+0x54/0x90
        el1h_64_sync+0x68/0x6c
        blk_mq_unique_tag+0x8/0x14
        ufshcd_clear_cmd+0x34/0x118 [ufs_mediatek_mod_ise]
        ufshcd_try_to_abort_task+0x2c8/0x5b4 [ufs_mediatek_mod_ise]
        ufshcd_err_handler+0xa7c/0xfa8 [ufs_mediatek_mod_ise]
        process_one_work+0x208/0x4fc
        worker_thread+0x228/0x438
        kthread+0x104/0x1d4
        ret_from_fork+0x10/0x20
    
    Fixes: 8d7290348992 ("scsi: ufs: mcq: Add supporting functions for MCQ abort")
    Suggested-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Peter Wang <peter.wang@mediatek.com>
    Link: https://lore.kernel.org/r/20240628070030.30929-2-peter.wang@mediatek.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: imx: ensure RTS signal is not left active after shutdown [+ + +]
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Tue Jun 25 20:42:05 2024 +0200

    serial: imx: ensure RTS signal is not left active after shutdown
    
    commit 1af2156e58f3af1216ce2f0456b3b8949faa5c7e upstream.
    
    If a process is killed while writing to a /dev/ttymxc* device in RS485
    mode, we observe that the RTS signal is left high, thus making it
    impossible for other devices to transmit anything.
    
    Moreover, the ->tx_state variable is left in state SEND, which means
    that when one next opens the device and configures baud rate etc., the
    initialization code in imx_uart_set_termios dutifully ensures the RTS
    pin is pulled down, but since ->tx_state is already SEND, the logic in
    imx_uart_start_tx() does not in fact pull the pin high before
    transmitting, so nothing actually gets on the wire on the other side
    of the transceiver. Only when that transmission is allowed to complete
    is the state machine then back in a consistent state.
    
    This is completely reproducible by doing something as simple as
    
      seq 10000 > /dev/ttymxc0
    
    and hitting ctrl-C, and watching with a logic analyzer.
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Cc: stable <stable@kernel.org>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Link: https://lore.kernel.org/r/20240625184206.508837-1-linux@rasmusvillemoes.dk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
skmsg: Skip zero length skb in sk_msg_recvmsg [+ + +]
Author: Geliang Tang <geliang@kernel.org>
Date:   Wed Jul 3 16:39:31 2024 +0800

    skmsg: Skip zero length skb in sk_msg_recvmsg
    
    [ Upstream commit f0c18025693707ec344a70b6887f7450bf4c826b ]
    
    When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch
    platform, the following kernel panic occurs:
    
      [...]
      Oops[#1]:
      CPU: 22 PID: 2824 Comm: test_progs Tainted: G           OE  6.10.0-rc2+ #18
      Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018
         ... ...
         ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560
        ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0
       CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
       PRMD: 0000000c (PPLV0 +PIE +PWE)
       EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
       ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
      ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
       BADV: 0000000000000040
       PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)
      Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack
      Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)
      Stack : ...
      Call Trace:
      [<9000000004162774>] copy_page_to_iter+0x74/0x1c0
      [<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560
      [<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0
      [<90000000049aae34>] inet_recvmsg+0x54/0x100
      [<900000000481ad5c>] sock_recvmsg+0x7c/0xe0
      [<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0
      [<900000000481e27c>] sys_recvfrom+0x1c/0x40
      [<9000000004c076ec>] do_syscall+0x8c/0xc0
      [<9000000003731da4>] handle_syscall+0xc4/0x160
      Code: ...
      ---[ end trace 0000000000000000 ]---
      Kernel panic - not syncing: Fatal exception
      Kernel relocated by 0x3510000
       .text @ 0x9000000003710000
       .data @ 0x9000000004d70000
       .bss  @ 0x9000000006469400
      ---[ end Kernel panic - not syncing: Fatal exception ]---
      [...]
    
    This crash happens every time when running sockmap_skb_verdict_shutdown
    subtest in sockmap_basic.
    
    This crash is because a NULL pointer is passed to page_address() in the
    sk_msg_recvmsg(). Due to the different implementations depending on the
    architecture, page_address(NULL) will trigger a panic on Loongarch
    platform but not on x86 platform. So this bug was hidden on x86 platform
    for a while, but now it is exposed on Loongarch platform. The root cause
    is that a zero length skb (skb->len == 0) was put on the queue.
    
    This zero length skb is a TCP FIN packet, which was sent by shutdown(),
    invoked in test_sockmap_skb_verdict_shutdown():
    
            shutdown(p1, SHUT_WR);
    
    In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no
    page is put to this sge (see sg_set_page in sg_set_page), but this empty
    sge is queued into ingress_msg list.
    
    And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by
    sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it
    to kmap_local_page() and to page_address(), then kernel panics.
    
    To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),
    if copy is zero, that means it's a zero length skb, skip invoking
    copy_page_to_iter(). We are using the EFAULT return triggered by
    copy_page_to_iter to check for is_fin in tcp_bpf.c.
    
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Suggested-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/bpf/e3a16eacdc6740658ee02a33489b1b9d4912f378.1719992715.git.tanggeliang@kylinos.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: add defer_optimize_message controller flag [+ + +]
Author: David Lechner <dlechner@baylibre.com>
Date:   Mon Jul 8 20:05:29 2024 -0500

    spi: add defer_optimize_message controller flag
    
    [ Upstream commit ca52aa4c60f76566601b42e935b8a78f0fb4f8eb ]
    
    Adding spi_optimize_message() broke the spi-mux driver because it
    calls spi_async() from it's transfer_one_message() callback. This
    resulted in passing an incorrectly optimized message to the controller.
    For example, if the underlying controller has an optimize_message()
    callback, this would have not been called and can cause a crash when
    the underlying controller driver tries to transfer the message.
    
    Also, since the spi-mux driver swaps out the controller pointer by
    replacing msg->spi, __spi_unoptimize_message() was being called with a
    different controller than the one used in __spi_optimize_message(). This
    could cause a crash when attempting to free the message resources when
    __spi_unoptimize_message() is called in spi_finalize_current_message()
    since it is being called with a controller that did not allocate the
    resources.
    
    This is fixed by adding a defer_optimize_message flag for controllers.
    This flag causes all of the spi_[maybe_][un]optimize_message() calls to
    be a no-op (other than attaching a pointer to the spi device to the
    message).
    
    This allows the spi-mux driver to pass an unmodified message to
    spi_async() in spi_mux_transfer_one_message() after the spi device has
    been swapped out. This causes __spi_optimize_message() and
    __spi_unoptimize_message() to be called only once per message and with
    the correct/same controller in each case.
    
    Reported-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Closes: https://lore.kernel.org/linux-spi/Zn6HMrYG2b7epUxT@pengutronix.de/
    Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Closes: https://lore.kernel.org/linux-spi/20240628-awesome-discerning-bear-1621f9-mkl@pengutronix.de/
    Fixes: 7b1d87af14d9 ("spi: add spi_optimize_message() APIs")
    Signed-off-by: David Lechner <dlechner@baylibre.com>
    Link: https://patch.msgid.link/20240708-spi-mux-fix-v1-2-6c8845193128@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: axi-spi-engine: fix sleep calculation [+ + +]
Author: David Lechner <dlechner@baylibre.com>
Date:   Thu Jun 20 11:43:58 2024 -0500

    spi: axi-spi-engine: fix sleep calculation
    
    [ Upstream commit 40b3d0838a1ff242e61f341e49226074bbdd319f ]
    
    The sleep calculation was not taking into account increased delay when
    the SPI device is not running at the maximum SCLK frequency.
    
    Rounding down when one SCLK tick was the same as the instruction
    execution time was fine, but it rounds down too much when SCLK is
    slower. This changes the rounding to round up instead while still
    taking into account the instruction execution time so that small
    delays remain accurate.
    
    Fixes: be9070bcf670 ("spi: axi-spi-engine: fix sleep ticks calculation")
    Signed-off-by: David Lechner <dlechner@baylibre.com>
    Link: https://patch.msgid.link/20240620-spi-axi-spi-engine-fix-sleep-time-v1-1-b20b527924a0@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: don't unoptimize message in spi_async() [+ + +]
Author: David Lechner <dlechner@baylibre.com>
Date:   Mon Jul 8 20:05:28 2024 -0500

    spi: don't unoptimize message in spi_async()
    
    [ Upstream commit c86a918b1bdba78fb155184f8d88dfba1e63335d ]
    
    Calling spi_maybe_unoptimize_message() in spi_async() is wrong because
    the message is likely to be in the queue and not transferred yet. This
    can corrupt the message while it is being used by the controller driver.
    
    spi_maybe_unoptimize_message() is already called in the correct place
    in spi_finalize_current_message() to balance the call to
    spi_maybe_optimize_message() in spi_async().
    
    Fixes: 7b1d87af14d9 ("spi: add spi_optimize_message() APIs")
    Signed-off-by: David Lechner <dlechner@baylibre.com>
    Link: https://patch.msgid.link/20240708-spi-mux-fix-v1-1-6c8845193128@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp: avoid too many retransmit packets [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jul 10 00:14:01 2024 +0000

    tcp: avoid too many retransmit packets
    
    [ Upstream commit 97a9063518f198ec0adb2ecb89789de342bb8283 ]
    
    If a TCP socket is using TCP_USER_TIMEOUT, and the other peer
    retracted its window to zero, tcp_retransmit_timer() can
    retransmit a packet every two jiffies (2 ms for HZ=1000),
    for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.
    
    The fix is to make sure tcp_rtx_probe0_timed_out() takes
    icsk->icsk_user_timeout into account.
    
    Before blamed commit, the socket would not timeout after
    icsk->icsk_user_timeout, but would use standard exponential
    backoff for the retransmits.
    
    Also worth noting that before commit e89688e3e978 ("net: tcp:
    fix unexcepted socket die when snd_wnd is 0"), the issue
    would last 2 minutes instead of 4.
    
    Fixes: b701a99e431d ("tcp: Add tcp_clamp_rto_to_user_timeout() helper to improve accuracy")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
    Reviewed-by: Jon Maxwell <jmaxwell37@gmail.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://patch.msgid.link/20240710001402.2758273-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: fix incorrect undo caused by DSACK of TLP retransmit [+ + +]
Author: Neal Cardwell <ncardwell@google.com>
Date:   Wed Jul 3 13:12:46 2024 -0400

    tcp: fix incorrect undo caused by DSACK of TLP retransmit
    
    [ Upstream commit 0ec986ed7bab6801faed1440e8839dcc710331ff ]
    
    Loss recovery undo_retrans bookkeeping had a long-standing bug where a
    DSACK from a spurious TLP retransmit packet could cause an erroneous
    undo of a fast recovery or RTO recovery that repaired a single
    really-lost packet (in a sequence range outside that of the TLP
    retransmit). Basically, because the loss recovery state machine didn't
    account for the fact that it sent a TLP retransmit, the DSACK for the
    TLP retransmit could erroneously be implicitly be interpreted as
    corresponding to the normal fast recovery or RTO recovery retransmit
    that plugged a real hole, thus resulting in an improper undo.
    
    For example, consider the following buggy scenario where there is a
    real packet loss but the congestion control response is improperly
    undone because of this bug:
    
    + send packets P1, P2, P3, P4
    + P1 is really lost
    + send TLP retransmit of P4
    + receive SACK for original P2, P3, P4
    + enter fast recovery, fast-retransmit P1, increment undo_retrans to 1
    + receive DSACK for TLP P4, decrement undo_retrans to 0, undo (bug!)
    + receive cumulative ACK for P1-P4 (fast retransmit plugged real hole)
    
    The fix: when we initialize undo machinery in tcp_init_undo(), if
    there is a TLP retransmit in flight, then increment tp->undo_retrans
    so that we make sure that we receive a DSACK corresponding to the TLP
    retransmit, as well as DSACKs for all later normal retransmits, before
    triggering a loss recovery undo. Note that we also have to move the
    line that clears tp->tlp_high_seq for RTO recovery, so that upon RTO
    we remember the tp->tlp_high_seq value until tcp_init_undo() and clear
    it only afterward.
    
    Also note that the bug dates back to the original 2013 TLP
    implementation, commit 6ba8a3b19e76 ("tcp: Tail loss probe (TLP)").
    
    However, this patch will only compile and work correctly with kernels
    that have tp->tlp_retrans, which was added only in v5.8 in 2020 in
    commit 76be93fc0702 ("tcp: allow at most one TLP probe per flight").
    So we associate this fix with that later commit.
    
    Fixes: 76be93fc0702 ("tcp: allow at most one TLP probe per flight")
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Kevin Yang <yyd@google.com>
    Link: https://patch.msgid.link/20240703171246.1739561-1-ncardwell.sw@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tty: serial: ma35d1: Add a NULL check for of_node [+ + +]
Author: Jacky Huang <ychuang3@nuvoton.com>
Date:   Tue Jun 25 06:41:28 2024 +0000

    tty: serial: ma35d1: Add a NULL check for of_node
    
    commit acd09ac253b5de8fd79fc61a482ee19154914c7a upstream.
    
    The pdev->dev.of_node can be NULL if the "serial" node is absent.
    Add a NULL check to return an error in such cases.
    
    Fixes: 930cbf92db01 ("tty: serial: Add Nuvoton ma35d1 serial driver support")
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/all/8df7ce45-fd58-4235-88f7-43fe7cd67e8f@moroto.mountain/
    Signed-off-by: Jacky Huang <ychuang3@nuvoton.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20240625064128.127-1-ychuang570808@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jul 9 12:13:56 2024 -0700

    udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
    
    [ Upstream commit 5c0b485a8c6116516f33925b9ce5b6104a6eadfd ]
    
    syzkaller triggered the warning [0] in udp_v4_early_demux().
    
    In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount
    of the looked-up sk and use sock_pfree() as skb->destructor, so we check
    SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace
    period.
    
    Currently, SOCK_RCU_FREE is flagged for a bound socket after being put
    into the hash table.  Moreover, the SOCK_RCU_FREE check is done too early
    in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race
    window:
    
      CPU1                                 CPU2
      ----                                 ----
      udp_v4_early_demux()                 udp_lib_get_port()
      |                                    |- hlist_add_head_rcu()
      |- sk = __udp4_lib_demux_lookup()    |
      |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));
                                           `- sock_set_flag(sk, SOCK_RCU_FREE)
    
    We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
    set SOCK_RCU_FREE before inserting socket into hashtable").
    
    Let's apply the same fix for UDP.
    
    [0]:
    WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
    Modules linked in:
    CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
    Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52
    RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c
    RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001
    RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680
    R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e
    FS:  00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
    PKRU: 55555554
    Call Trace:
     <TASK>
     ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349
     ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447
     NF_HOOK include/linux/netfilter.h:314 [inline]
     NF_HOOK include/linux/netfilter.h:308 [inline]
     ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569
     __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624
     __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738
     netif_receive_skb_internal net/core/dev.c:5824 [inline]
     netif_receive_skb+0x271/0x300 net/core/dev.c:5884
     tun_rx_batched drivers/net/tun.c:1549 [inline]
     tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002
     tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048
     new_sync_write fs/read_write.c:497 [inline]
     vfs_write+0x76f/0x8d0 fs/read_write.c:590
     ksys_write+0xbf/0x190 fs/read_write.c:643
     __do_sys_write fs/read_write.c:655 [inline]
     __se_sys_write fs/read_write.c:652 [inline]
     __x64_sys_write+0x41/0x50 fs/read_write.c:652
     x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x4b/0x53
    RIP: 0033:0x7fc44a68bc1f
    Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48
    RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f
    RDX: 0000000000000032 RSI: 00000000200000c0 RDI: 00000000000000c8
    RBP: 00000000004bc050 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000032 R11: 0000000000000293 R12: 0000000000000000
    R13: 000000000000000b R14: 00007fc44a5ec530 R15: 0000000000000000
     </TASK>
    
    Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20240709191356.24010-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
USB: Add USB_QUIRK_NO_SET_INTF quirk for START BP-850k [+ + +]
Author: WangYuli <wangyuli@uniontech.com>
Date:   Tue Jul 2 23:44:08 2024 +0800

    USB: Add USB_QUIRK_NO_SET_INTF quirk for START BP-850k
    
    commit 3859e85de30815a20bce7db712ce3d94d40a682d upstream.
    
    START BP-850K is a dot matrix printer that crashes when
    it receives a Set-Interface request and needs USB_QUIRK_NO_SET_INTF
    to work properly.
    
    Cc: stable <stable@kernel.org>
    Signed-off-by: jinxiaobo <jinxiaobo@uniontech.com>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Link: https://lore.kernel.org/r/202E4B2BD0F0FEA4+20240702154408.631201-1-wangyuli@uniontech.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: core: add missing of_node_put() in usb_of_has_devices_or_graph [+ + +]
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Mon Jun 24 23:10:06 2024 +0200

    usb: core: add missing of_node_put() in usb_of_has_devices_or_graph
    
    commit c7a5403ea04320e08f2595baa940541a59a3856e upstream.
    
    The for_each_child_of_node() macro requires an explicit call to
    of_node_put() on early exits to decrement the child refcount and avoid a
    memory leak.
    The child node is not required outsie the loop, and the resource must be
    released before the function returns.
    
    Add the missing of_node_put().
    
    Cc: stable@vger.kernel.org
    Fixes: 82e82130a78b ("usb: core: Set connect_type of ports based on DT node")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Link: https://lore.kernel.org/r/20240624-usb_core_of_memleak-v1-1-af6821c1a584@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Jun 27 15:56:18 2024 -0400

    USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
    
    commit a368ecde8a5055b627749b09c6218ef793043e47 upstream.
    
    Syzbot has identified a bug in usbcore (see the Closes: tag below)
    caused by our assumption that the reserved bits in an endpoint
    descriptor's bEndpointAddress field will always be 0.  As a result of
    the bug, the endpoint_is_duplicate() routine in config.c (and possibly
    other routines as well) may believe that two descriptors are for
    distinct endpoints, even though they have the same direction and
    endpoint number.  This can lead to confusion, including the bug
    identified by syzbot (two descriptors with matching endpoint numbers
    and directions, where one was interrupt and the other was bulk).
    
    To fix the bug, we will clear the reserved bits in bEndpointAddress
    when we parse the descriptor.  (Note that both the USB-2.0 and USB-3.1
    specs say these bits are "Reserved, reset to zero".)  This requires us
    to make a copy of the descriptor earlier in usb_parse_endpoint() and
    use the copy instead of the original when checking for duplicates.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: syzbot+8693a0bb9c10b554272a@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-usb/0000000000003d868e061bc0f554@google.com/
    Fixes: 0a8fd1346254 ("USB: fix problems with duplicate endpoint addresses")
    CC: Oliver Neukum <oneukum@suse.com>
    CC: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/205a5edc-7fef-4159-b64a-80374b6b101a@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: dwc3: pci: add support for the Intel Panther Lake [+ + +]
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Fri Jun 28 14:18:34 2024 +0300

    usb: dwc3: pci: add support for the Intel Panther Lake
    
    commit 2bf35ea46d0bc379c456e14c0ec1dc1e003b39f1 upstream.
    
    This patch adds the necessary PCI IDs for Intel Panther Lake
    devices.
    
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Cc: stable <stable@kernel.org>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240628111834.1498461-1-heikki.krogerus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: configfs: Prevent OOB read/write in usb_string_copy() [+ + +]
Author: Lee Jones <lee@kernel.org>
Date:   Fri Jul 5 08:43:39 2024 +0100

    usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
    
    commit 6d3c721e686ea6c59e18289b400cc95c76e927e0 upstream.
    
    Userspace provided string 's' could trivially have the length zero. Left
    unchecked this will firstly result in an OOB read in the form
    `if (str[0 - 1] == '\n') followed closely by an OOB write in the form
    `str[0 - 1] = '\0'`.
    
    There is already a validating check to catch strings that are too long.
    Let's supply an additional check for invalid strings that are too short.
    
    Signed-off-by: Lee Jones <lee@kernel.org>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20240705074339.633717-1-lee@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: serial: mos7840: fix crash on resume [+ + +]
Author: Dmitry Smirnov <d.smirnov@inbox.lv>
Date:   Sat Jun 15 01:45:56 2024 +0300

    USB: serial: mos7840: fix crash on resume
    
    commit c15a688e49987385baa8804bf65d570e362f8576 upstream.
    
    Since commit c49cfa917025 ("USB: serial: use generic method if no
    alternative is provided in usb serial layer"), USB serial core calls the
    generic resume implementation when the driver has not provided one.
    
    This can trigger a crash on resume with mos7840 since support for
    multiple read URBs was added back in 2011. Specifically, both port read
    URBs are now submitted on resume for open ports, but the context pointer
    of the second URB is left set to the core rather than mos7840 port
    structure.
    
    Fix this by implementing dedicated suspend and resume functions for
    mos7840.
    
    Tested with Delock 87414 USB 2.0 to 4x serial adapter.
    
    Signed-off-by: Dmitry Smirnov <d.smirnov@inbox.lv>
    [ johan: analyse crash and rewrite commit message; set busy flag on
             resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]
    Fixes: d83b405383c9 ("USB: serial: add support for multiple read urbs")
    Cc: stable@vger.kernel.org      # 3.3
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Fibocom FM350-GL [+ + +]
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed Jun 26 15:32:23 2024 +0200

    USB: serial: option: add Fibocom FM350-GL
    
    commit 2604e08ff251dba330e16b65e80074c9c540aad7 upstream.
    
    FM350-GL is 5G Sub-6 WWAN module which uses M.2 form factor interface.
    It is based on Mediatek's MTK T700 CPU. The module supports PCIe Gen3
    x1 and USB 2.0 and 3.0 interfaces.
    
    The manufacturer states that USB is "for debug" but it has been
    confirmed to be fully functional, except for modem-control requests on
    some of the interfaces.
    
    USB device composition is controlled by AT+GTUSBMODE=<mode> command.
    Two values are currently supported for the <mode>:
    
    40: RNDIS+AT+AP(GNSS)+META+DEBUG+NPT+ADB
    41: RNDIS+AT+AP(GNSS)+META+DEBUG+NPT+ADB+AP(LOG)+AP(META) (default value)
    
    [ Note that the functions above are not ordered by interface number. ]
    
    Mode 40 corresponds to:
    
    T:  Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 22 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0e8d ProdID=7126 Rev= 0.01
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=FM350-GL
    C:* #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=rndis_host
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=125us
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Mode 41 corresponds to:
    
    T:  Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  7 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0e8d ProdID=7127 Rev= 0.01
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=FM350-GL
    C:* #Ifs=10 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=rndis_host
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=125us
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Netprisma LCUK54 series modules [+ + +]
Author: Mank Wang <mank.wang@netprisma.us>
Date:   Sat Jun 29 01:54:45 2024 +0000

    USB: serial: option: add Netprisma LCUK54 series modules
    
    commit dc6dbe3ed28795b01c712ad8f567728f9c14b01d upstream.
    
    Add support for Netprisma LCUK54 series modules.
    
    LCUK54-WRD-LWW(0x3731/0x0100): NetPrisma LCUK54-WWD for Global
    LCUK54-WRD-LWW(0x3731/0x0101): NetPrisma LCUK54-WRD for Global SKU
    LCUK54-WRD-LCN(0x3731/0x0106): NetPrisma LCUK54-WRD for China SKU
    LCUK54-WRD-LWW(0x3731/0x0111): NetPrisma LCUK54-WWD for SA
    LCUK54-WRD-LWW(0x3731/0x0112): NetPrisma LCUK54-WWD for EU
    LCUK54-WRD-LWW(0x3731/0x0113): NetPrisma LCUK54-WWD for NA
    LCUK54-WWD-LCN(0x3731/0x0115): NetPrisma LCUK54-WWD for China EDU
    LCUK54-WWD-LWW(0x3731/0x0116): NetPrisma LCUK54-WWD for Golbal EDU
    
    Above products use the exact same interface layout and option
    driver:
    MBIM + GNSS + DIAG + NMEA + AT + QDSS + DPL
    
    T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  5 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=3731 ProdID=0101 Rev= 5.04
    S:  Manufacturer=NetPrisma
    S:  Product=LCUK54-WRD
    S:  SerialNumber=b6250c36
    C:* #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none)
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=8f(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Mank Wang <mank.wang@netprisma.us>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Rolling RW350-GL variants [+ + +]
Author: Vanillan Wang <vanillanwang@163.com>
Date:   Fri May 31 10:40:12 2024 +0800

    USB: serial: option: add Rolling RW350-GL variants
    
    commit ae420771551bd9f04347c59744dd062332bdec3e upstream.
    
    Update the USB serial option driver support for the Rolling
    RW350-GL
    - VID:PID 33f8:0802, RW350-GL are laptop M.2 cards (with
    MBIM interfaces for /Linux/Chrome OS)
    
    Here are the outputs of usb-devices:
    
    usbmode=63: mbim, pipe
    
    T:  Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
    P:  Vendor=33f8 ProdID=0802 Rev=00.01
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=USB DATA CARD
    C:  #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    usbmode=64: mbim, others at (If#= 5 adb)
    
    MBIM(MI0) + GNSS(MI2) + AP log(MI3) + AP META(MI4) + ADB(MI5) +
    MD AT(MI6) + MD META(MI7) + NPT(MI8) + Debug(MI9)
    
    T:  Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  5 Spd=5000 MxCh= 0
    D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
    P:  Vendor=33f8 ProdID=0802 Rev=00.01
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=USB DATA CARD
    C:  #Ifs=10 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=06(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=07(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=08(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=89(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=09(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=8a(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Signed-off-by: Vanillan Wang <vanillanwang@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add support for Foxconn T99W651 [+ + +]
Author: Slark Xiao <slark_xiao@163.com>
Date:   Fri Jul 5 16:17:09 2024 +0800

    USB: serial: option: add support for Foxconn T99W651
    
    commit 3c841d54b63e4446383de3238399a3910e47d8e2 upstream.
    
    T99W651 is a RNDIS based modem device. There are 3 serial ports
    need to be enumerated: Diag, NMEA and AT.
    
    Test evidence as below:
    T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e145 Rev=05.15
    S:  Manufacturer=QCOM
    S:  Product=SDXPINN-IDP _SN:93B562B2
    S:  SerialNumber=82e6fe26
    C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#=0x0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host
    I:  If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    I:  If#=0x5 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none)
    I:  If#=0x6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    
    0&1: RNDIS, 2:AT, 3:NMEA, 4:DIAG, 5:QDSS, 6:ADB
    QDSS is not a serial port.
    
    Signed-off-by: Slark Xiao <slark_xiao@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Telit FN912 rmnet compositions [+ + +]
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Tue Jun 25 12:27:16 2024 +0200

    USB: serial: option: add Telit FN912 rmnet compositions
    
    commit 9a590ff283421b71560deded2110dbdcbe1f7d1d upstream.
    
    Add the following Telit FN912 compositions:
    
    0x3000: rmnet + tty (AT/NMEA) + tty (AT) + tty (diag)
    T:  Bus=03 Lev=01 Prnt=03 Port=07 Cnt=01 Dev#=  8 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=3000 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN912
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x3001: rmnet + tty (AT) + tty (diag) + DPL (data packet logging) + adb
    T:  Bus=03 Lev=01 Prnt=03 Port=07 Cnt=01 Dev#=  7 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=3001 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN912
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Telit generic core-dump composition [+ + +]
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Thu May 30 10:00:53 2024 +0200

    USB: serial: option: add Telit generic core-dump composition
    
    commit 4298e400dbdbf259549d69c349e060652ad53611 upstream.
    
    Add the following core-dump composition, used in different Telit modems:
    
    0x9000: tty (sahara)
    T:  Bus=03 Lev=01 Prnt=03 Port=07 Cnt=01 Dev#= 41 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=9000 Rev=00.00
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN990-dump
    S:  SerialNumber=e815bdde
    C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=2mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vfio/pci: Init the count variable in collecting hot-reset devices [+ + +]
Author: Yi Liu <yi.l.liu@intel.com>
Date:   Tue Jul 9 17:41:50 2024 -0700

    vfio/pci: Init the count variable in collecting hot-reset devices
    
    [ Upstream commit 5a88a3f67e37e39f933b38ebb4985ba5822e9eca ]
    
    The count variable is used without initialization, it results in mistakes
    in the device counting and crashes the userspace if the get hot reset info
    path is triggered.
    
    Fixes: f6944d4a0b87 ("vfio/pci: Collect hot-reset devices to local buffer")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219010
    Reported-by: Žilvinas Žaltiena <zaltys@natrix.lt>
    Cc: Beld Zhang <beldzhang@gmail.com>
    Signed-off-by: Yi Liu <yi.l.liu@intel.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Link: https://lore.kernel.org/r/20240710004150.319105-1-yi.l.liu@intel.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vfs: don't mod negative dentry count when on shrinker list [+ + +]
Author: Brian Foster <bfoster@redhat.com>
Date:   Wed Jul 3 08:13:01 2024 -0400

    vfs: don't mod negative dentry count when on shrinker list
    
    [ Upstream commit aabfe57ebaa75841db47ea59091ec3c5a06d2f52 ]
    
    The nr_dentry_negative counter is intended to only account negative
    dentries that are present on the superblock LRU. Therefore, the LRU
    add, remove and isolate helpers modify the counter based on whether
    the dentry is negative, but the shrinker list related helpers do not
    modify the counter, and the paths that change a dentry between
    positive and negative only do so if DCACHE_LRU_LIST is set.
    
    The problem with this is that a dentry on a shrinker list still has
    DCACHE_LRU_LIST set to indicate ->d_lru is in use. The additional
    DCACHE_SHRINK_LIST flag denotes whether the dentry is on LRU or a
    shrink related list. Therefore if a relevant operation (i.e. unlink)
    occurs while a dentry is present on a shrinker list, and the
    associated codepath only checks for DCACHE_LRU_LIST, then it is
    technically possible to modify the negative dentry count for a
    dentry that is off the LRU. Since the shrinker list related helpers
    do not modify the negative dentry count (because non-LRU dentries
    should not be included in the count) when the dentry is ultimately
    removed from the shrinker list, this can cause the negative dentry
    count to become permanently inaccurate.
    
    This problem can be reproduced via a heavy file create/unlink vs.
    drop_caches workload. On an 80xcpu system, I start 80 tasks each
    running a 1k file create/delete loop, and one task spinning on
    drop_caches. After 10 minutes or so of runtime, the idle/clean cache
    negative dentry count increases from somewhere in the range of 5-10
    entries to several hundred (and increasingly grows beyond
    nr_dentry_unused).
    
    Tweak the logic in the paths that turn a dentry negative or positive
    to filter out the case where the dentry is present on a shrink
    related list. This allows the above workload to maintain an accurate
    negative dentry count.
    
    Fixes: af0c9af1b3f6 ("fs/dcache: Track & report number of negative dentries")
    Signed-off-by: Brian Foster <bfoster@redhat.com>
    Link: https://lore.kernel.org/r/20240703121301.247680-1-bfoster@redhat.com
    Acked-by: Ian Kent <ikent@redhat.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wireguard: allowedips: avoid unaligned 64-bit memory accesses [+ + +]
Author: Helge Deller <deller@kernel.org>
Date:   Thu Jul 4 17:45:15 2024 +0200

    wireguard: allowedips: avoid unaligned 64-bit memory accesses
    
    commit 948f991c62a4018fb81d85804eeab3029c6209f8 upstream.
    
    On the parisc platform, the kernel issues kernel warnings because
    swap_endian() tries to load a 128-bit IPv6 address from an unaligned
    memory location:
    
     Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)
     Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)
    
    Avoid such unaligned memory accesses by instead using the
    get_unaligned_be64() helper macro.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    [Jason: replace src[8] in original patch with src+8]
    Cc: stable@vger.kernel.org
    Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Link: https://patch.msgid.link/20240704154517.1572127-3-Jason@zx2c4.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wireguard: queueing: annotate intentional data race in cpu round robin [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Jul 4 17:45:16 2024 +0200

    wireguard: queueing: annotate intentional data race in cpu round robin
    
    commit 2fe3d6d2053c57f2eae5e85ca1656d185ebbe4e8 upstream.
    
    KCSAN reports a race in the CPU round robin function, which, as the
    comment points out, is intentional:
    
        BUG: KCSAN: data-race in wg_packet_send_staged_packets / wg_packet_send_staged_packets
    
        read to 0xffff88811254eb28 of 4 bytes by task 3160 on cpu 1:
         wg_cpumask_next_online drivers/net/wireguard/queueing.h:127 [inline]
         wg_queue_enqueue_per_device_and_peer drivers/net/wireguard/queueing.h:173 [inline]
         wg_packet_create_data drivers/net/wireguard/send.c:320 [inline]
         wg_packet_send_staged_packets+0x60e/0xac0 drivers/net/wireguard/send.c:388
         wg_packet_send_keepalive+0xe2/0x100 drivers/net/wireguard/send.c:239
         wg_receive_handshake_packet drivers/net/wireguard/receive.c:186 [inline]
         wg_packet_handshake_receive_worker+0x449/0x5f0 drivers/net/wireguard/receive.c:213
         process_one_work kernel/workqueue.c:3248 [inline]
         process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3329
         worker_thread+0x526/0x720 kernel/workqueue.c:3409
         kthread+0x1d1/0x210 kernel/kthread.c:389
         ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
         ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
    
        write to 0xffff88811254eb28 of 4 bytes by task 3158 on cpu 0:
         wg_cpumask_next_online drivers/net/wireguard/queueing.h:130 [inline]
         wg_queue_enqueue_per_device_and_peer drivers/net/wireguard/queueing.h:173 [inline]
         wg_packet_create_data drivers/net/wireguard/send.c:320 [inline]
         wg_packet_send_staged_packets+0x6e5/0xac0 drivers/net/wireguard/send.c:388
         wg_packet_send_keepalive+0xe2/0x100 drivers/net/wireguard/send.c:239
         wg_receive_handshake_packet drivers/net/wireguard/receive.c:186 [inline]
         wg_packet_handshake_receive_worker+0x449/0x5f0 drivers/net/wireguard/receive.c:213
         process_one_work kernel/workqueue.c:3248 [inline]
         process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3329
         worker_thread+0x526/0x720 kernel/workqueue.c:3409
         kthread+0x1d1/0x210 kernel/kthread.c:389
         ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
         ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
    
        value changed: 0xffffffff -> 0x00000000
    
    Mark this race as intentional by using READ/WRITE_ONCE().
    
    Cc: stable@vger.kernel.org
    Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Link: https://patch.msgid.link/20240704154517.1572127-4-Jason@zx2c4.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wireguard: selftests: use acpi=off instead of -no-acpi for recent QEMU [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Jul 4 17:45:14 2024 +0200

    wireguard: selftests: use acpi=off instead of -no-acpi for recent QEMU
    
    commit 2cb489eb8dfc291060516df313ff31f4f9f3d794 upstream.
    
    QEMU 9.0 removed -no-acpi, in favor of machine properties, so update the
    Makefile to use the correct QEMU invocation.
    
    Cc: stable@vger.kernel.org
    Fixes: b83fdcd9fb8a ("wireguard: selftests: use microvm on x86")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Link: https://patch.msgid.link/20240704154517.1572127-2-Jason@zx2c4.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wireguard: send: annotate intentional data race in checking empty queue [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Jul 4 17:45:17 2024 +0200

    wireguard: send: annotate intentional data race in checking empty queue
    
    commit 381a7d453fa2ac5f854a154d3c9b1bbb90c4f94f upstream.
    
    KCSAN reports a race in wg_packet_send_keepalive, which is intentional:
    
        BUG: KCSAN: data-race in wg_packet_send_keepalive / wg_packet_send_staged_packets
    
        write to 0xffff88814cd91280 of 8 bytes by task 3194 on cpu 0:
         __skb_queue_head_init include/linux/skbuff.h:2162 [inline]
         skb_queue_splice_init include/linux/skbuff.h:2248 [inline]
         wg_packet_send_staged_packets+0xe5/0xad0 drivers/net/wireguard/send.c:351
         wg_xmit+0x5b8/0x660 drivers/net/wireguard/device.c:218
         __netdev_start_xmit include/linux/netdevice.h:4940 [inline]
         netdev_start_xmit include/linux/netdevice.h:4954 [inline]
         xmit_one net/core/dev.c:3548 [inline]
         dev_hard_start_xmit+0x11b/0x3f0 net/core/dev.c:3564
         __dev_queue_xmit+0xeff/0x1d80 net/core/dev.c:4349
         dev_queue_xmit include/linux/netdevice.h:3134 [inline]
         neigh_connected_output+0x231/0x2a0 net/core/neighbour.c:1592
         neigh_output include/net/neighbour.h:542 [inline]
         ip6_finish_output2+0xa66/0xce0 net/ipv6/ip6_output.c:137
         ip6_finish_output+0x1a5/0x490 net/ipv6/ip6_output.c:222
         NF_HOOK_COND include/linux/netfilter.h:303 [inline]
         ip6_output+0xeb/0x220 net/ipv6/ip6_output.c:243
         dst_output include/net/dst.h:451 [inline]
         NF_HOOK include/linux/netfilter.h:314 [inline]
         ndisc_send_skb+0x4a2/0x670 net/ipv6/ndisc.c:509
         ndisc_send_rs+0x3ab/0x3e0 net/ipv6/ndisc.c:719
         addrconf_dad_completed+0x640/0x8e0 net/ipv6/addrconf.c:4295
         addrconf_dad_work+0x891/0xbc0
         process_one_work kernel/workqueue.c:2633 [inline]
         process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706
         worker_thread+0x525/0x730 kernel/workqueue.c:2787
         kthread+0x1d7/0x210 kernel/kthread.c:388
         ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
         ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
    
        read to 0xffff88814cd91280 of 8 bytes by task 3202 on cpu 1:
         skb_queue_empty include/linux/skbuff.h:1798 [inline]
         wg_packet_send_keepalive+0x20/0x100 drivers/net/wireguard/send.c:225
         wg_receive_handshake_packet drivers/net/wireguard/receive.c:186 [inline]
         wg_packet_handshake_receive_worker+0x445/0x5e0 drivers/net/wireguard/receive.c:213
         process_one_work kernel/workqueue.c:2633 [inline]
         process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706
         worker_thread+0x525/0x730 kernel/workqueue.c:2787
         kthread+0x1d7/0x210 kernel/kthread.c:388
         ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
         ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
    
        value changed: 0xffff888148fef200 -> 0xffff88814cd91280
    
    Mark this race as intentional by using the skb_queue_empty_lockless()
    function rather than skb_queue_empty(), which uses READ_ONCE()
    internally to annotate the race.
    
    Cc: stable@vger.kernel.org
    Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Link: https://patch.msgid.link/20240704154517.1572127-5-Jason@zx2c4.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/bhi: Avoid warning in #DB handler due to BHI mitigation [+ + +]
Author: Alexandre Chartre <alexandre.chartre@oracle.com>
Date:   Fri May 24 09:04:59 2024 +0200

    x86/bhi: Avoid warning in #DB handler due to BHI mitigation
    
    [ Upstream commit ac8b270b61d48fcc61f052097777e3b5e11591e0 ]
    
    When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set
    then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the
    clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler
    (exc_debug_kernel()) to issue a warning because single-step is used outside the
    entry_SYSENTER_compat() function.
    
    To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY
    after making sure the TF flag is cleared.
    
    The problem can be reproduced with the following sequence:
    
      $ cat sysenter_step.c
      int main()
      { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); }
    
      $ gcc -o sysenter_step sysenter_step.c
    
      $ ./sysenter_step
      Segmentation fault (core dumped)
    
    The program is expected to crash, and the #DB handler will issue a warning.
    
    Kernel log:
    
      WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160
      ...
      RIP: 0010:exc_debug_kernel+0xd2/0x160
      ...
      Call Trace:
      <#DB>
       ? show_regs+0x68/0x80
       ? __warn+0x8c/0x140
       ? exc_debug_kernel+0xd2/0x160
       ? report_bug+0x175/0x1a0
       ? handle_bug+0x44/0x90
       ? exc_invalid_op+0x1c/0x70
       ? asm_exc_invalid_op+0x1f/0x30
       ? exc_debug_kernel+0xd2/0x160
       exc_debug+0x43/0x50
       asm_exc_debug+0x1e/0x40
      RIP: 0010:clear_bhb_loop+0x0/0xb0
      ...
      </#DB>
      <TASK>
       ? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d
      </TASK>
    
      [ bp: Massage commit message. ]
    
    Fixes: 7390db8aea0d ("x86/bhi: Add support for clearing branch history at syscall entry")
    Reported-by: Suman Maity <suman.m.maity@oracle.com>
    Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Link: https://lore.kernel.org/r/20240524070459.3674025-1-alexandre.chartre@oracle.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xhci: always resume roothubs if xHC was reset during resume [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Jun 27 17:55:23 2024 +0300

    xhci: always resume roothubs if xHC was reset during resume
    
    commit 79989bd4ab86404743953fa382af0a22900050cf upstream.
    
    Usb device connect may not be detected after runtime resume if
    xHC is reset during resume.
    
    In runtime resume cases xhci_resume() will only resume roothubs if there
    are pending port events. If the xHC host is reset during runtime resume
    due to a Save/Restore Error (SRE) then these pending port events won't be
    detected as PORTSC change bits are not immediately set by host after reset.
    
    Unconditionally resume roothubs if xHC is reset during resume to ensure
    device connections are detected.
    
    Also return early with error code if starting xHC fails after reset.
    
    Issue was debugged and a similar solution suggested by Remi Pommarel.
    Using this instead as it simplifies future refactoring.
    
    Reported-by: Remi Pommarel <repk@triplefau.lt>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218987
    Suggested-by: Remi Pommarel <repk@triplefau.lt>
    Tested-by: Remi Pommarel <repk@triplefau.lt>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20240627145523.1453155-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>