Linux 6.2.9

 
ACPI: x86: Drop quirk for HP Elitebook [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Thu Feb 23 14:26:22 2023 -0600

    ACPI: x86: Drop quirk for HP Elitebook
    
    [ Upstream commit e32d546c483a2a0f607687f5b521c2a2f942ffbe ]
    
    There was a quirk in `acpi/x86/s2idle.c` for an HP Elitebook G9
    platforms to force AMD GUID codepath instead of Microsoft codepath.
    
    This was due to a bug with WCN6855 WLAN firmware interaction with
    the system.
    
    This bug is fixed by WCN6855 firmware:
    WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
    
    Remove the quirk as it's no longer necessary with this firmware.
    
    Link: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=c7a57ef688f7d99d8338a5d8edddc8836ff0e6de
    Tested-by: Anson Tsao <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: x86: utils: Add Cezanne to the list for forcing StorageD3Enable [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Tue Feb 28 16:11:28 2023 -0600

    ACPI: x86: utils: Add Cezanne to the list for forcing StorageD3Enable
    
    [ Upstream commit e2a56364485e7789e7b8f342637c7f3a219f7ede ]
    
    commit 018d6711c26e4 ("ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1
    for StorageD3Enable") introduced a quirk to allow a system with ambiguous
    use of _ADR 0 to force StorageD3Enable.
    
    It was reported that several more Dell systems suffered the same symptoms.
    As the list is continuing to grow but these are all Cezanne systems,
    instead add Cezanne to the CPU list to apply the StorageD3Enable property
    and remove the whole list.
    
    It was also reported that an HP system only has StorageD3Enable on the ACPI
    device for the first NVME disk, not the second.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217003
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216773
    Reported-by: David Alvarez Lombardi <[email protected]>
    Reported-by: [email protected]
    Reported-and-tested-by: Elvis Angelaccio <[email protected]>
    Tested-by: [email protected]
    Tested-by: [email protected]
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
act_mirred: use the backlog for nested calls to mirred ingress [+ + +]
Author: Davide Caratti <[email protected]>
Date:   Fri Jan 20 18:01:40 2023 +0100

    act_mirred: use the backlog for nested calls to mirred ingress
    
    [ Upstream commit ca22da2fbd693b54dc8e3b7b54ccc9f7e9ba3640 ]
    
    William reports kernel soft-lockups on some OVS topologies when TC mirred
    egress->ingress action is hit by local TCP traffic [1].
    The same can also be reproduced with SCTP (thanks Xin for verifying), when
    client and server reach themselves through mirred egress to ingress, and
    one of the two peers sends a "heartbeat" packet (from within a timer).
    
    Enqueueing to backlog proved to fix this soft lockup; however, as Cong
    noticed [2], we should preserve - when possible - the current mirred
    behavior that counts as "overlimits" any eventual packet drop subsequent to
    the mirred forwarding action [3]. A compromise solution might use the
    backlog only when tcf_mirred_act() has a nest level greater than one:
    change tcf_mirred_forward() accordingly.
    
    Also, add a kselftest that can reproduce the lockup and verifies TC mirred
    ability to account for further packet drops after TC mirred egress->ingress
    (when the nest level is 1).
    
     [1] https://lore.kernel.org/netdev/33dc43f587ec1388ba456b4915c75f02a8aae226.1663945716.git.dcaratti@redhat.com/
     [2] https://lore.kernel.org/netdev/Y0w%[email protected]/
     [3] such behavior is not guaranteed: for example, if RPS or skb RX
         timestamping is enabled on the mirred target device, the kernel
         can defer receiving the skb and return NET_RX_SUCCESS inside
         tcf_mirred_forward().
    
    Reported-by: William Zhao <[email protected]>
    CC: Xin Long <[email protected]>
    Signed-off-by: Davide Caratti <[email protected]>
    Reviewed-by: Marcelo Ricardo Leitner <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arm64: dts: freescale: imx8-ss-lsio: Fix flexspi clock order [+ + +]
Author: Alexander Stein <[email protected]>
Date:   Tue Jan 31 11:35:58 2023 +0100

    arm64: dts: freescale: imx8-ss-lsio: Fix flexspi clock order
    
    [ Upstream commit fd4334a06d452ce89a0bb831b03130c51331d927 ]
    
    The correct clock order is "fspi_en" and "fspi". As they are identical
    just reordering the names is sufficient.
    
    Fixes: 6276d66984e9 ("arm64: dts: imx8dxl: add flexspi0 support")
    Signed-off-by: Alexander Stein <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8dxl-evk: Disable hibernation mode of AR8031 for EQOS [+ + +]
Author: Wei Fang <[email protected]>
Date:   Fri Dec 16 09:14:34 2022 +0800

    arm64: dts: imx8dxl-evk: Disable hibernation mode of AR8031 for EQOS
    
    [ Upstream commit 0deefb5bd1382aae0aed7c8b266d5088a5308a26 ]
    
    The hibernation mode of AR8031 PHY defaults to be enabled after hardware
    reset. When the cable is unplugged, the PHY will enter hibernation mode
    after about 10 senconds and the PHY clocks will be stopped to save
    power. However, due to the design of EQOS, the mac needs the RX_CLK of
    PHY for software reset to complete. Otherwise the software reset of EQOS
    will be failed and do not work correctly. The only way is to disable
    hibernation mode of AR8031 PHY for EQOS, the "qca,disable-hibernation-mode"
    property is used for this purpose and has already been submitted to the
    upstream, for more details please refer to the below link:
    https://lore.kernel.org/netdev/[email protected]/
    
    This issue is easy to reproduce, just unplug the cable and "ifconfig eth0
    down", after about 10 senconds, then "ifconfig eth0 up", you will see
    failure log on the serial port. The log is shown as following:
    root@imx8dxlevk:~#
    [34.941970] imx-dwmac 5b050000.ethernet eth0: Link is Down
    root@imx8dxlevk:~# ifconfig eth0 down
    [35.437814] imx-dwmac 5b050000.ethernet eth0: FPE workqueue stop
    [35.507913] imx-dwmac 5b050000.ethernet eth0: PHY [stmmac-1:00] driver [Qualcomm Atheros AR8031/AR8033] (irq=POLL)
    [35.518613] imx-dwmac 5b050000.ethernet eth0: configuring for phy/rgmii-id link mode
    root@imx8dxlevk:~# ifconfig eth0 up
    [71.143044] imx-dwmac 5b050000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
    [71.215855] imx-dwmac 5b050000.ethernet eth0: PHY [stmmac-1:00] driver [Qualcomm Atheros AR8031/AR8033] (irq=POLL)
    [72.230417] imx-dwmac 5b050000.ethernet: Failed to reset the dma
    [72.236512] imx-dwmac 5b050000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
    [72.245258] imx-dwmac 5b050000.ethernet eth0: __stmmac_open: Hw setup failed
    SIOCSIFFLAGS: Connection timed out
    
    After applying this patch, the software reset of EQOS will be
    successful. And the log is shown as below.
    root@imx8dxlevk:~# ifconfig eth0 up
    [96.114344] imx-dwmac 5b050000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
    [96.171466] imx-dwmac 5b050000.ethernet eth0: PHY [stmmac-1:00] driver [Qualcomm Atheros AR8031/AR8033] (irq=POLL)
    [96.188883] imx-dwmac 5b050000.ethernet eth0: No Safety Features support found
    [96.196221] imx-dwmac 5b050000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
    [96.204846] imx-dwmac 5b050000.ethernet eth0: registered PTP clock
    [96.225558] imx-dwmac 5b050000.ethernet eth0: FPE workqueue start
    [96.236858] imx-dwmac 5b050000.ethernet eth0: configuring for phy/rgmii-id link mode
    [96.249358] 8021q: adding VLAN 0 to HW filter on device eth0
    
    Signed-off-by: Wei Fang <[email protected]>
    Reviewed-by: Clark Wang <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Stable-dep-of: feafeb53140a ("arm64: dts: imx8dxl-evk: Fix eqos phy reset gpio")
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8dxl-evk: Fix eqos phy reset gpio [+ + +]
Author: Andrew Halaney <[email protected]>
Date:   Tue Feb 14 11:15:05 2023 -0600

    arm64: dts: imx8dxl-evk: Fix eqos phy reset gpio
    
    [ Upstream commit feafeb53140af3cde3fba46b292b15b3a0c0635c ]
    
    The deprecated property is named snps,reset-gpio, but this devicetree
    used snps,reset-gpios instead which results in the reset not being used
    and the following make dtbs_check error:
    
        ./arch/arm64/boot/dts/freescale/imx8dxl-evk.dtb: ethernet@5b050000: 'snps,reset-gpio' is a dependency of 'snps,reset-delays-us'
            From schema: ./Documentation/devicetree/bindings/net/snps,dwmac.yaml
    
    Use the preferred method of defining the reset gpio in the phy node
    itself. Note that this drops the 10 us pre-delay, but prior this wasn't
    used at all and a pre-delay doesn't make much sense in this context so
    it should be fine.
    
    Fixes: 8dd495d12374 ("arm64: dts: freescale: add support for i.MX8DXL EVK board")
    Signed-off-by: Andrew Halaney <[email protected]>
    Acked-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx8mm-nitrogen-r2: fix WM8960 clock name [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Feb 17 16:06:26 2023 +0100

    arm64: dts: imx8mm-nitrogen-r2: fix WM8960 clock name
    
    commit 32f86da7c86b27ebed31c24453a0713f612e43fb upstream.
    
    The WM8960 Linux driver expects the clock to be named "mclk".  Otherwise
    the clock will be ignored and not prepared/enabled by the driver.
    
    Fixes: 40ba2eda0a7b ("arm64: dts: imx8mm-nitrogen-r2: add audio")
    Cc: <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: imx8mn: specify #sound-dai-cells for SAI nodes [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Tue Feb 28 22:52:44 2023 +0100

    arm64: dts: imx8mn: specify #sound-dai-cells for SAI nodes
    
    [ Upstream commit 62fb54148cd6eb456ff031be8fb447c98cf0bd9b ]
    
    Add #sound-dai-cells properties to SAI nodes.
    
    Reviewed-by: Adam Ford <[email protected]>
    Reviewed-by: Fabio Estevam <[email protected]>
    Fixes: 9e9860069725 ("arm64: dts: imx8mn: Add SAI nodes")
    Signed-off-by: Marek Vasut <[email protected]>
    Reviewed-by: Marco Felsch <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: imx93: add missing #address-cells and #size-cells to i2c nodes [+ + +]
Author: Alexander Stein <[email protected]>
Date:   Wed Mar 8 11:17:20 2023 +0100

    arm64: dts: imx93: add missing #address-cells and #size-cells to i2c nodes
    
    [ Upstream commit b3cdf730486b048ca0bf23bef050550d9fd40422 ]
    
    Add them to the SoC .dtsi, so that not every board has to specify them.
    
    Fixes: 1225396fefea ("arm64: dts: imx93: add lpi2c nodes")
    Signed-off-by: Alexander Stein <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sc7280: Mark PCIe controller as cache coherent [+ + +]
Author: Krishna chaitanya chundru <[email protected]>
Date:   Tue Feb 28 17:19:12 2023 +0530

    arm64: dts: qcom: sc7280: Mark PCIe controller as cache coherent
    
    commit 8a63441e83724fee1ef3fd37b237d40d90780766 upstream.
    
    If the controller is not marked as cache coherent, then kernel will
    try to ensure coherency during dma-ops and that may cause data corruption.
    So, mark the PCIe node as dma-coherent as the devices on PCIe bus are
    cache coherent.
    
    Cc: [email protected]
    Fixes: 92e0ee9f83b3 ("arm64: dts: qcom: sc7280: Add PCIe and PHY related node")
    Signed-off-by: Krishna chaitanya chundru <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: qcom: sc8280xp-x13s: mark s11b regulator as always-on [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Wed Mar 22 12:33:13 2023 +0100

    arm64: dts: qcom: sc8280xp-x13s: mark s11b regulator as always-on
    
    commit b8838e653034425cd26983c7d96535e2742a6212 upstream.
    
    The s11b supply is used by the wlan module (as well as some of the
    pmics) which are not yet fully described in the devicetree.
    
    Mark the regulator as always-on for now.
    
    Fixes: 123b30a75623 ("arm64: dts: qcom: sc8280xp-x13s: enable WiFi controller")
    Cc: [email protected]      # 6.2
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: qcom: sc8280xp: Add label property to vadc channel nodes [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Sat Feb 11 10:54:15 2023 +0530

    arm64: dts: qcom: sc8280xp: Add label property to vadc channel nodes
    
    [ Upstream commit 8013295662f55696e5953ef14c31ba03721adf8f ]
    
    For uniquely identifying the vadc channels, label property has to be used.
    The initial commit adding vadc support assumed that the driver will use the
    unit address along with the node name to identify the channels. But this
    assumption is now broken by,
    commit 701c875aded8 ("iio: adc: qcom-spmi-adc5: Fix the channel name") that
    stripped unit address from channel names. This results in probe failure of
    the vadc driver:
    
    [    8.380370] iio iio:device0: tried to double register : in_temp_pmic-die-temp_input
    [    8.380383] qcom-spmi-adc5 c440000.spmi:pmic@0:adc@3100: Failed to register sysfs interfaces
    [    8.380386] qcom-spmi-adc5: probe of c440000.spmi:pmic@0:adc@3100 failed with error -16
    
    Hence, let's get rid of the assumption about drivers and rely on label
    property to uniquely identify the channels.
    
    The labels are derived from the schematics for each PMIC. For internal adc
    channels such as die and xo, the PMIC names are used as a prefix.
    
    Fixes: 7c0151347401 ("arm64: dts: qcom: sc8280xp-x13s: Add PM8280_{1/2} ADC_TM5 channels")
    Fixes: 9d41cd17394a ("arm64: dts: qcom: sc8280xp-x13s: Add PMR735A VADC channel")
    Fixes: 3375151a7185 ("arm64: dts: qcom: sc8280xp-x13s: Add PM8280_{1/2} VADC channels")
    Fixes: 9a6b3042c533 ("arm64: dts: qcom: sc8280xp-x13s: Add PMK8280 VADC channels")
    Reported-by: Steev Klimaszewski <[email protected]>
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm6375: Add missing power-domain-named to CDSP [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Mon Jan 9 14:56:47 2023 +0100

    arm64: dts: qcom: sm6375: Add missing power-domain-named to CDSP
    
    [ Upstream commit 11d5e41f5e129e39bddedc7244a0946a802d2e8e ]
    
    This was omitted when first introducing the node. Fix it.
    
    Fixes: fe6fd26aeddf ("arm64: dts: qcom: sm6375: Add ADSP&CDSP")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm8150: Fix the iommu mask used for PCIe controllers [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Fri Feb 24 13:30:45 2023 +0530

    arm64: dts: qcom: sm8150: Fix the iommu mask used for PCIe controllers
    
    commit 672a58fc7c477e59981653a11241566870fff852 upstream.
    
    The iommu mask should be 0x3f as per Qualcomm internal documentation.
    Without the correct mask, the PCIe transactions from the endpoint will
    result in SMMU faults. Hence, fix it!
    
    Cc: [email protected] # 5.19
    Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes")
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Bhupesh Sharma <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: qcom: sm8450: correct WSA2 assigned clocks [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Wed Mar 8 13:31:29 2023 +0100

    arm64: dts: qcom: sm8450: correct WSA2 assigned clocks
    
    [ Upstream commit 6df6fab9320bc9ebdf50136a01e7bf0ee5984c62 ]
    
    The WSA2 assigned-clocks were copied from WSA, but the WSA2 uses its
    own.
    
    Fixes: 14341e76dbc7 ("arm64: dts: qcom: sm8450: add Soundwire and LPASS")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sm8450: Mark UFS controller as cache coherent [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Tue Mar 7 21:02:01 2023 +0530

    arm64: dts: qcom: sm8450: Mark UFS controller as cache coherent
    
    [ Upstream commit 8ba961d4339c5db0e69ff6627606fe1f34c838e5 ]
    
    The UFS controller on SM8450 supports cache coherency, hence add the
    "dma-coherent" property to mark it as such.
    
    Fixes: 07fa917a335e ("arm64: dts: qcom: sm8450: add ufs nodes")
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

arm64: efi: Set NX compat flag in PE/COFF header [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Fri Mar 10 13:30:05 2023 +0100

    arm64: efi: Set NX compat flag in PE/COFF header
    
    commit 3c66bb1918c262dd52fb4221a8d372619c5da70a upstream.
    
    The PE/COFF header has a NX compat flag which informs the firmware that
    the application does not rely on memory regions being mapped with both
    executable and writable permissions at the same time.
    
    This is typically used by the firmware to decide whether it can set the
    NX attribute on all allocations it returns, but going forward, it may be
    used to enforce a policy that only permits applications with the NX flag
    set to be loaded to begin wiht in some configurations, e.g., when Secure
    Boot is in effect.
    
    Even though the arm64 version of the EFI stub may relocate the kernel
    before executing it, it always did so after disabling the MMU, and so we
    were always in line with what the NX compat flag conveys, we just never
    bothered to set it.
    
    So let's set the flag now.
    
    Cc: <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: efi: Use SMBIOS processor version to key off Ampere quirk [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Tue Feb 28 17:00:49 2023 +0100

    arm64: efi: Use SMBIOS processor version to key off Ampere quirk
    
    [ Upstream commit eb684408f3ea4856639675d6465f0024e498e4b1 ]
    
    Instead of using the SMBIOS type 1 record 'family' field, which is often
    modified by OEMs, use the type 4 'processor ID' and 'processor version'
    fields, which are set to a small set of probe-able values on all known
    Ampere EFI systems in the field.
    
    Fixes: 550b33cfd4452968 ("arm64: efi: Force the use of ...")
    Tested-by: Andrea Righi <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: dts: imx6sl: tolino-shine2hd: fix usbotg1 pinctrl [+ + +]
Author: Peng Fan <[email protected]>
Date:   Sun Feb 26 21:12:14 2023 +0800

    ARM: dts: imx6sl: tolino-shine2hd: fix usbotg1 pinctrl
    
    [ Upstream commit 1cd489e1ada1cffa56bd06fd4609f5a60a985d43 ]
    
    usb@2184000: 'pinctrl-0' is a dependency of 'pinctrl-names'
    
    Signed-off-by: Peng Fan <[email protected]>
    Fixes: 9c7016f1ca6d ("ARM: dts: imx: add devicetree for Tolino Shine 2 HD")
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: imx6sll: e60k02: fix usbotg1 pinctrl [+ + +]
Author: Peng Fan <[email protected]>
Date:   Sun Feb 26 21:12:13 2023 +0800

    ARM: dts: imx6sll: e60k02: fix usbotg1 pinctrl
    
    [ Upstream commit 957c04e9784c7c757e8cc293d7fb2a60cdf461b6 ]
    
    usb@2184000: 'pinctrl-0' is a dependency of 'pinctrl-names'
    
    Signed-off-by: Peng Fan <[email protected]>
    Fixes: c100ea86e6ab ("ARM: dts: add Netronix E60K02 board common file")
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: imx6sll: e70k02: fix usbotg1 pinctrl [+ + +]
Author: Peng Fan <[email protected]>
Date:   Sun Feb 26 21:12:12 2023 +0800

    ARM: dts: imx6sll: e70k02: fix usbotg1 pinctrl
    
    [ Upstream commit 3d37f7685d525e58674c23d607020e66d501dcd1 ]
    
    usb@2184000: 'pinctrl-0' is a dependency of 'pinctrl-names'
    
    Signed-off-by: Peng Fan <[email protected]>
    Fixes: 3bb3fd856505 ("ARM: dts: add Netronix E70K02 board common file")
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: amd: yc: Add DMI entries to support HP OMEN 16-n0xxx (8A43) [+ + +]
Author: Duc Anh Le <[email protected]>
Date:   Tue Feb 28 00:49:21 2023 +0100

    ASoC: amd: yc: Add DMI entries to support HP OMEN 16-n0xxx (8A43)
    
    [ Upstream commit d52279d5c9204a041e9ba02a66a353573b2f96e4 ]
    
    This model requires an additional detection quirk to enable the internal microphone.
    
    Signed-off-by: Duc Anh Le <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: amd: yp: Add OMEN by HP Gaming Laptop 16z-n000 to quirks [+ + +]
Author: Joseph Hunkeler <[email protected]>
Date:   Thu Feb 16 10:50:07 2023 -0500

    ASoC: amd: yp: Add OMEN by HP Gaming Laptop 16z-n000 to quirks
    
    [ Upstream commit 22ce6843abec19270bf69b176d7ee0a4ef781da5 ]
    
    Enables display microphone on the HP OMEN 16z-n000 (8A42) laptop
    
    Signed-off-by: Joseph Hunkeler <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: sof_rt5682: Add quirk for Rex board with mx98360a amplifier [+ + +]
Author: Dharageswari.R <[email protected]>
Date:   Mon Feb 20 10:06:52 2023 +0200

    ASoC: Intel: sof_rt5682: Add quirk for Rex board with mx98360a amplifier
    
    [ Upstream commit 7e43b75d6a062197b3bf39ddd1b10ce2e2d2a9b0 ]
    
    Add mtl_mx98360a_rt5682 driver data for Chrome Rex board support.
    
    Signed-off-by: Dharageswari.R <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Ranjani Sridharan <[email protected]>
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
atm: idt77252: fix kmemleak when rmmod idt77252 [+ + +]
Author: Li Zetao <[email protected]>
Date:   Mon Mar 20 14:33:18 2023 +0000

    atm: idt77252: fix kmemleak when rmmod idt77252
    
    [ Upstream commit 4fe3c88552a3fbe1944426a4506a18cdeb457b5a ]
    
    There are memory leaks reported by kmemleak:
    
      unreferenced object 0xffff888106500800 (size 128):
        comm "modprobe", pid 1017, jiffies 4297787785 (age 67.152s)
        hex dump (first 32 bytes):
          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 00 00  ................
        backtrace:
          [<00000000970ce626>] __kmem_cache_alloc_node+0x20c/0x380
          [<00000000fb5f78d9>] kmalloc_trace+0x2f/0xb0
          [<000000000e947e2a>] idt77252_init_one+0x2847/0x3c90 [idt77252]
          [<000000006efb048e>] local_pci_probe+0xeb/0x1a0
        ...
    
      unreferenced object 0xffff888106500b00 (size 128):
        comm "modprobe", pid 1017, jiffies 4297787785 (age 67.152s)
        hex dump (first 32 bytes):
          00 20 3d 01 80 88 ff ff 00 20 3d 01 80 88 ff ff  . =...... =.....
          f0 23 3d 01 80 88 ff ff 00 20 3d 01 00 00 00 00  .#=...... =.....
        backtrace:
          [<00000000970ce626>] __kmem_cache_alloc_node+0x20c/0x380
          [<00000000fb5f78d9>] kmalloc_trace+0x2f/0xb0
          [<00000000f451c5be>] alloc_scq.constprop.0+0x4a/0x400 [idt77252]
          [<00000000e6313849>] idt77252_init_one+0x28cf/0x3c90 [idt77252]
    
    The root cause is traced to the vc_maps which alloced in open_card_oam()
    are not freed in close_card_oam(). The vc_maps are used to record
    open connections, so when close a vc_map in close_card_oam(), the memory
    should be freed. Moreover, the ubr0 is not closed when close a idt77252
    device, leading to the memory leak of vc_map and scq_info.
    
    Fix them by adding kfree in close_card_oam() and implementing new
    close_card_ubr0() to close ubr0.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Li Zetao <[email protected]>
    Reviewed-by: Francois Romieu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
block/io_uring: pass in issue_flags for uring_cmd task_work handling [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Mon Mar 20 20:01:25 2023 -0600

    block/io_uring: pass in issue_flags for uring_cmd task_work handling
    
    commit 9d2789ac9d60c049d26ef6d3005d9c94c5a559e9 upstream.
    
    io_uring_cmd_done() currently assumes that the uring_lock is held
    when invoked, and while it generally is, this is not guaranteed.
    Pass in the issue_flags associated with it, so that we have
    IO_URING_F_UNLOCKED available to be able to lock the CQ ring
    appropriately when completing events.
    
    Cc: [email protected]
    Fixes: ee692a21e9bf ("fs,io_uring: add infrastructure for uring-cmd")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Bluetooth: btqcomsmd: Fix command timeout after setting BD address [+ + +]
Author: Stephan Gerhold <[email protected]>
Date:   Wed Mar 8 14:31:55 2023 +0100

    Bluetooth: btqcomsmd: Fix command timeout after setting BD address
    
    [ Upstream commit 5d44ab9e204200a78ad55cdf185aa2bb109b5950 ]
    
    On most devices using the btqcomsmd driver (e.g. the DragonBoard 410c
    and other devices based on the Qualcomm MSM8916/MSM8909/... SoCs)
    the Bluetooth firmware seems to become unresponsive for a while after
    setting the BD address. On recent kernel versions (at least 5.17+)
    this often causes timeouts for subsequent commands, e.g. the HCI reset
    sent by the Bluetooth core during initialization:
    
        Bluetooth: hci0: Opcode 0x c03 failed: -110
    
    Unfortunately this behavior does not seem to be documented anywhere.
    Experimentation suggests that the minimum necessary delay to avoid
    the problem is ~150us. However, to be sure add a sleep for > 1ms
    in case it is a bit longer on other firmware versions.
    
    Older kernel versions are likely also affected, although perhaps with
    slightly different errors or less probability. Side effects can easily
    hide the issue in most cases, e.g. unrelated incoming interrupts that
    cause the necessary delay.
    
    Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
    Signed-off-by: Stephan Gerhold <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Thu Mar 9 16:07:39 2023 +0800

    Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work
    
    [ Upstream commit 1e9ac114c4428fdb7ff4635b45d4f46017e8916f ]
    
    In btsdio_probe, &data->work was bound with btsdio_work.In
    btsdio_send_frame, it was started by schedule_work.
    
    If we call btsdio_remove with an unfinished job, there may
    be a race condition and cause UAF bug on hdev.
    
    Fixes: ddbaf13e3609 ("[Bluetooth] Add generic driver for Bluetooth SDIO devices")
    Signed-off-by: Zheng Wang <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: btusb: Remove detection of ISO packets over bulk [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Fri Feb 24 15:54:31 2023 -0800

    Bluetooth: btusb: Remove detection of ISO packets over bulk
    
    [ Upstream commit efe375b716c1c1c9b52a816f5b933a95421020a2 ]
    
    This removes the code introduced by
    14202eff214e1e941fefa0366d4c3bc4b1a0d500 as hci_recv_frame is now able
    to detect ACL packets that are in fact ISO packets.
    
    Fixes: 14202eff214e ("Bluetooth: btusb: Detect if an ACL packet is in fact an ISO packet")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: Fix race condition in hci_cmd_sync_clear [+ + +]
Author: Min Li <[email protected]>
Date:   Sat Mar 4 21:50:35 2023 +0800

    Bluetooth: Fix race condition in hci_cmd_sync_clear
    
    commit 1c66bee492a5fe00ae3fe890bb693bfc99f994c6 upstream.
    
    There is a potential race condition in hci_cmd_sync_work and
    hci_cmd_sync_clear, and could lead to use-after-free. For instance,
    hci_cmd_sync_work is added to the 'req_workqueue' after cancel_work_sync
    The entry of 'cmd_sync_work_list' may be freed in hci_cmd_sync_clear, and
    causing kernel panic when it is used in 'hci_cmd_sync_work'.
    
    Here's the call trace:
    
    dump_stack_lvl+0x49/0x63
    print_report.cold+0x5e/0x5d3
    ? hci_cmd_sync_work+0x282/0x320
    kasan_report+0xaa/0x120
    ? hci_cmd_sync_work+0x282/0x320
    __asan_report_load8_noabort+0x14/0x20
    hci_cmd_sync_work+0x282/0x320
    process_one_work+0x77b/0x11c0
    ? _raw_spin_lock_irq+0x8e/0xf0
    worker_thread+0x544/0x1180
    ? poll_idle+0x1e0/0x1e0
    kthread+0x285/0x320
    ? process_one_work+0x11c0/0x11c0
    ? kthread_complete_and_exit+0x30/0x30
    ret_from_fork+0x22/0x30
    </TASK>
    
    Allocated by task 266:
    kasan_save_stack+0x26/0x50
    __kasan_kmalloc+0xae/0xe0
    kmem_cache_alloc_trace+0x191/0x350
    hci_cmd_sync_queue+0x97/0x2b0
    hci_update_passive_scan+0x176/0x1d0
    le_conn_complete_evt+0x1b5/0x1a00
    hci_le_conn_complete_evt+0x234/0x340
    hci_le_meta_evt+0x231/0x4e0
    hci_event_packet+0x4c5/0xf00
    hci_rx_work+0x37d/0x880
    process_one_work+0x77b/0x11c0
    worker_thread+0x544/0x1180
    kthread+0x285/0x320
    ret_from_fork+0x22/0x30
    
    Freed by task 269:
    kasan_save_stack+0x26/0x50
    kasan_set_track+0x25/0x40
    kasan_set_free_info+0x24/0x40
    ____kasan_slab_free+0x176/0x1c0
    __kasan_slab_free+0x12/0x20
    slab_free_freelist_hook+0x95/0x1a0
    kfree+0xba/0x2f0
    hci_cmd_sync_clear+0x14c/0x210
    hci_unregister_dev+0xff/0x440
    vhci_release+0x7b/0xf0
    __fput+0x1f3/0x970
    ____fput+0xe/0x20
    task_work_run+0xd4/0x160
    do_exit+0x8b0/0x22a0
    do_group_exit+0xba/0x2a0
    get_signal+0x1e4a/0x25b0
    arch_do_signal_or_restart+0x93/0x1f80
    exit_to_user_mode_prepare+0xf5/0x1a0
    syscall_exit_to_user_mode+0x26/0x50
    ret_from_fork+0x15/0x30
    
    Fixes: 6a98e3836fa2 ("Bluetooth: Add helper for serialized HCI command execution")
    Cc: [email protected]
    Signed-off-by: Min Li <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Bluetooth: HCI: Fix global-out-of-bounds [+ + +]
Author: Sungwoo Kim <[email protected]>
Date:   Mon Mar 20 21:50:18 2023 -0400

    Bluetooth: HCI: Fix global-out-of-bounds
    
    [ Upstream commit bce56405201111807cc8e4f47c6de3e10b17c1ac ]
    
    To loop a variable-length array, hci_init_stage_sync(stage) considers
    that stage[i] is valid as long as stage[i-1].func is valid.
    Thus, the last element of stage[].func should be intentionally invalid
    as hci_init0[], le_init2[], and others did.
    However, amp_init1[] and amp_init2[] have no invalid element, letting
    hci_init_stage_sync() keep accessing amp_init1[] over its valid range.
    This patch fixes this by adding {} in the last of amp_init1[] and
    amp_init2[].
    
    ==================================================================
    BUG: KASAN: global-out-of-bounds in hci_dev_open_sync (
    /v6.2-bzimage/net/bluetooth/hci_sync.c:3154
    /v6.2-bzimage/net/bluetooth/hci_sync.c:3343
    /v6.2-bzimage/net/bluetooth/hci_sync.c:4418
    /v6.2-bzimage/net/bluetooth/hci_sync.c:4609
    /v6.2-bzimage/net/bluetooth/hci_sync.c:4689)
    Read of size 8 at addr ffffffffaed1ab70 by task kworker/u5:0/1032
    CPU: 0 PID: 1032 Comm: kworker/u5:0 Not tainted 6.2.0 #3
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04
    Workqueue: hci1 hci_power_on
    Call Trace:
     <TASK>
    dump_stack_lvl (/v6.2-bzimage/lib/dump_stack.c:107 (discriminator 1))
    print_report (/v6.2-bzimage/mm/kasan/report.c:307
      /v6.2-bzimage/mm/kasan/report.c:417)
    ? hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154
      /v6.2-bzimage/net/bluetooth/hci_sync.c:3343
      /v6.2-bzimage/net/bluetooth/hci_sync.c:4418
      /v6.2-bzimage/net/bluetooth/hci_sync.c:4609
      /v6.2-bzimage/net/bluetooth/hci_sync.c:4689)
    kasan_report (/v6.2-bzimage/mm/kasan/report.c:184
      /v6.2-bzimage/mm/kasan/report.c:519)
    ? hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154
      /v6.2-bzimage/net/bluetooth/hci_sync.c:3343
      /v6.2-bzimage/net/bluetooth/hci_sync.c:4418
      /v6.2-bzimage/net/bluetooth/hci_sync.c:4609
      /v6.2-bzimage/net/bluetooth/hci_sync.c:4689)
    hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154
      /v6.2-bzimage/net/bluetooth/hci_sync.c:3343
      /v6.2-bzimage/net/bluetooth/hci_sync.c:4418
      /v6.2-bzimage/net/bluetooth/hci_sync.c:4609
      /v6.2-bzimage/net/bluetooth/hci_sync.c:4689)
    ? __pfx_hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:4635)
    ? mutex_lock (/v6.2-bzimage/./arch/x86/include/asm/atomic64_64.h:190
      /v6.2-bzimage/./include/linux/atomic/atomic-long.h:443
      /v6.2-bzimage/./include/linux/atomic/atomic-instrumented.h:1781
      /v6.2-bzimage/kernel/locking/mutex.c:171
      /v6.2-bzimage/kernel/locking/mutex.c:285)
    ? __pfx_mutex_lock (/v6.2-bzimage/kernel/locking/mutex.c:282)
    hci_power_on (/v6.2-bzimage/net/bluetooth/hci_core.c:485
      /v6.2-bzimage/net/bluetooth/hci_core.c:984)
    ? __pfx_hci_power_on (/v6.2-bzimage/net/bluetooth/hci_core.c:969)
    ? read_word_at_a_time (/v6.2-bzimage/./include/asm-generic/rwonce.h:85)
    ? strscpy (/v6.2-bzimage/./arch/x86/include/asm/word-at-a-time.h:62
      /v6.2-bzimage/lib/string.c:161)
    process_one_work (/v6.2-bzimage/kernel/workqueue.c:2294)
    worker_thread (/v6.2-bzimage/./include/linux/list.h:292
      /v6.2-bzimage/kernel/workqueue.c:2437)
    ? __pfx_worker_thread (/v6.2-bzimage/kernel/workqueue.c:2379)
    kthread (/v6.2-bzimage/kernel/kthread.c:376)
    ? __pfx_kthread (/v6.2-bzimage/kernel/kthread.c:331)
    ret_from_fork (/v6.2-bzimage/arch/x86/entry/entry_64.S:314)
     </TASK>
    The buggy address belongs to the variable:
    amp_init1+0x30/0x60
    The buggy address belongs to the physical page:
    page:000000003a157ec6 refcount:1 mapcount:0 mapping:0000000000000000 ia
    flags: 0x200000000001000(reserved|node=0|zone=2)
    raw: 0200000000001000 ffffea0005054688 ffffea0005054688 000000000000000
    raw: 0000000000000000 0000000000000000 00000001ffffffff 000000000000000
    page dumped because: kasan: bad access detected
    Memory state around the buggy address:
     ffffffffaed1aa00: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 00
     ffffffffaed1aa80: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00
    >ffffffffaed1ab00: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 f9 f9
                                                                 ^
     ffffffffaed1ab80: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 f9
     ffffffffaed1ac00: f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 00 00 02 f9
    
    This bug is found by FuzzBT, a modified version of Syzkaller.
    Other contributors for this bug are Ruoyu Wu and Peng Hui.
    
    Fixes: d0b137062b2d ("Bluetooth: hci_sync: Rework init stages")
    Signed-off-by: Sungwoo Kim <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_core: Detect if an ACL packet is in fact an ISO packet [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Fri Feb 24 15:43:31 2023 -0800

    Bluetooth: hci_core: Detect if an ACL packet is in fact an ISO packet
    
    [ Upstream commit 876e78104f23ce9267822757a63562a609b126c3 ]
    
    Because some transports don't have a dedicated type for ISO packets
    (see 14202eff214e1e941fefa0366d4c3bc4b1a0d500) they may use ACL type
    when in fact they are ISO packets.
    
    In the past this was left for the driver to detect such thing but it
    creates a problem when using the likes of btproxy when used by a VM as
    the host would not be aware of the connection the guest is doing it
    won't be able to detect such behavior, so this make bt_recv_frame
    detect when it happens as it is the common interface to all drivers
    including guest VMs.
    
    Fixes: 14202eff214e ("Bluetooth: btusb: Detect if an ACL packet is in fact an ISO packet")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_sync: Resume adv with no RPA when active scan [+ + +]
Author: Zhengping Jiang <[email protected]>
Date:   Tue Feb 21 16:17:56 2023 -0800

    Bluetooth: hci_sync: Resume adv with no RPA when active scan
    
    [ Upstream commit 3c44a431d62bf4a20d7b901f98266ae3f4676d48 ]
    
    The address resolution should be disabled during the active scan,
    so all the advertisements can reach the host. The advertising
    has to be paused before disabling the address resolution,
    because the advertising will prevent any changes to the resolving
    list and the address resolution status. Skipping this will cause
    the hci error and the discovery failure.
    
    According to the bluetooth specification:
    "7.8.44 LE Set Address Resolution Enable command
    
    This command shall not be used when:
    - Advertising (other than periodic advertising) is enabled,
    - Scanning is enabled, or
    - an HCI_LE_Create_Connection, HCI_LE_Extended_Create_Connection, or
      HCI_LE_Periodic_Advertising_Create_Sync command is outstanding."
    
    If the host is using RPA, the controller needs to generate RPA for
    the advertising, so the advertising must remain paused during the
    active scan.
    
    If the host is not using RPA, the advertising can be resumed after
    disabling the address resolution.
    
    Fixes: 9afc675edeeb ("Bluetooth: hci_sync: allow advertise when scan without RPA")
    Signed-off-by: Zhengping Jiang <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: ISO: fix timestamped HCI ISO data packet parsing [+ + +]
Author: Pauli Virtanen <[email protected]>
Date:   Mon Feb 20 19:38:24 2023 +0000

    Bluetooth: ISO: fix timestamped HCI ISO data packet parsing
    
    [ Upstream commit 2f10e40a948e8a2abe7f983df3959a333ca8955f ]
    
    Use correct HCI ISO data packet header struct when the packet has
    timestamp. The timestamp, when present, goes before the other fields
    (Core v5.3 4E 5.4.5), so the structs are not compatible.
    
    Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type")
    Signed-off-by: Pauli Virtanen <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: L2CAP: Fix responding with wrong PDU type [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Mar 8 14:20:34 2023 -0800

    Bluetooth: L2CAP: Fix responding with wrong PDU type
    
    [ Upstream commit 9aa9d9473f1550d1936c31259720b3f1f4690576 ]
    
    L2CAP_ECRED_CONN_REQ shall be responded with L2CAP_ECRED_CONN_RSP not
    L2CAP_LE_CONN_RSP:
    
    L2CAP LE EATT Server - Reject - run
      Listening for connections
      New client connection with handle 0x002a
      Sending L2CAP Request from client
      Client received response code 0x15
      Unexpected L2CAP response code (expected 0x18)
    L2CAP LE EATT Server - Reject - test failed
    
    > ACL Data RX: Handle 42 flags 0x02 dlen 26
          LE L2CAP: Enhanced Credit Connection Request (0x17) ident 1 len 18
            PSM: 39 (0x0027)
            MTU: 64
            MPS: 64
            Credits: 5
            Source CID: 65
            Source CID: 66
            Source CID: 67
            Source CID: 68
            Source CID: 69
    < ACL Data TX: Handle 42 flags 0x00 dlen 16
          LE L2CAP: LE Connection Response (0x15) ident 1 len 8
            invalid size
            00 00 00 00 00 00 06 00
    
    L2CAP LE EATT Server - Reject - run
      Listening for connections
      New client connection with handle 0x002a
      Sending L2CAP Request from client
      Client received response code 0x18
    L2CAP LE EATT Server - Reject - test passed
    
    Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: mgmt: Fix MGMT add advmon with RSSI command [+ + +]
Author: Howard Chung <[email protected]>
Date:   Thu Mar 16 18:11:38 2023 +0800

    Bluetooth: mgmt: Fix MGMT add advmon with RSSI command
    
    [ Upstream commit 1a0291f81529e8044fb29845a0196ba47af894ce ]
    
    The MGMT command: MGMT_OP_ADD_ADV_PATTERNS_MONITOR_RSSI uses variable
    length argument. This causes host not able to register advmon with rssi.
    
    This patch has been locally tested by adding monitor with rssi via
    btmgmt on a kernel 6.1 machine.
    
    Reviewed-by: Archie Pusaka <[email protected]>
    Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh")
    Signed-off-by: Howard Chung <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: Remove "Power-on" check from Mesh feature [+ + +]
Author: Brian Gix <[email protected]>
Date:   Mon Mar 6 14:32:21 2023 -0800

    Bluetooth: Remove "Power-on" check from Mesh feature
    
    [ Upstream commit 52dd5e964a55c98c1b0bcf5fc737a5ddd00e7d4d ]
    
    The Bluetooth mesh experimental feature enable was requiring the
    controller to be powered off in order for the Enable to work. Mesh is
    supposed to be enablable regardless of the controller state, and created
    an unintended requirement that the mesh daemon be started before the
    classic bluetoothd daemon.
    
    Fixes: af6bcc1921ff ("Bluetooth: Add experimental wrapper for MGMT based mesh")
    Signed-off-by: Brian Gix <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bootconfig: Fix testcase to increase max node [+ + +]
Author: Masami Hiramatsu (Google) <[email protected]>
Date:   Wed Mar 15 22:54:08 2023 +0900

    bootconfig: Fix testcase to increase max node
    
    [ Upstream commit b69245126a48e50882021180fa5d264dc7149ccc ]
    
    Since commit 6c40624930c5 ("bootconfig: Increase max nodes of bootconfig
    from 1024 to 8192 for DCC support") increased the max number of bootconfig
    node to 8192, the bootconfig testcase of the max number of nodes fails.
    To fix this issue, we can not simply increase the number in the test script
    because the test bootconfig file becomes too big (>32KB). To fix that, we
    can use a combination of three alphabets (26^3 = 17576). But with that,
    we can not express the 8193 (just one exceed from the limitation) because
    it also exceeds the max size of bootconfig. So, the first 26 nodes will just
    use one alphabet.
    
    With this fix, test-bootconfig.sh passes all tests.
    
    Link: https://lore.kernel.org/all/167888844790.791176.670805252426835131.stgit@devnote2/
    
    Reported-by: Heinz Wiesinger <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Fixes: 6c40624930c5 ("bootconfig: Increase max nodes of bootconfig from 1024 to 8192 for DCC support")
    Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
    Reviewed-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: Adjust insufficient default bpf_jit_limit [+ + +]
Author: Daniel Borkmann <[email protected]>
Date:   Mon Mar 20 15:37:25 2023 +0100

    bpf: Adjust insufficient default bpf_jit_limit
    
    [ Upstream commit 10ec8ca8ec1a2f04c4ed90897225231c58c124a7 ]
    
    We've seen recent AWS EKS (Kubernetes) user reports like the following:
    
      After upgrading EKS nodes from v20230203 to v20230217 on our 1.24 EKS
      clusters after a few days a number of the nodes have containers stuck
      in ContainerCreating state or liveness/readiness probes reporting the
      following error:
    
        Readiness probe errored: rpc error: code = Unknown desc = failed to
        exec in container: failed to start exec "4a11039f730203ffc003b7[...]":
        OCI runtime exec failed: exec failed: unable to start container process:
        unable to init seccomp: error loading seccomp filter into kernel:
        error loading seccomp filter: errno 524: unknown
    
      However, we had not been seeing this issue on previous AMIs and it only
      started to occur on v20230217 (following the upgrade from kernel 5.4 to
      5.10) with no other changes to the underlying cluster or workloads.
    
      We tried the suggestions from that issue (sysctl net.core.bpf_jit_limit=452534528)
      which helped to immediately allow containers to be created and probes to
      execute but after approximately a day the issue returned and the value
      returned by cat /proc/vmallocinfo | grep bpf_jit | awk '{s+=$2} END {print s}'
      was steadily increasing.
    
    I tested bpf tree to observe bpf_jit_charge_modmem, bpf_jit_uncharge_modmem
    their sizes passed in as well as bpf_jit_current under tcpdump BPF filter,
    seccomp BPF and native (e)BPF programs, and the behavior all looks sane
    and expected, that is nothing "leaking" from an upstream perspective.
    
    The bpf_jit_limit knob was originally added in order to avoid a situation
    where unprivileged applications loading BPF programs (e.g. seccomp BPF
    policies) consuming all the module memory space via BPF JIT such that loading
    of kernel modules would be prevented. The default limit was defined back in
    2018 and while good enough back then, we are generally seeing far more BPF
    consumers today.
    
    Adjust the limit for the BPF JIT pool from originally 1/4 to now 1/2 of the
    module memory space to better reflect today's needs and avoid more users
    running into potentially hard to debug issues.
    
    Fixes: fdadd04931c2 ("bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K")
    Reported-by: Stephen Haynes <[email protected]>
    Reported-by: Lefteris Alexakis <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://github.com/awslabs/amazon-eks-ami/issues/1179
    Link: https://github.com/awslabs/amazon-eks-ami/issues/1219
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
btrfs: zoned: fix btrfs_can_activate_zone() to support DUP profile [+ + +]
Author: Naohiro Aota <[email protected]>
Date:   Mon Mar 13 16:29:49 2023 +0900

    btrfs: zoned: fix btrfs_can_activate_zone() to support DUP profile
    
    commit 9e1cdf0c354e46e428c0e0cab008abbe81b6013d upstream.
    
    btrfs_can_activate_zone() returns true if at least one device has one zone
    available for activation. This is OK for the single profile, but not OK for
    DUP profile. We need two zones to create a DUP block group. Fix it by
    properly handling the case with the profile flags.
    
    Fixes: 265f7237dd25 ("btrfs: zoned: allow DUP on meta-data block groups")
    CC: [email protected] # 6.1+
    Reviewed-by: Johannes Thumshirn <[email protected]>
    Signed-off-by: Naohiro Aota <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
bus: imx-weim: fix branch condition evaluates to a garbage value [+ + +]
Author: Ivan Bornyakov <[email protected]>
Date:   Mon Mar 6 16:25:26 2023 +0300

    bus: imx-weim: fix branch condition evaluates to a garbage value
    
    commit 1adab2922c58e7ff4fa9f0b43695079402cce876 upstream.
    
    If bus type is other than imx50_weim_devtype and have no child devices,
    variable 'ret' in function weim_parse_dt() will not be initialized, but
    will be used as branch condition and return value. Fix this by
    initializing 'ret' with 0.
    
    This was discovered with help of clang-analyzer, but the situation is
    quite possible in real life.
    
    Fixes: 52c47b63412b ("bus: imx-weim: improve error handling upon child probe-failure")
    Signed-off-by: Ivan Bornyakov <[email protected]>
    Cc: [email protected]
    Reviewed-by: Fabio Estevam <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ca8210: fix mac_len negative array access [+ + +]
Author: Alexander Aring <[email protected]>
Date:   Thu Feb 16 23:25:04 2023 -0500

    ca8210: fix mac_len negative array access
    
    [ Upstream commit 6c993779ea1d0cccdb3a5d7d45446dd229e610a3 ]
    
    This patch fixes a buffer overflow access of skb->data if
    ieee802154_hdr_peek_addrs() fails.
    
    Reported-by: lianhui tang <[email protected]>
    Signed-off-by: Alexander Aring <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stefan Schmidt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cifs: append path to open_enter trace event [+ + +]
Author: Shyam Prasad N <[email protected]>
Date:   Fri Mar 17 12:51:17 2023 +0000

    cifs: append path to open_enter trace event
    
    commit fddc6ccc487e5de07b98df8d04118d5dcb5e0407 upstream.
    
    We do not dump the file path for smb3_open_enter ftrace
    calls, which is a severe handicap while debugging
    using ftrace evens. This change adds that info.
    
    Unfortunately, we're not updating the path in open params
    in many places; which I had to do as a part of this change.
    SMB2_open gets path in utf16 format, but it's easier of
    path is supplied as char pointer in oparms.
    
    Signed-off-by: Shyam Prasad N <[email protected]>
    Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
    Cc: [email protected]
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

cifs: do not poll server interfaces too regularly [+ + +]
Author: Shyam Prasad N <[email protected]>
Date:   Wed Mar 8 12:11:31 2023 +0000

    cifs: do not poll server interfaces too regularly
    
    commit 072a28c8907c841f7d4b56c78bce46d3ee211e73 upstream.
    
    We have the server interface list hanging off the tcon
    structure today for reasons unknown. So each tcon which is
    connected to a file server can query them separately,
    which is really unnecessary. To avoid this, in the query
    function, we will check the time of last update of the
    interface list, and avoid querying the server if it is
    within a certain range.
    
    Signed-off-by: Shyam Prasad N <[email protected]>
    Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
    Cc: [email protected]
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

cifs: dump pending mids for all channels in DebugData [+ + +]
Author: Shyam Prasad N <[email protected]>
Date:   Mon Mar 13 11:09:12 2023 +0000

    cifs: dump pending mids for all channels in DebugData
    
    commit d12bc6d26f92c51b28e8f4a146ffcc630b688198 upstream.
    
    Currently, we only dump the pending mid information only
    on the primary channel in /proc/fs/cifs/DebugData.
    If multichannel is active, we do not print the pending MID
    list on secondary channels.
    
    This change will dump the pending mids for all the channels
    based on server->conn_id.
    
    Signed-off-by: Shyam Prasad N <[email protected]>
    Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
    Cc: [email protected]
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

cifs: empty interface list when server doesn't support query interfaces [+ + +]
Author: Shyam Prasad N <[email protected]>
Date:   Thu Mar 9 13:23:29 2023 +0000

    cifs: empty interface list when server doesn't support query interfaces
    
    commit 896cd316b841053f6df95ab77b5f1322c16a8e18 upstream.
    
    When querying server interfaces returns -EOPNOTSUPP,
    clear the list of interfaces. Assumption is that multichannel
    would be disabled too.
    
    Signed-off-by: Shyam Prasad N <[email protected]>
    Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
    Cc: [email protected]
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

cifs: fix dentry lookups in directory handle cache [+ + +]
Author: Paulo Alcantara <[email protected]>
Date:   Fri Mar 24 13:56:33 2023 -0300

    cifs: fix dentry lookups in directory handle cache
    
    commit be4fde79812f02914e350bde0bc4cfeae8429378 upstream.
    
    Get rid of any prefix paths in @path before lookup_positive_unlocked()
    as it will call ->lookup() which already adds those prefix paths
    through build_path_from_dentry().
    
    This has caused a performance regression when mounting shares with a
    prefix path where readdir(2) would end up retrying several times to
    open bad directory names that contained duplicate prefix paths.
    
    Fix this by skipping any prefix paths in @path before calling
    lookup_positive_unlocked().
    
    Fixes: e4029e072673 ("cifs: find and use the dentry for cached non-root directories also")
    Cc: [email protected] # 6.1+
    Signed-off-by: Paulo Alcantara (SUSE) <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

cifs: lock chan_lock outside match_session [+ + +]
Author: Shyam Prasad N <[email protected]>
Date:   Mon Feb 20 13:02:11 2023 +0000

    cifs: lock chan_lock outside match_session
    
    commit 2f4e429c846972c8405951a9ff7a82aceeca7461 upstream.
    
    Coverity had rightly indicated a possible deadlock
    due to chan_lock being done inside match_session.
    All callers of match_* functions should pick up the
    necessary locks and call them.
    
    Signed-off-by: Shyam Prasad N <[email protected]>
    Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
    Cc: [email protected]
    Fixes: 724244cdb382 ("cifs: protect session channel fields with chan_lock")
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

cifs: print session id while listing open files [+ + +]
Author: Shyam Prasad N <[email protected]>
Date:   Mon Mar 13 12:17:34 2023 +0000

    cifs: print session id while listing open files
    
    commit 175b54abc443b6965e9379b71ec05f7c73c192e9 upstream.
    
    In the output of /proc/fs/cifs/open_files, we only print
    the tree id for the tcon of each open file. It becomes
    difficult to know which tcon these files belong to with
    just the tree id.
    
    This change dumps ses id in addition to all other data today.
    
    Signed-off-by: Shyam Prasad N <[email protected]>
    Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
    Cc: [email protected]
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cpumask: fix incorrect cpumask scanning result checks [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Mon Mar 6 12:15:13 2023 -0800

    cpumask: fix incorrect cpumask scanning result checks
    
    [ Upstream commit 8ca09d5fa3549d142c2080a72a4c70ce389163cd ]
    
    It turns out that commit 596ff4a09b89 ("cpumask: re-introduce
    constant-sized cpumask optimizations") exposed a number of cases of
    drivers not checking the result of "cpumask_next()" and friends
    correctly.
    
    The documented correct check for "no more cpus in the cpumask" is to
    check for the result being equal or larger than the number of possible
    CPU ids, exactly _because_ we've always done those constant-sized
    cpumask scans using a widened type before.  So the return value of a
    cpumask scan should be checked with
    
            if (cpu >= nr_cpu_ids)
                    ...
    
    because the cpumask scan did not necessarily stop exactly *at* that
    maximum CPU id.
    
    But a few cases ended up instead using checks like
    
            if (cpu == nr_cpumask_bits)
                    ...
    
    which used that internal "widened" number of bits.  And that used to
    work pretty much by accident (ok, in this case "by accident" is simply
    because it matched the historical internal implementation of the cpumask
    scanning, so it was more of a "intentionally using implementation
    details rather than an accident").
    
    But the extended constant-sized optimizations then did that internal
    implementation differently, and now that code that did things wrong but
    matched the old implementation no longer worked at all.
    
    Which then causes subsequent odd problems due to using what ends up
    being an invalid CPU ID.
    
    Most of these cases require either unusual hardware or special uses to
    hit, but the random.c one triggers quite easily.
    
    All you really need is to have a sufficiently small CONFIG_NR_CPUS value
    for the bit scanning optimization to be triggered, but not enough CPUs
    to then actually fill that widened cpumask.  At that point, the cpumask
    scanning will return the NR_CPUS constant, which is _not_ the same as
    nr_cpumask_bits.
    
    This just does the mindless fix with
    
       sed -i 's/== nr_cpumask_bits/>= nr_cpu_ids/'
    
    to fix the incorrect uses.
    
    The ones in the SCSI lpfc driver in particular could probably be fixed
    more cleanly by just removing that repeated pattern entirely, but I am
    not emptionally invested enough in that driver to care.
    
    Reported-and-tested-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]/
    Reported-and-tested-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/lkml/CAMuHMdUKo_Sf7TjKzcNDa8Ve+6QrK+P8nSQrSQ=6LTRmcBKNww@mail.gmail.com/
    Reported-by: Vernon Yang <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]/
    Cc: Yury Norov <[email protected]>
    Cc: Jason A. Donenfeld <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dm crypt: add cond_resched() to dmcrypt_write() [+ + +]
Author: Mikulas Patocka <[email protected]>
Date:   Mon Mar 6 11:17:58 2023 -0500

    dm crypt: add cond_resched() to dmcrypt_write()
    
    commit fb294b1c0ba982144ca467a75e7d01ff26304e2b upstream.
    
    The loop in dmcrypt_write may be running for unbounded amount of time,
    thus we need cond_resched() in it.
    
    This commit fixes the following warning:
    
    [ 3391.153255][   C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897]
    ...
    [ 3391.387210][   C12] Call trace:
    [ 3391.390338][   C12]  blk_attempt_bio_merge.part.6+0x38/0x158
    [ 3391.395970][   C12]  blk_attempt_plug_merge+0xc0/0x1b0
    [ 3391.401085][   C12]  blk_mq_submit_bio+0x398/0x550
    [ 3391.405856][   C12]  submit_bio_noacct+0x308/0x380
    [ 3391.410630][   C12]  dmcrypt_write+0x1e4/0x208 [dm_crypt]
    [ 3391.416005][   C12]  kthread+0x130/0x138
    [ 3391.419911][   C12]  ret_from_fork+0x10/0x18
    
    Reported-by: yangerkun <[email protected]>
    Fixes: dc2676210c42 ("dm crypt: offload writes to thread")
    Cc: [email protected]
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

dm crypt: avoid accessing uninitialized tasklet [+ + +]
Author: Mike Snitzer <[email protected]>
Date:   Wed Mar 8 14:39:54 2023 -0500

    dm crypt: avoid accessing uninitialized tasklet
    
    commit d9a02e016aaf5a57fb44e9a5e6da8ccd3b9e2e70 upstream.
    
    When neither "no_read_workqueue" nor "no_write_workqueue" are enabled,
    tasklet_trylock() in crypt_dec_pending() may still return false due to
    an uninitialized state, and dm-crypt will unnecessarily do io completion
    in io_queue workqueue instead of current context.
    
    Fix this by adding an 'in_tasklet' flag to dm_crypt_io struct and
    initialize it to false in crypt_io_init(). Set this flag to true in
    kcryptd_queue_crypt() before calling tasklet_schedule(). If set
    crypt_dec_pending() will punt io completion to a workqueue.
    
    This also nicely avoids the tasklet_trylock/unlock hack when tasklets
    aren't in use.
    
    Fixes: 8e14f610159d ("dm crypt: do not call bio_endio() from the dm-crypt tasklet")
    Cc: [email protected]
    Reported-by: Hou Tao <[email protected]>
    Suggested-by: Ignat Korchagin <[email protected]>
    Reviewed-by: Ignat Korchagin <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dm stats: check for and propagate alloc_percpu failure [+ + +]
Author: Jiasheng Jiang <[email protected]>
Date:   Thu Mar 16 14:55:06 2023 +0800

    dm stats: check for and propagate alloc_percpu failure
    
    commit d3aa3e060c4a80827eb801fc448debc9daa7c46b upstream.
    
    Check alloc_precpu()'s return value and return an error from
    dm_stats_init() if it fails. Update alloc_dev() to fail if
    dm_stats_init() does.
    
    Otherwise, a NULL pointer dereference will occur in dm_stats_cleanup()
    even if dm-stats isn't being actively used.
    
    Fixes: fd2ed4d25270 ("dm: add statistics support")
    Cc: [email protected]
    Signed-off-by: Jiasheng Jiang <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dm thin: fix deadlock when swapping to thin device [+ + +]
Author: Coly Li <[email protected]>
Date:   Mon Feb 27 23:23:17 2023 +0800

    dm thin: fix deadlock when swapping to thin device
    
    commit 9bbf5feecc7eab2c370496c1c161bbfe62084028 upstream.
    
    This is an already known issue that dm-thin volume cannot be used as
    swap, otherwise a deadlock may happen when dm-thin internal memory
    demand triggers swap I/O on the dm-thin volume itself.
    
    But thanks to commit a666e5c05e7c ("dm: fix deadlock when swapping to
    encrypted device"), the limit_swap_bios target flag can also be used
    for dm-thin to avoid the recursive I/O when it is used as swap.
    
    Fix is to simply set ti->limit_swap_bios to true in both pool_ctr()
    and thin_ctr().
    
    In my test, I create a dm-thin volume /dev/vg/swap and use it as swap
    device. Then I run fio on another dm-thin volume /dev/vg/main and use
    large --blocksize to trigger swap I/O onto /dev/vg/swap.
    
    The following fio command line is used in my test,
      fio --name recursive-swap-io --lockmem 1 --iodepth 128 \
         --ioengine libaio --filename /dev/vg/main --rw randrw \
        --blocksize 1M --numjobs 32 --time_based --runtime=12h
    
    Without this fix, the whole system can be locked up within 15 seconds.
    
    With this fix, there is no any deadlock or hung task observed after
    2 hours of running fio.
    
    Furthermore, if blocksize is changed from 1M to 128M, after around 30
    seconds fio has no visible I/O, and the out-of-memory killer message
    shows up in kernel message. After around 20 minutes all fio processes
    are killed and the whole system is back to being alive.
    
    This is exactly what is expected when recursive I/O happens on dm-thin
    volume when it is used as swap.
    
    Depends-on: a666e5c05e7c ("dm: fix deadlock when swapping to encrypted device")
    Cc: [email protected]
    Signed-off-by: Coly Li <[email protected]>
    Acked-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amd/display: Fix DP MST sinks removal issue [+ + +]
Author: Cruise Hung <[email protected]>
Date:   Wed Mar 22 17:08:41 2023 -0500

    drm/amd/display: Fix DP MST sinks removal issue
    
    [ Upstream commit cbd6c1b17d3b42b7935526a86ad5f66838767d03 ]
    
    [Why]
    In USB4 DP tunneling, it's possible to have this scenario that
    the path becomes unavailable and CM tears down the path a little bit late.
    So, in this case, the HPD is high but fails to read any DPCD register.
    That causes the link connection type to be set to sst.
    And not all sinks are removed behind the MST branch.
    
    [How]
    Restore the link connection type if it fails to read DPCD register.
    
    Cc: [email protected]
    Cc: Mario Limonciello <[email protected]>
    Reviewed-by: Wenjing Liu <[email protected]>
    Acked-by: Qingqing Zhuo <[email protected]>
    Signed-off-by: Cruise Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit cbd6c1b17d3b42b7935526a86ad5f66838767d03)
    Modified for stable backport as a lot of the code in this file was moved
    in 6.3 to drivers/gpu/drm/amd/display/dc/link/link_detection.c.
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: fix k1 k2 divider programming for phantom streams [+ + +]
Author: Aurabindo Pillai <[email protected]>
Date:   Mon Jan 30 13:07:59 2023 -0500

    drm/amd/display: fix k1 k2 divider programming for phantom streams
    
    [ Upstream commit 3b214bb7185d8284d7d4c53e15127f69a375abf6 ]
    
    [Why & How]
    When k1 and k2 divider programming logic is executed for a phantom
    stream, the corresponding master stream should be used for the
    calculation. Fix the if condition to use the master stream for checking
    signal type instead of the phantom stream.
    
    Reviewed-by: Alvin Lee <[email protected]>
    Acked-by: Qingqing Zhuo <[email protected]>
    Signed-off-by: Aurabindo Pillai <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 709671ffb15d ("drm/amd/display: Remove OTG DIV register write for Virtual signals.")
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: fix wrong index used in dccg32_set_dpstreamclk [+ + +]
Author: Hersen Wu <[email protected]>
Date:   Thu Mar 9 16:14:08 2023 -0500

    drm/amd/display: fix wrong index used in dccg32_set_dpstreamclk
    
    commit 4c94e57c258cb7800aa5f3a9d9597d91291407a9 upstream.
    
    [Why & How]
    When merging commit 9af611f29034
    ("drm/amd/display: Fix DCN32 DPSTREAMCLK_CNTL programming"),
    index change was not picked up.
    
    Cc: [email protected]
    Cc: Mario Limonciello <[email protected]>
    Fixes: 9af611f29034 ("drm/amd/display: Fix DCN32 DPSTREAMCLK_CNTL programming")
    Reviewed-by: Qingqing Zhuo <[email protected]>
    Acked-by: Qingqing Zhuo <[email protected]>
    Signed-off-by: Hersen Wu <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Remove OTG DIV register write for Virtual signals. [+ + +]
Author: Saaem Rizvi <[email protected]>
Date:   Mon Feb 27 18:55:07 2023 -0500

    drm/amd/display: Remove OTG DIV register write for Virtual signals.
    
    [ Upstream commit 709671ffb15dcd1b4f6afe2a9d8c67c7c4ead4a1 ]
    
    [WHY]
    Hot plugging and then hot unplugging leads to k1 and k2 values to
    change, as signal is detected as a virtual signal on hot unplug. Writing
    these values to OTG_PIXEL_RATE_DIV register might cause primary display
    to blank (known hw bug).
    
    [HOW]
    No longer write k1 and k2 values to register if signal is virtual, we
    have safe guards in place in the case that k1 and k2 is unassigned so
    that an unknown value is not written to the register either.
    
    Cc: [email protected]
    Cc: Mario Limonciello <[email protected]>
    Reviewed-by: Samson Tam <[email protected]>
    Reviewed-by: Alvin Lee <[email protected]>
    Acked-by: Qingqing Zhuo <[email protected]>
    Signed-off-by: Saaem Rizvi <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Set dcn32 caps.seamless_odm [+ + +]
Author: Hersen Wu <[email protected]>
Date:   Thu Mar 9 15:58:54 2023 -0500

    drm/amd/display: Set dcn32 caps.seamless_odm
    
    [ Upstream commit f9537b1fa7fb51c2162bc15ce469cbbf1ca0fbfe ]
    
    [Why & How]
    seamless_odm set was not picked up while
    merging commit 2d017189e2b3 ("drm/amd/display:
    Blank eDP on enable drv if odm enabled")
    
    Fixes: 2d017189e2b3 ("drm/amd/display: Blank eDP on enable drv if odm enabled")
    Reviewed-by: Qingqing Zhuo <[email protected]>
    Acked-by: Qingqing Zhuo <[email protected]>
    Signed-off-by: Hersen Wu <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Update clock table to include highest clock setting [+ + +]
Author: Swapnil Patel <[email protected]>
Date:   Wed Mar 1 14:33:33 2023 -0500

    drm/amd/display: Update clock table to include highest clock setting
    
    [ Upstream commit 2d99a7ec25cf456cd3680eb314d6454138e5aa64 ]
    
    [Why]
    Currently, the clk manager matches SocVoltage with voltage from
    fused settings (dfPstate clock table). And then corresponding clocks
    are selected.
    
    However in certain situations, this leads to clk manager not
    including at least one entry with highest supported clock setting.
    
    [How]
    Update the clk manager to include at least one entry with highest
    supported clock setting.
    
    Reviewed-by: Pavle Kotarac <[email protected]>
    Acked-by: Qingqing Zhuo <[email protected]>
    Signed-off-by: Swapnil Patel <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd: Fix initialization mistake for NBIO 7.3.0 [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Wed Mar 1 09:36:06 2023 -0600

    drm/amd: Fix initialization mistake for NBIO 7.3.0
    
    [ Upstream commit 1717cc5f2962a4652c76ed3858b499ccae6c277c ]
    
    The same strapping initialization issue that happened on NBIO 7.5.1
    appears to be happening on NBIO 7.3.0.
    Apply the same fix to 7.3.0 as well.
    
    Note: This workaround relies upon the integrated GPU being enabled
    in BIOS. If the integrated GPU is disabled in BIOS a different
    workaround will be required.
    
    Reported-by: Thomas Glanzmann <[email protected]>
    Cc: Basavaraj Natikar <[email protected]>
    Link: https://lore.kernel.org/linux-usb/Y%[email protected]/T/#u
    Signed-off-by: Mario Limonciello <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/nv: Apply ASPM quirk on Intel ADL + AMD Navi [+ + +]
Author: Kai-Heng Feng <[email protected]>
Date:   Wed Mar 15 20:07:23 2023 +0800

    drm/amdgpu/nv: Apply ASPM quirk on Intel ADL + AMD Navi
    
    commit 2b072442f4962231a8516485012bb2d2551ef2fe upstream.
    
    S2idle resume freeze can be observed on Intel ADL + AMD WX5500. This is
    caused by commit 0064b0ce85bb ("drm/amd/pm: enable ASPM by default").
    
    The root cause is still not clear for now.
    
    So extend and apply the ASPM quirk from commit e02fe3bc7aba
    ("drm/amdgpu: vi: disable ASPM on Intel Alder Lake based systems"), to
    workaround the issue on Navi cards too.
    
    Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2458
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Kai-Heng Feng <[email protected]>
    Reviewed-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdgpu: Fix call trace warning and hang when removing amdgpu device [+ + +]
Author: lyndonli <[email protected]>
Date:   Thu Mar 2 14:18:12 2023 +0800

    drm/amdgpu: Fix call trace warning and hang when removing amdgpu device
    
    [ Upstream commit 93bb18d2a873d2fa9625c8ea927723660a868b95 ]
    
    On GPUs with RAS enabled, below call trace and hang are observed when
    shutting down device.
    
    v2: use DRM device unplugged flag instead of shutdown flag as the check to
    prevent memory wipe in shutdown stage.
    
    [ +0.000000] RIP: 0010:amdgpu_vram_mgr_fini+0x18d/0x1c0 [amdgpu]
    [ +0.000001] PKRU: 55555554
    [ +0.000001] Call Trace:
    [ +0.000001] <TASK>
    [ +0.000002] amdgpu_ttm_fini+0x140/0x1c0 [amdgpu]
    [ +0.000183] amdgpu_bo_fini+0x27/0xa0 [amdgpu]
    [ +0.000184] gmc_v11_0_sw_fini+0x2b/0x40 [amdgpu]
    [ +0.000163] amdgpu_device_fini_sw+0xb6/0x510 [amdgpu]
    [ +0.000152] amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
    [ +0.000090] drm_dev_release+0x28/0x50 [drm]
    [ +0.000016] devm_drm_dev_init_release+0x38/0x60 [drm]
    [ +0.000011] devm_action_release+0x15/0x20
    [ +0.000003] release_nodes+0x40/0xc0
    [ +0.000001] devres_release_all+0x9e/0xe0
    [ +0.000001] device_unbind_cleanup+0x12/0x80
    [ +0.000003] device_release_driver_internal+0xff/0x160
    [ +0.000001] driver_detach+0x4a/0x90
    [ +0.000001] bus_remove_driver+0x6c/0xf0
    [ +0.000001] driver_unregister+0x31/0x50
    [ +0.000001] pci_unregister_driver+0x40/0x90
    [ +0.000003] amdgpu_exit+0x15/0x120 [amdgpu]
    
    Signed-off-by: lyndonli <[email protected]>
    Reviewed-by: Guchun Chen <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: reposition the gpu reset checking for reuse [+ + +]
Author: Tim Huang <[email protected]>
Date:   Wed Mar 15 15:52:09 2023 +0800

    drm/amdgpu: reposition the gpu reset checking for reuse
    
    commit aaee0ce460b954e08b6e630d7e54b2abb672feb8 upstream.
    
    Move the amdgpu_acpi_should_gpu_reset out of
    CONFIG_SUSPEND to share it with hibernate case.
    
    Signed-off-by: Tim Huang <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # 6.1.x
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amdgpu: skip ASIC reset for APUs when go to S4 [+ + +]
Author: Tim Huang <[email protected]>
Date:   Thu Mar 9 16:27:51 2023 +0800

    drm/amdgpu: skip ASIC reset for APUs when go to S4
    
    commit b589626674de94d977e81c99bf7905872b991197 upstream.
    
    For GC IP v11.0.4/11, PSP TMR need to be reserved
    for ASIC mode2 reset. But for S4, when psp suspend,
    it will destroy the TMR that fails the ASIC reset.
    
    [  96.006101] amdgpu 0000:62:00.0: amdgpu: MODE2 reset
    [  100.409717] amdgpu 0000:62:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000011 SMN_C2PMSG_82:0x00000002
    [  100.411593] amdgpu 0000:62:00.0: amdgpu: Mode2 reset failed!
    [  100.412470] amdgpu 0000:62:00.0: PM: pci_pm_freeze(): amdgpu_pmops_freeze+0x0/0x50 [amdgpu] returns -62
    [  100.414020] amdgpu 0000:62:00.0: PM: dpm_run_callback(): pci_pm_freeze+0x0/0xd0 returns -62
    [  100.415311] amdgpu 0000:62:00.0: PM: pci_pm_freeze+0x0/0xd0 returned -62 after 4623202 usecs
    [  100.416608] amdgpu 0000:62:00.0: PM: failed to freeze async: error -62
    
    We can skip the reset on APUs, assuming we can resume them
    properly. Verified on some GFX11, GFX10 and old GFX9 APUs.
    
    Signed-off-by: Tim Huang <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # 6.1.x
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/bridge: lt8912b: return EPROBE_DEFER if bridge is not found [+ + +]
Author: Matheus Castello <[email protected]>
Date:   Wed Mar 22 15:38:21 2023 +0100

    drm/bridge: lt8912b: return EPROBE_DEFER if bridge is not found
    
    commit 1a70ca89d59c7c8af006d29b965a95ede0abb0da upstream.
    
    Returns EPROBE_DEFER when of_drm_find_bridge() fails, this is consistent
    with what all the other DRM bridge drivers are doing and this is
    required since the bridge might not be there when the driver is probed
    and this should not be a fatal failure.
    
    Cc: <[email protected]>
    Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
    Signed-off-by: Matheus Castello <[email protected]>
    Signed-off-by: Francesco Dolcini <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Reviewed-by: Andrzej Hajda <[email protected]>
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/cirrus: NULL-check pipe->plane.state->fb in cirrus_pipe_update() [+ + +]
Author: Alexandr Sapozhnikov <[email protected]>
Date:   Wed Feb 15 20:15:49 2023 +0300

    drm/cirrus: NULL-check pipe->plane.state->fb in cirrus_pipe_update()
    
    [ Upstream commit 7245e629dcaaf308f1868aeffa218e9849c77893 ]
    
    After having been compared to NULL value at cirrus.c:455, pointer
    'pipe->plane.state->fb' is passed as 1st parameter in call to function
    'cirrus_fb_blit_rect' at cirrus.c:461, where it is dereferenced at
    cirrus.c:316.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    v2:
            * aligned commit message to line-length limits
    
    Signed-off-by: Alexandr Sapozhnikov <[email protected]>
    Reviewed-by: Thomas Zimmermann <[email protected]>
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/active: Fix missing debug object activation [+ + +]
Author: Nirmoy Das <[email protected]>
Date:   Tue Mar 14 15:29:14 2023 +0100

    drm/i915/active: Fix missing debug object activation
    
    commit e92eb246feb9019b0b137706c934b8891cdfe3c2 upstream.
    
    debug_active_activate() expected ref->count to be zero
    which is not true anymore as __i915_active_activate() calls
    debug_active_activate() after incrementing the count.
    
    v2: No need to check for "ref->count == 1" as __i915_active_activate()
    already make sure of that(Janusz).
    
    References: https://gitlab.freedesktop.org/drm/intel/-/issues/6733
    Fixes: 04240e30ed06 ("drm/i915: Skip taking acquire mutex for no ref->active callback")
    Cc: Chris Wilson <[email protected]>
    Cc: Tvrtko Ursulin <[email protected]>
    Cc: Thomas Hellström <[email protected]>
    Cc: Andi Shyti <[email protected]>
    Cc: [email protected]
    Cc: Janusz Krzysztofik <[email protected]>
    Cc: <[email protected]> # v5.10+
    Signed-off-by: Nirmoy Das <[email protected]>
    Reviewed-by: Janusz Krzysztofik <[email protected]>
    Reviewed-by: Andrzej Hajda <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit bfad380c542438a9b642f8190b7fd37bc77e2723)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/i915/fbdev: lock the fbdev obj before vma pin [+ + +]
Author: Tejas Upadhyay <[email protected]>
Date:   Wed Mar 1 12:10:52 2023 -0800

    drm/i915/fbdev: lock the fbdev obj before vma pin
    
    [ Upstream commit ed00eba03474adbf525ff03d69705d8c78b76456 ]
    
    lock the fbdev obj before calling into
    i915_vma_pin_iomap(). This helps to solve below :
    
    <7>[   93.563308] i915 0000:00:02.0: [drm:intelfb_create [i915]] no BIOS fb, allocating a new one
    <4>[   93.581844] ------------[ cut here ]------------
    <4>[   93.581855] WARNING: CPU: 12 PID: 625 at drivers/gpu/drm/i915/gem/i915_gem_pages.c:424 i915_gem_object_pin_map+0x152/0x1c0 [i915]
    
    Fixes: f0b6b01b3efe ("drm/i915: Add ww context to intel_dpt_pin, v2.")
    Cc: Chris Wilson <[email protected]>
    Cc: Matthew Auld <[email protected]>
    Cc: Maarten Lankhorst <[email protected]>
    Signed-off-by: Tejas Upadhyay <[email protected]>
    Signed-off-by: Radhakrishna Sripada <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 561b31acfd65502a2cda2067513240fc57ccdbdc)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/gt: perform uc late init after probe error injection [+ + +]
Author: Andrzej Hajda <[email protected]>
Date:   Tue Mar 14 16:19:20 2023 +0100

    drm/i915/gt: perform uc late init after probe error injection
    
    [ Upstream commit 150784f9285e656373cf3953ef4a7663f1e1a0f2 ]
    
    Probe pseudo errors should be injected only in places where real errors
    can be encountered, otherwise unwinding code can be broken.
    Placing intel_uc_init_late before i915_inject_probe_error violated
    this rule, resulting in following bug:
    __intel_gt_disable:655 GEM_BUG_ON(intel_gt_pm_is_awake(gt))
    
    Fixes: 481d458caede ("drm/i915/guc: Add golden context to GuC ADS")
    Acked-by: Nirmoy Das <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Andrzej Hajda <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit c4252a11131c7f27a158294241466e2a4e7ff94e)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/guc: Fix missing ecodes [+ + +]
Author: John Harrison <[email protected]>
Date:   Fri Mar 10 22:37:12 2023 -0800

    drm/i915/guc: Fix missing ecodes
    
    [ Upstream commit 8df23e4c4f72f4e201c28e6fb0a67e2dbf30628a ]
    
    Error captures are tagged with an 'ecode'. This is a pseduo-unique magic
    number that is meant to distinguish similar seeming bugs with
    different underlying signatures. It is a combination of two ring state
    registers. Unfortunately, the register state being used is only valid
    in execlist mode. In GuC mode, the register state exists in a separate
    list of arbitrary register address/value pairs rather than the named
    entry structure. So, search through that list to find the two exciting
    registers and copy them over to the structure's named members.
    
    v2: if else if instead of if if (Alan)
    
    Signed-off-by: John Harrison <[email protected]>
    Reviewed-by: Alan Previn <[email protected]>
    Fixes: a6f0f9cf330a ("drm/i915/guc: Plumb GuC-capture into gpu_coredump")
    Cc: Alan Previn <[email protected]>
    Cc: Umesh Nerlige Ramappa <[email protected]>
    Cc: Lucas De Marchi <[email protected]>
    Cc: Jani Nikula <[email protected]>
    Cc: Joonas Lahtinen <[email protected]>
    Cc: Rodrigo Vivi <[email protected]>
    Cc: Tvrtko Ursulin <[email protected]>
    Cc: Matt Roper <[email protected]>
    Cc: Aravind Iddamsetty <[email protected]>
    Cc: Michael Cheng <[email protected]>
    Cc: Matthew Brost <[email protected]>
    Cc: Bruce Chang <[email protected]>
    Cc: Daniele Ceraolo Spurio <[email protected]>
    Cc: Matthew Auld <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 9724ecdbb9ddd6da3260e4a442574b90fc75188a)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/i915/guc: Rename GuC register state capture node to be more obvious [+ + +]
Author: John Harrison <[email protected]>
Date:   Thu Jan 26 16:28:42 2023 -0800

    drm/i915/guc: Rename GuC register state capture node to be more obvious
    
    [ Upstream commit 583ebae783b8241a30581c084ad6226051b594c5 ]
    
    The GuC specific register state entry in the error capture object was
    just called 'capture'. Although the companion 'node' entry was called
    'guc_capture_node'. Rename the base entry to be 'guc_capture' instead
    so that it is a) more consistent and b) more obvious what it is.
    
    Signed-off-by: John Harrison <[email protected]>
    Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Stable-dep-of: 8df23e4c4f72 ("drm/i915/guc: Fix missing ecodes")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/mtl: Disable MC6 for MTL A step [+ + +]
Author: Badal Nilawar <[email protected]>
Date:   Fri Mar 10 11:43:39 2023 +0530

    drm/i915/mtl: Disable MC6 for MTL A step
    
    [ Upstream commit 088a422c3fa3ee9268d400078626b0c202cfe9dd ]
    
    The Wa_14017073508 require to send Media Busy/Idle mailbox while
    accessing Media tile. As of now it is getting handled while __gt_unpark,
    __gt_park. But there are various corner cases where forcewakes are taken
    without __gt_unpark i.e. without sending Busy Mailbox especially during
    register reads. Forcewakes are taken without busy mailbox leads to
    GPU HANG. So bringing mailbox calls under forcewake calls are no feasible
    option as forcewake calls are atomic and mailbox calls are blocking.
    The issue already fixed in B step so disabling MC6 on A step and
    reverting previous commit which handles Wa_14017073508
    
    Fixes: 8f70f1ec587d ("drm/i915/mtl: Add Wa_14017073508 for SAMedia")
    Cc: Rodrigo Vivi <[email protected]>
    Signed-off-by: Badal Nilawar <[email protected]>
    Reviewed-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Anshuman Gupta <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 038a24835ab68f341eaa7a0e3bcc6ce0f9b22e17)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915: Fix format for perf_limit_reasons [+ + +]
Author: Vinay Belgaumkar <[email protected]>
Date:   Tue Mar 14 19:29:06 2023 -0700

    drm/i915: Fix format for perf_limit_reasons
    
    [ Upstream commit f8d62aa8d24d9883df738e450bfe6be396e11979 ]
    
    Use hex format so that it is easier to decode.
    
    Fixes: fe5979665f64 ("drm/i915/debugfs: Add perf_limit_reasons in debugfs")
    Signed-off-by: Vinay Belgaumkar <[email protected]>
    Reviewed-by: Ashutosh Dixit <[email protected]>
    Signed-off-by: John Harrison <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 5e008ba67cb80084e99b40ccd46f9029ae421632)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/i915: Preserve crtc_state->inherited during state clearing [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Thu Feb 23 17:20:48 2023 +0200

    drm/i915: Preserve crtc_state->inherited during state clearing
    
    commit 3a84f2c6c9558c554a90ec26ad25df92fc5e05b7 upstream.
    
    intel_crtc_prepare_cleared_state() is unintentionally losing
    the "inherited" flag. This will happen if intel_initial_commit()
    is forced to go through the full modeset calculations for
    whatever reason.
    
    Afterwards the first real commit from userspace will not get
    forced to the full modeset path, and thus eg. audio state may
    not get recomputed properly. So if the monitor was already
    enabled during boot audio will not work until userspace itself
    does an explicit full modeset.
    
    Cc: [email protected]
    Tested-by: Lee Shawn C <[email protected]>
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Uma Shankar <[email protected]>
    (cherry picked from commit 2553bacaf953b48c59357f5a622282bc0c45adae)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/i915: Update vblank timestamping stuff on seamless M/N change [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Sat Mar 11 01:58:25 2023 +0200

    drm/i915: Update vblank timestamping stuff on seamless M/N change
    
    [ Upstream commit 59ad01c786a4c94afacc7feb0ab97bf8d6672a46 ]
    
    When we change the M/N values seamlessly during a fastset we should
    also update the vblank timestamping stuff to make sure the vblank
    timestamp corrections/guesstimations come out exact.
    
    Note that only crtc_clock and framedur_ns can actually end up
    changing here during fastsets. Everything else we touch can
    only change during full modesets.
    
    Technically we should try to do this exactly at the start of
    vblank, but that would require some kind of double buffering
    scheme. Let's skip that for now and just update things right
    after the commit has been submitted to the hardware. This
    means the information will be properly up to date when the
    vblank irq handler goes to work. Only if someone ends up
    querying some vblanky stuff in between the commit and start
    of vblank may we see a slight discrepancy.
    
    Also this same problem really exists for the DRRS downclocking
    stuff. But as that is supposed to be more or less transparent
    to the user, and it only drops to low gear after a long delay
    (1 sec currently) we probably don't have to worry about it.
    Any time something is actively submitting updates DRRS will
    remain in high gear and so the timestamping constants will
    match the hardware state.
    
    Reviewed-by: Jani Nikula <[email protected]>
    Reviewed-by: Mitul Golani <[email protected]>
    Fixes: e6f29923c048 ("drm/i915: Allow M/N change during fastset on bdw+")
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 8cb1f95cca68421b08333175719fdd3615372ca8)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/meson: fix missing component unbind on bind errors [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Mon Mar 6 11:35:33 2023 +0100

    drm/meson: fix missing component unbind on bind errors
    
    commit ba98413bf45edbf33672e2539e321b851b2cfbd1 upstream.
    
    Make sure to unbind all subcomponents when binding the aggregate device
    fails.
    
    Fixes: a41e82e6c457 ("drm/meson: Add support for components")
    Cc: [email protected]      # 4.12
    Cc: Neil Armstrong <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Acked-by: Neil Armstrong <[email protected]>
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
efi/libstub: smbios: Use length member instead of record struct size [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Tue Feb 28 19:23:09 2023 +0100

    efi/libstub: smbios: Use length member instead of record struct size
    
    [ Upstream commit 34343eb06afc04af9178a9883d9354dc12beede0 ]
    
    The type 1 SMBIOS record happens to always be the same size, but there
    are other record types which have been augmented over time, and so we
    should really use the length field in the header to decide where the
    string table starts.
    
    Fixes: 550b33cfd4452968 ("arm64: efi: Force the use of ...")
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

efi/libstub: Use relocated version of kernel's struct screen_info [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Wed Mar 22 01:11:18 2023 +0100

    efi/libstub: Use relocated version of kernel's struct screen_info
    
    [ Upstream commit fc3608aaa5751318837e4bbe0282b3836bca5080 ]
    
    In some cases, we expose the kernel's struct screen_info to the EFI stub
    directly, so it gets populated before even entering the kernel.  This
    means the early console is available as soon as the early param parsing
    happens, which is nice. It also means we need two different ways to pass
    this information, as this trick only works if the EFI stub is baked into
    the core kernel image, which is not always the case.
    
    Huacai reports that the preparatory refactoring that was needed to
    implement this alternative method for zboot resulted in a non-functional
    efifb earlycon for other cases as well, due to the reordering of the
    kernel image relocation with the population of the screen_info struct,
    and the latter now takes place after copying the image to its new
    location, which means we copy the old, uninitialized state.
    
    So let's ensure that the same-image version of alloc_screen_info()
    produces the correct screen_info pointer, by taking the displacement of
    the loaded image into account.
    
    Reported-by: Huacai Chen <[email protected]>
    Tested-by: Huacai Chen <[email protected]>
    Link: https://lore.kernel.org/linux-efi/[email protected]/
    Fixes: 42c8ea3dca094ab8 ("efi: libstub: Factor out EFI stub entrypoint into separate file")
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

efi/libstub: zboot: Mark zboot EFI application as NX compatible [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Fri Mar 10 12:15:24 2023 +0100

    efi/libstub: zboot: Mark zboot EFI application as NX compatible
    
    commit c7d9e628b8ff4d52a365a441bdacb3209ee83c81 upstream.
    
    Now that the zboot loader will invoke the EFI memory attributes protocol
    to remap the decompressed code and rodata as read-only/executable, we
    can set the PE/COFF header flag that indicates to the firmware that the
    application does not rely on writable memory being executable at the
    same time.
    
    Cc: <[email protected]> # v6.2+
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
efi: earlycon: Reprobe after parsing config tables [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Sun Mar 12 23:00:03 2023 +0100

    efi: earlycon: Reprobe after parsing config tables
    
    [ Upstream commit 8b3a149db461d3286d1e211112de3b44ccaeaf71 ]
    
    Commit 732ea9db9d8a ("efi: libstub: Move screen_info handling to common
    code") reorganized the earlycon handling so that all architectures pass
    the screen_info data via a EFI config table instead of populating struct
    screen_info directly, as the latter is only possible when the EFI stub
    is baked into the kernel (and not into the decompressor).
    
    However, this means that struct screen_info may not have been populated
    yet by the time the earlycon probe takes place, and this results in a
    non-functional early console.
    
    So let's probe again right after parsing the config tables and
    populating struct screen_info. Note that this means that earlycon output
    starts a bit later than before, and so it may fail to capture issues
    that occur while doing the early EFI initialization.
    
    Fixes: 732ea9db9d8a ("efi: libstub: Move screen_info handling to common code")
    Reported-by: Shawn Guo <[email protected]>
    Tested-by: Shawn Guo <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

efi: sysfb_efi: Fix DMI quirks not working for simpledrm [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Tue Mar 14 13:31:02 2023 +0100

    efi: sysfb_efi: Fix DMI quirks not working for simpledrm
    
    commit 3615c78673c332b69aaacefbcde5937c5c706686 upstream.
    
    Commit 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup
    for all arches") moved the sysfb_apply_efi_quirks() call in sysfb_init()
    from before the [sysfb_]parse_mode() call to after it.
    But sysfb_apply_efi_quirks() modifies the global screen_info struct which
    [sysfb_]parse_mode() parses, so doing it later is too late.
    
    This has broken all DMI based quirks for correcting wrong firmware efifb
    settings when simpledrm is used.
    
    To fix this move the sysfb_apply_efi_quirks() call back to its old place
    and split the new setup of the efifb_fwnode (which requires
    the platform_device) into its own function and call that at
    the place of the moved sysfb_apply_efi_quirks(pd) calls.
    
    Fixes: 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches")
    Cc: [email protected]
    Cc: Javier Martinez Canillas <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Reviewed-by: Javier Martinez Canillas <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
entry/rcu: Check TIF_RESCHED _after_ delayed RCU wake-up [+ + +]
Author: Frederic Weisbecker <[email protected]>
Date:   Wed Mar 15 19:43:43 2023 +0000

    entry/rcu: Check TIF_RESCHED _after_ delayed RCU wake-up
    
    [ Upstream commit b416514054810cf2d2cc348ae477cea619b64da7 ]
    
    RCU sometimes needs to perform a delayed wake up for specific kthreads
    handling offloaded callbacks (RCU_NOCB).  These wakeups are performed
    by timers and upon entry to idle (also to guest and to user on nohz_full).
    
    However the delayed wake-up on kernel exit is actually performed after
    the thread flags are fetched towards the fast path check for work to
    do on exit to user. As a result, and if there is no other pending work
    to do upon that kernel exit, the current task will resume to userspace
    with TIF_RESCHED set and the pending wake up ignored.
    
    Fix this with fetching the thread flags _after_ the delayed RCU-nocb
    kthread wake-up.
    
    Fixes: 47b8ff194c1f ("entry: Explicitly flush pending rcuog wakeup before last rescheduling point")
    Signed-off-by: Frederic Weisbecker <[email protected]>
    Signed-off-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Joel Fernandes (Google) <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
entry: Fix noinstr warning in __enter_from_user_mode() [+ + +]
Author: Josh Poimboeuf <[email protected]>
Date:   Sat Feb 25 16:01:36 2023 -0800

    entry: Fix noinstr warning in __enter_from_user_mode()
    
    [ Upstream commit f87d28673b71b35b248231a2086f9404afbb7f28 ]
    
    __enter_from_user_mode() is triggering noinstr warnings with
    CONFIG_DEBUG_PREEMPT due to its call of preempt_count_add() via
    ct_state().
    
    The preemption disable isn't needed as interrupts are already disabled.
    And the context_tracking_enabled() check in ct_state() also isn't needed
    as that's already being done by the CT_WARN_ON().
    
    Just use __ct_state() instead.
    
    Fixes the following warnings:
    
      vmlinux.o: warning: objtool: enter_from_user_mode+0xba: call to preempt_count_add() leaves .noinstr.text section
      vmlinux.o: warning: objtool: syscall_enter_from_user_mode+0xf9: call to preempt_count_add() leaves .noinstr.text section
      vmlinux.o: warning: objtool: syscall_enter_from_user_mode_prepare+0xc7: call to preempt_count_add() leaves .noinstr.text section
      vmlinux.o: warning: objtool: irqentry_enter_from_user_mode+0xba: call to preempt_count_add() leaves .noinstr.text section
    
    Fixes: 171476775d32 ("context_tracking: Convert state to atomic_t")
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/d8955fa6d68dc955dda19baf13ae014ae27926f5.1677369694.git.jpoimboe@kernel.org
    Signed-off-by: Sasha Levin <[email protected]>

 
erspan: do not use skb_mac_header() in ndo_start_xmit() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon Mar 20 16:34:27 2023 +0000

    erspan: do not use skb_mac_header() in ndo_start_xmit()
    
    [ Upstream commit 8e50ed774554f93d55426039b27b1e38d7fa64d8 ]
    
    Drivers should not assume skb_mac_header(skb) == skb->data in their
    ndo_start_xmit().
    
    Use skb_network_offset() and skb_transport_offset() which
    better describe what is needed in erspan_fb_xmit() and
    ip6erspan_tunnel_xmit()
    
    syzbot reported:
    WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]
    WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
    Modules linked in:
    CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
    RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]
    RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
    Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 <0f> 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00
    RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
    RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003
    RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff
    R10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00
    R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000
    FS: 0000555556a61300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000055e5b11eb6e8 CR3: 0000000027c1b000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    __netdev_start_xmit include/linux/netdevice.h:4900 [inline]
    netdev_start_xmit include/linux/netdevice.h:4914 [inline]
    __dev_direct_xmit+0x504/0x730 net/core/dev.c:4300
    dev_direct_xmit include/linux/netdevice.h:3088 [inline]
    packet_xmit+0x20a/0x390 net/packet/af_packet.c:285
    packet_snd net/packet/af_packet.c:3075 [inline]
    packet_sendmsg+0x31a0/0x5150 net/packet/af_packet.c:3107
    sock_sendmsg_nosec net/socket.c:724 [inline]
    sock_sendmsg+0xde/0x190 net/socket.c:747
    __sys_sendto+0x23a/0x340 net/socket.c:2142
    __do_sys_sendto net/socket.c:2154 [inline]
    __se_sys_sendto net/socket.c:2150 [inline]
    __x64_sys_sendto+0xe1/0x1b0 net/socket.c:2150
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7f123aaa1039
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007ffc15d12058 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f123aaa1039
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
    RBP: 0000000000000000 R08: 0000000020000040 R09: 0000000000000014
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f123aa648c0
    R13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000
    
    Fixes: 1baf5ebf8954 ("erspan: auto detect truncated packets.")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
firmware: arm_scmi: Fix device node validation for mailbox transport [+ + +]
Author: Cristian Marussi <[email protected]>
Date:   Tue Mar 7 16:23:24 2023 +0000

    firmware: arm_scmi: Fix device node validation for mailbox transport
    
    commit 2ab4f4018cb6b8010ca5002c3bdc37783b5d28c2 upstream.
    
    When mailboxes are used as a transport it is possible to setup the SCMI
    transport layer, depending on the underlying channels configuration, to use
    one or two mailboxes, associated, respectively, to one or two, distinct,
    shared memory areas: any other combination should be treated as invalid.
    
    Add more strict checking of SCMI mailbox transport device node descriptors.
    
    Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type")
    Cc: <[email protected]> # 4.19
    Signed-off-by: Cristian Marussi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sudeep Holla <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fscrypt: destroy keyring after security_sb_delete() [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Mon Mar 13 15:12:29 2023 -0700

    fscrypt: destroy keyring after security_sb_delete()
    
    commit ccb820dc7d2236b1af0d54ae038a27b5b6d5ae5a upstream.
    
    fscrypt_destroy_keyring() must be called after all potentially-encrypted
    inodes were evicted; otherwise it cannot safely destroy the keyring.
    Since inodes that are in-use by the Landlock LSM don't get evicted until
    security_sb_delete(), this means that fscrypt_destroy_keyring() must be
    called *after* security_sb_delete().
    
    This fixes a WARN_ON followed by a NULL dereference, only possible if
    Landlock was being used on encrypted files.
    
    Fixes: d7e7b9af104c ("fscrypt: stop using keyrings subsystem for fscrypt_master_key")
    Cc: [email protected]
    Reported-by: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Christian Brauner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fsverity: Remove WQ_UNBOUND from fsverity read workqueue [+ + +]
Author: Nathan Huckleberry <[email protected]>
Date:   Fri Mar 10 11:33:25 2023 -0800

    fsverity: Remove WQ_UNBOUND from fsverity read workqueue
    
    commit f959325e6ac3f499450088b8d9c626d1177be160 upstream.
    
    WQ_UNBOUND causes significant scheduler latency on ARM64/Android.  This
    is problematic for latency sensitive workloads, like I/O
    post-processing.
    
    Removing WQ_UNBOUND gives a 96% reduction in fsverity workqueue related
    scheduler latency and improves app cold startup times by ~30ms.
    WQ_UNBOUND was also removed from the dm-verity workqueue for the same
    reason [1].
    
    This code was tested by running Android app startup benchmarks and
    measuring how long the fsverity workqueue spent in the runnable state.
    
    Before
    Total workqueue scheduler latency: 553800us
    After
    Total workqueue scheduler latency: 18962us
    
    [1]: https://lore.kernel.org/all/[email protected]/
    
    Signed-off-by: Nathan Huckleberry <[email protected]>
    Fixes: 8a1d0f9cacc9 ("fs-verity: add data verification hooks for ->readpages()")
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
gve: Cache link_speed value from device [+ + +]
Author: Joshua Washington <[email protected]>
Date:   Tue Mar 21 10:23:32 2023 -0700

    gve: Cache link_speed value from device
    
    [ Upstream commit 68c3e4fc8628b1487c965aabb29207249657eb5f ]
    
    The link speed is never changed for the uptime of a VM, and the current
    implementation sends an admin queue command for each call. Admin queue
    command invocations have nontrivial overhead (e.g., VM exits), which can
    be disruptive to users if triggered frequently. Our telemetry data shows
    that there are VMs that make frequent calls to this admin queue command.
    Caching the result of the original admin queue command would eliminate
    the need to send multiple admin queue commands on subsequent calls to
    retrieve link speed.
    
    Fixes: 7e074d5a76ca ("gve: Enable Link Speed Reporting in the driver.")
    Signed-off-by: Joshua Washington <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
HID: cp2112: Fix driver not registering GPIO IRQ chip as threaded [+ + +]
Author: Danny Kaehn <[email protected]>
Date:   Fri Feb 10 11:00:44 2023 -0600

    HID: cp2112: Fix driver not registering GPIO IRQ chip as threaded
    
    [ Upstream commit 37f5b858a66543b2b67c0288280af623985abc29 ]
    
    The CP2112 generates interrupts from a polling routine on a thread,
    and can only support threaded interrupts. This patch configures the
    gpiochip irq chip with this flag, disallowing consumers to request
    a hard IRQ from this driver, which resulted in a segfault previously.
    
    Signed-off-by: Danny Kaehn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: intel-ish-hid: ipc: Fix potential use-after-free in work function [+ + +]
Author: Reka Norman <[email protected]>
Date:   Mon Feb 27 13:49:38 2023 +1100

    HID: intel-ish-hid: ipc: Fix potential use-after-free in work function
    
    [ Upstream commit 8ae2f2b0a28416ed2f6d8478ac8b9f7862f36785 ]
    
    When a reset notify IPC message is received, the ISR schedules a work
    function and passes the ISHTP device to it via a global pointer
    ishtp_dev. If ish_probe() fails, the devm-managed device resources
    including ishtp_dev are freed, but the work is not cancelled, causing a
    use-after-free when the work function tries to access ishtp_dev. Use
    devm_work_autocancel() instead, so that the work is automatically
    cancelled if probe fails.
    
    Signed-off-by: Reka Norman <[email protected]>
    Acked-by: Srinivas Pandruvada <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: logitech-hidpp: Add support for Logitech MX Master 3S mouse [+ + +]
Author: Rafał Szalecki <[email protected]>
Date:   Wed Mar 1 02:23:56 2023 +0100

    HID: logitech-hidpp: Add support for Logitech MX Master 3S mouse
    
    [ Upstream commit db50f7a3983f0154e730f1147ef729e0c5c2f90c ]
    
    Add signature for the Logitech MX Master 3S mouse over Bluetooth.
    
    Signed-off-by: Rafał Szalecki <[email protected]>
    Reviewed-by: Bastien Nocera <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hvc/xen: prevent concurrent accesses to the shared ring [+ + +]
Author: Roger Pau Monne <[email protected]>
Date:   Wed Nov 30 16:09:11 2022 +0100

    hvc/xen: prevent concurrent accesses to the shared ring
    
    [ Upstream commit 6214894f49a967c749ee6c07cb00f9cede748df4 ]
    
    The hvc machinery registers both a console and a tty device based on
    the hv ops provided by the specific implementation.  Those two
    interfaces however have different locks, and there's no single locks
    that's shared between the tty and the console implementations, hence
    the driver needs to protect itself against concurrent accesses.
    Otherwise concurrent calls using the split interfaces are likely to
    corrupt the ring indexes, leaving the console unusable.
    
    Introduce a lock to xencons_info to serialize accesses to the shared
    ring.  This is only required when using the shared memory console,
    concurrent accesses to the hypercall based console implementation are
    not an issue.
    
    Note the conditional logic in domU_read_console() is slightly modified
    so the notify_daemon() call can be done outside of the locked region:
    it's an hypercall and there's no need for it to be done with the lock
    held.
    
    Fixes: b536b4b96230 ('xen: use the hvc console infrastructure for Xen console')
    Signed-off-by: Roger Pau Monné <[email protected]>
    Reviewed-by: Juergen Gross <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hwmon (it87): Fix voltage scaling for chips with 10.9mV ADCs [+ + +]
Author: Frank Crawford <[email protected]>
Date:   Sat Mar 18 19:05:42 2023 +1100

    hwmon (it87): Fix voltage scaling for chips with 10.9mV ADCs
    
    [ Upstream commit 968b66ffeb7956acc72836a7797aeb7b2444ec51 ]
    
    Fix voltage scaling for chips that have 10.9mV ADCs, where scaling was
    not performed.
    
    Fixes: ead8080351c9 ("hwmon: (it87) Add support for IT8732F")
    Signed-off-by: Frank Crawford <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [groeck: Update subject and description to focus on bug fix]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hwmon: fix potential sensor registration fail if of_node is missing [+ + +]
Author: Phinex Hung <[email protected]>
Date:   Tue Mar 21 14:02:23 2023 +0800

    hwmon: fix potential sensor registration fail if of_node is missing
    
    [ Upstream commit 2315332efcbe7124252f080e03b57d3d2f1f4771 ]
    
    It is not sufficient to check of_node in current device.
    In some cases, this would cause the sensor registration to fail.
    
    This patch looks for device's ancestors to find a valid of_node if any.
    
    Fixes: d560168b5d0f ("hwmon: (core) New hwmon registration API")
    Signed-off-by: Phinex Hung <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
i2c: hisi: Only use the completion interrupt to finish the transfer [+ + +]
Author: Yicong Yang <[email protected]>
Date:   Mon Mar 13 15:45:52 2023 +0800

    i2c: hisi: Only use the completion interrupt to finish the transfer
    
    [ Upstream commit d98263512684a47e81bcb72a5408958ecd1e60b0 ]
    
    The controller will always generate a completion interrupt when the
    transfer is finished normally or not. Currently we use either error or
    completion interrupt to finish, this may result the completion
    interrupt unhandled and corrupt the next transfer, especially at low
    speed mode. Since on error case, the error interrupt will come first
    then is the completion interrupt. So only use the completion interrupt
    to finish the whole transfer process.
    
    Fixes: d62fbdb99a85 ("i2c: add support for HiSilicon I2C controller")
    Reported-by: Sheng Feng <[email protected]>
    Signed-off-by: Sheng Feng <[email protected]>
    Signed-off-by: Yicong Yang <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: imx-lpi2c: check only for enabled interrupt flags [+ + +]
Author: Alexander Stein <[email protected]>
Date:   Mon Jan 30 16:32:47 2023 +0100

    i2c: imx-lpi2c: check only for enabled interrupt flags
    
    [ Upstream commit 1c7885004567e8951d65a983be095f254dd20bef ]
    
    When reading from I2C, the Tx watermark is set to 0. Unfortunately the
    TDF (transmit data flag) is enabled when Tx FIFO entries is equal or less
    than watermark. So it is set in every case, hence the reset default of 1.
    This results in the MSR_RDF _and_ MSR_TDF flags to be set thus trying
    to send Tx data on a read message.
    Mask the IRQ status to filter for wanted flags only.
    
    Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver")
    Signed-off-by: Alexander Stein <[email protected]>
    Tested-by: Emanuele Ghidoli <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: mxs: ensure that DMA buffers are safe for DMA [+ + +]
Author: Matthias Schiffer <[email protected]>
Date:   Mon Feb 13 16:25:50 2023 +0100

    i2c: mxs: ensure that DMA buffers are safe for DMA
    
    [ Upstream commit 5190417bdf72c71b65bd9892103c6186816a6e8b ]
    
    We found that after commit 9c46929e7989
    ("ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems"), the
    PCF85063 RTC driver stopped working on i.MX28 due to regmap_bulk_read()
    reading bogus data into a stack buffer. This is caused by the i2c-mxs
    driver using DMA transfers even for messages without the I2C_M_DMA_SAFE
    flag, and the aforementioned commit enabling vmapped stacks.
    
    As the MXS I2C controller requires DMA for reads of >4 bytes, DMA can't be
    disabled, so the issue is fixed by using i2c_get_dma_safe_msg_buf() to
    create a bounce buffer when needed.
    
    Fixes: 9c46929e7989 ("ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems")
    Signed-off-by: Matthias Schiffer <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer() [+ + +]
Author: Wei Chen <[email protected]>
Date:   Tue Mar 14 16:54:21 2023 +0000

    i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()
    
    commit 92fbb6d1296f81f41f65effd7f5f8c0f74943d15 upstream.
    
    The data->block[0] variable comes from user and is a number between
    0-255. Without proper check, the variable may be very large to cause
    an out-of-bounds when performing memcpy in slimpro_i2c_blkwr.
    
    Fix this bug by checking the value of writelen.
    
    Fixes: f6505fbabc42 ("i2c: add SLIMpro I2C device driver on APM X-Gene platform")
    Signed-off-by: Wei Chen <[email protected]>
    Cc: [email protected]
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i40e: fix flow director packet filter programming [+ + +]
Author: Radoslaw Tyl <[email protected]>
Date:   Mon Mar 13 15:07:33 2023 +0100

    i40e: fix flow director packet filter programming
    
    [ Upstream commit c672297bbc0e86dbf88396b8053e2fbb173f16ff ]
    
    Initialize to zero structures to build a valid
    Tx Packet used for the filter programming.
    
    Fixes: a9219b332f52 ("i40e: VLAN field for flow director")
    Signed-off-by: Radoslaw Tyl <[email protected]>
    Reviewed-by: Michal Swiatkowski <[email protected]>
    Tested-by: Arpana Arland <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iavf: do not track VLAN 0 filters [+ + +]
Author: Ahmed Zaki <[email protected]>
Date:   Wed Mar 15 13:59:25 2023 -0600

    iavf: do not track VLAN 0 filters
    
    [ Upstream commit 964290ff32d132bf971d45b29f7de39756dab7c8 ]
    
    When an interface with the maximum number of VLAN filters is brought up,
    a spurious error is logged:
    
        [257.483082] 8021q: adding VLAN 0 to HW filter on device enp0s3
        [257.483094] iavf 0000:00:03.0 enp0s3: Max allowed VLAN filters 8. Remove existing VLANs or disable filtering via Ethtool if supported.
    
    The VF driver complains that it cannot add the VLAN 0 filter.
    
    On the other hand, the PF driver always adds VLAN 0 filter on VF
    initialization. The VF does not need to ask the PF for that filter at
    all.
    
    Fix the error by not tracking VLAN 0 filters altogether. With that, the
    check added by commit 0e710a3ffd0c ("iavf: Fix VF driver counting VLAN 0
    filters") in iavf_virtchnl.c is useless and might be confusing if left as
    it suggests that we track VLAN 0.
    
    Fixes: 0e710a3ffd0c ("iavf: Fix VF driver counting VLAN 0 filters")
    Signed-off-by: Ahmed Zaki <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iavf: fix hang on reboot with ice [+ + +]
Author: Stefan Assmann <[email protected]>
Date:   Mon Mar 13 17:06:45 2023 +0100

    iavf: fix hang on reboot with ice
    
    [ Upstream commit 4e264be98b88a6d6f476c11087fe865696e8bef5 ]
    
    When a system with E810 with existing VFs gets rebooted the following
    hang may be observed.
    
     Pid 1 is hung in iavf_remove(), part of a network driver:
     PID: 1        TASK: ffff965400e5a340  CPU: 24   COMMAND: "systemd-shutdow"
      #0 [ffffaad04005fa50] __schedule at ffffffff8b3239cb
      #1 [ffffaad04005fae8] schedule at ffffffff8b323e2d
      #2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc
      #3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930
      #4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf]
      #5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513
      #6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa
      #7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc
      #8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e
      #9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429
     #10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4
     #11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice]
     #12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice]
     #13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice]
     #14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1
     #15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386
     #16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870
     #17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6
     #18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159
     #19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc
     #20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d
     #21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169
     #22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b
         RIP: 00007f1baa5c13d7  RSP: 00007fffbcc55a98  RFLAGS: 00000202
         RAX: ffffffffffffffda  RBX: 0000000000000000  RCX: 00007f1baa5c13d7
         RDX: 0000000001234567  RSI: 0000000028121969  RDI: 00000000fee1dead
         RBP: 00007fffbcc55ca0   R8: 0000000000000000   R9: 00007fffbcc54e90
         R10: 00007fffbcc55050  R11: 0000000000000202  R12: 0000000000000005
         R13: 0000000000000000  R14: 00007fffbcc55af0  R15: 0000000000000000
         ORIG_RAX: 00000000000000a9  CS: 0033  SS: 002b
    
    During reboot all drivers PM shutdown callbacks are invoked.
    In iavf_shutdown() the adapter state is changed to __IAVF_REMOVE.
    In ice_shutdown() the call chain above is executed, which at some point
    calls iavf_remove(). However iavf_remove() expects the VF to be in one
    of the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If
    that's not the case it sleeps forever.
    So if iavf_shutdown() gets invoked before iavf_remove() the system will
    hang indefinitely because the adapter is already in state __IAVF_REMOVE.
    
    Fix this by returning from iavf_remove() if the state is __IAVF_REMOVE,
    as we already went through iavf_shutdown().
    
    Fixes: 974578017fc1 ("iavf: Add waiting so the port is initialized in remove")
    Fixes: a8417330f8a5 ("iavf: Fix race condition between iavf_shutdown and iavf_remove")
    Reported-by: Marius Cornea <[email protected]>
    Signed-off-by: Stefan Assmann <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iavf: fix inverted Rx hash condition leading to disabled hash [+ + +]
Author: Alexander Lobakin <[email protected]>
Date:   Wed Mar 1 12:59:07 2023 +0100

    iavf: fix inverted Rx hash condition leading to disabled hash
    
    [ Upstream commit 32d57f667f871bc5a8babbe27ea4c5e668ee0ea8 ]
    
    Condition, which checks whether the netdev has hashing enabled is
    inverted. Basically, the tagged commit effectively disabled passing flow
    hash from descriptor to skb, unless user *disables* it via Ethtool.
    Commit a876c3ba59a6 ("i40e/i40evf: properly report Rx packet hash")
    fixed this problem, but only for i40e.
    Invert the condition now in iavf and unblock passing hash to skbs again.
    
    Fixes: 857942fd1aa1 ("i40e: Fix Rx hash reported to the stack by our driver")
    Reviewed-by: Larysa Zaremba <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Signed-off-by: Alexander Lobakin <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iavf: fix non-tunneled IPv6 UDP packet type and hashing [+ + +]
Author: Alexander Lobakin <[email protected]>
Date:   Wed Mar 1 12:59:08 2023 +0100

    iavf: fix non-tunneled IPv6 UDP packet type and hashing
    
    [ Upstream commit de58647b4301fe181f9c38e8b46f7021584ae427 ]
    
    Currently, IAVF's decode_rx_desc_ptype() correctly reports payload type
    of L4 for IPv4 UDP packets and IPv{4,6} TCP, but only L3 for IPv6 UDP.
    Originally, i40e, ice and iavf were affected.
    Commit 73df8c9e3e3d ("i40e: Correct UDP packet header for non_tunnel-ipv6")
    fixed that in i40e, then
    commit 638a0c8c8861 ("ice: fix incorrect payload indicator on PTYPE")
    fixed that for ice.
    IPv6 UDP is L4 obviously. Fix it and make iavf report correct L4 hash
    type for such packets, so that the stack won't calculate it on CPU when
    needs it.
    
    Fixes: 206812b5fccb ("i40e/i40evf: i40e implementation for skb_set_hash")
    Reviewed-by: Larysa Zaremba <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Signed-off-by: Alexander Lobakin <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ice: check if VF exists before mode check [+ + +]
Author: Michal Swiatkowski <[email protected]>
Date:   Fri Mar 10 12:33:44 2023 +0100

    ice: check if VF exists before mode check
    
    [ Upstream commit 83b49e7f63da88a1544cba2b2e40bfabb24bd203 ]
    
    Setting trust on VF should return EINVAL when there is no VF. Move
    checking for switchdev mode after checking if VF exists.
    
    Fixes: c54d209c78b8 ("ice: Wait for VF to be reset/ready before configuration")
    Signed-off-by: Michal Swiatkowski <[email protected]>
    Signed-off-by: Kalyan Kodamagula <[email protected]>
    Tested-by: Sujai Buvaneswaran <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
igb: revert rtnl_lock() that causes deadlock [+ + +]
Author: Lin Ma <[email protected]>
Date:   Tue Mar 7 23:29:17 2023 +0800

    igb: revert rtnl_lock() that causes deadlock
    
    commit 65f69851e44d71248b952a687e44759a7abb5016 upstream.
    
    The commit 6faee3d4ee8b ("igb: Add lock to avoid data race") adds
    rtnl_lock to eliminate a false data race shown below
    
     (FREE from device detaching)      |   (USE from netdev core)
    igb_remove                         |  igb_ndo_get_vf_config
     igb_disable_sriov                 |  vf >= adapter->vfs_allocated_count?
      kfree(adapter->vf_data)          |
      adapter->vfs_allocated_count = 0 |
                                       |    memcpy(... adapter->vf_data[vf]
    
    The above race will never happen and the extra rtnl_lock causes deadlock
    below
    
    [  141.420169]  <TASK>
    [  141.420672]  __schedule+0x2dd/0x840
    [  141.421427]  schedule+0x50/0xc0
    [  141.422041]  schedule_preempt_disabled+0x11/0x20
    [  141.422678]  __mutex_lock.isra.13+0x431/0x6b0
    [  141.423324]  unregister_netdev+0xe/0x20
    [  141.423578]  igbvf_remove+0x45/0xe0 [igbvf]
    [  141.423791]  pci_device_remove+0x36/0xb0
    [  141.423990]  device_release_driver_internal+0xc1/0x160
    [  141.424270]  pci_stop_bus_device+0x6d/0x90
    [  141.424507]  pci_stop_and_remove_bus_device+0xe/0x20
    [  141.424789]  pci_iov_remove_virtfn+0xba/0x120
    [  141.425452]  sriov_disable+0x2f/0xf0
    [  141.425679]  igb_disable_sriov+0x4e/0x100 [igb]
    [  141.426353]  igb_remove+0xa0/0x130 [igb]
    [  141.426599]  pci_device_remove+0x36/0xb0
    [  141.426796]  device_release_driver_internal+0xc1/0x160
    [  141.427060]  driver_detach+0x44/0x90
    [  141.427253]  bus_remove_driver+0x55/0xe0
    [  141.427477]  pci_unregister_driver+0x2a/0xa0
    [  141.428296]  __x64_sys_delete_module+0x141/0x2b0
    [  141.429126]  ? mntput_no_expire+0x4a/0x240
    [  141.429363]  ? syscall_trace_enter.isra.19+0x126/0x1a0
    [  141.429653]  do_syscall_64+0x5b/0x80
    [  141.429847]  ? exit_to_user_mode_prepare+0x14d/0x1c0
    [  141.430109]  ? syscall_exit_to_user_mode+0x12/0x30
    [  141.430849]  ? do_syscall_64+0x67/0x80
    [  141.431083]  ? syscall_exit_to_user_mode_prepare+0x183/0x1b0
    [  141.431770]  ? syscall_exit_to_user_mode+0x12/0x30
    [  141.432482]  ? do_syscall_64+0x67/0x80
    [  141.432714]  ? exc_page_fault+0x64/0x140
    [  141.432911]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    Since the igb_disable_sriov() will call pci_disable_sriov() before
    releasing any resources, the netdev core will synchronize the cleanup to
    avoid any races. This patch removes the useless rtnl_(un)lock to guarantee
    correctness.
    
    CC: [email protected]
    Fixes: 6faee3d4ee8b ("igb: Add lock to avoid data race")
    Reported-by: Corinna Vinschen <[email protected]>
    Link: https://lore.kernel.org/intel-wired-lan/[email protected]/
    Signed-off-by: Lin Ma <[email protected]>
    Tested-by: Corinna Vinschen <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
igbvf: Regard vf reset nack as success [+ + +]
Author: Akihiko Odaki <[email protected]>
Date:   Thu Dec 1 19:20:03 2022 +0900

    igbvf: Regard vf reset nack as success
    
    [ Upstream commit 02c83791ef969c6a8a150b4927193d0d0e50fb23 ]
    
    vf reset nack actually represents the reset operation itself is
    performed but no address is assigned. Therefore, e1000_reset_hw_vf
    should fill the "perm_addr" with the zero address and return success on
    such an occasion. This prevents its callers in netdev.c from saying PF
    still resetting, and instead allows them to correctly report that no
    address is assigned.
    
    Fixes: 6ddbc4cf1f4d ("igb: Indicate failure on vf reset for empty mac address")
    Signed-off-by: Akihiko Odaki <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Tested-by: Marek Szlosek <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
igc: fix the validation logic for taprio's gate list [+ + +]
Author: AKASHI Takahiro <[email protected]>
Date:   Tue Mar 7 15:45:31 2023 +0900

    igc: fix the validation logic for taprio's gate list
    
    [ Upstream commit 2b4cc3d3f4d8ec42961e98568a0afeee96a943ab ]
    
    The check introduced in the commit a5fd39464a40 ("igc: Lift TAPRIO schedule
    restriction") can detect a false positive error in some corner case.
    For instance,
        tc qdisc replace ... taprio num_tc 4
            ...
            sched-entry S 0x01 100000       # slot#1
            sched-entry S 0x03 100000       # slot#2
            sched-entry S 0x04 100000       # slot#3
            sched-entry S 0x08 200000       # slot#4
            flags 0x02                      # hardware offload
    
    Here the queue#0 (the first queue) is on at the slot#1 and #2,
    and off at the slot#3 and #4. Under the current logic, when the slot#4
    is examined, validate_schedule() returns *false* since the enablement
    count for the queue#0 is two and it is already off at the previous slot
    (i.e. #3). But this definition is truely correct.
    
    Let's fix the logic to enforce a strict validation for consecutively-opened
    slots.
    
    Fixes: a5fd39464a40 ("igc: Lift TAPRIO schedule restriction")
    Signed-off-by: AKASHI Takahiro <[email protected]>
    Reviewed-by: Kurt Kanzenbach <[email protected]>
    Acked-by: Vinicius Costa Gomes <[email protected]>
    Tested-by: Naama Meir <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
intel/igbvf: free irq on the error path in igbvf_request_msix() [+ + +]
Author: Gaosheng Cui <[email protected]>
Date:   Tue Nov 22 10:28:52 2022 +0800

    intel/igbvf: free irq on the error path in igbvf_request_msix()
    
    [ Upstream commit 85eb39bb39cbb5c086df1e19ba67cc1366693a77 ]
    
    In igbvf_request_msix(), irqs have not been freed on the err path,
    we need to free it. Fix it.
    
    Fixes: d4e0fe01a38a ("igbvf: add new driver to support 82576 virtual functions")
    Signed-off-by: Gaosheng Cui <[email protected]>
    Reviewed-by: Maciej Fijalkowski <[email protected]>
    Tested-by: Marek Szlosek <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
interconnect: qcom: osm-l3: fix icc_onecell_data allocation [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Thu Jan 5 02:22:19 2023 +0200

    interconnect: qcom: osm-l3: fix icc_onecell_data allocation
    
    [ Upstream commit f77ebdda0ee652124061c2ac42399bb6c367e729 ]
    
    This is a struct with a trailing zero-length array of icc_node pointers
    but it's allocated as if it were a single array of icc_nodes instead.
    
    Fortunately this overallocates memory rather then allocating less memory
    than required.
    
    Fix by replacing devm_kcalloc() with devm_kzalloc() and struct_size()
    macro.
    
    Fixes: 5bc9900addaf ("interconnect: qcom: Add OSM L3 interconnect provider support")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Georgi Djakov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
interconnect: qcom: qcm2290: Fix MASTER_SNOC_BIMC_NRT [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Tue Jan 3 15:21:20 2023 +0100

    interconnect: qcom: qcm2290: Fix MASTER_SNOC_BIMC_NRT
    
    [ Upstream commit 633a12fda6536a1a17bcea29502e777e86a4547e ]
    
    Due to what seems to be a copy-paste error, the _NRT master was
    identical to the _RT master, which should not be the case.. Fix it
    using the values available from the downstream kernel [1].
    
    [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/scuba-bus.dtsi#127
    Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support")
    Signed-off-by: Konrad Dybcio <[email protected]>
    Acked-by: Shawn Guo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Georgi Djakov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

interconnect: qcom: sm8450: switch to qcom_icc_rpmh_* function [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Thu Jan 5 02:22:20 2023 +0200

    interconnect: qcom: sm8450: switch to qcom_icc_rpmh_* function
    
    [ Upstream commit 87e8fab1917a2b3f6e3dedfd1cdf22a1416e6676 ]
    
    Change sm8450 interconnect driver to use generic qcom_icc_rpmh_*
    functions rather than embedding a copy of thema. This also fixes an
    overallocation of memory for icc_onecell_data structure.
    
    Fixes: fafc114a468e ("interconnect: qcom: Add SM8450 interconnect provider driver")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Georgi Djakov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring/net: avoid sending -ECONNABORTED on repeated connection requests [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Mon Mar 20 11:13:49 2023 -0600

    io_uring/net: avoid sending -ECONNABORTED on repeated connection requests
    
    commit 74e2e17ee1f8d8a0928b90434ad7e2df70f8483e upstream.
    
    Since io_uring does nonblocking connect requests, if we do two repeated
    ones without having a listener, the second will get -ECONNABORTED rather
    than the expected -ECONNREFUSED. Treat -ECONNABORTED like a normal retry
    condition if we're nonblocking, if we haven't already seen it.
    
    Cc: [email protected]
    Fixes: 3fb1bd688172 ("io_uring/net: handle -EINPROGRESS correct for IORING_OP_CONNECT")
    Link: https://github.com/axboe/liburing/issues/828
    Reported-by: Hui, Chunyang <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
io_uring/rsrc: fix null-ptr-deref in io_file_bitmap_get() [+ + +]
Author: Savino Dicanosa <[email protected]>
Date:   Tue Mar 21 19:44:02 2023 +0000

    io_uring/rsrc: fix null-ptr-deref in io_file_bitmap_get()
    
    commit 02a4d923e4400a36d340ea12d8058f69ebf3a383 upstream.
    
    When fixed files are unregistered, file_alloc_end and alloc_hint
    are not cleared. This can later cause a NULL pointer dereference in
    io_file_bitmap_get() if auto index selection is enabled via
    IORING_FILE_INDEX_ALLOC:
    
    [    6.519129] BUG: kernel NULL pointer dereference, address: 0000000000000000
    [...]
    [    6.541468] RIP: 0010:_find_next_zero_bit+0x1a/0x70
    [...]
    [    6.560906] Call Trace:
    [    6.561322]  <TASK>
    [    6.561672]  io_file_bitmap_get+0x38/0x60
    [    6.562281]  io_fixed_fd_install+0x63/0xb0
    [    6.562851]  ? __pfx_io_socket+0x10/0x10
    [    6.563396]  io_socket+0x93/0xf0
    [    6.563855]  ? __pfx_io_socket+0x10/0x10
    [    6.564411]  io_issue_sqe+0x5b/0x3d0
    [    6.564914]  io_submit_sqes+0x1de/0x650
    [    6.565452]  __do_sys_io_uring_enter+0x4fc/0xb20
    [    6.566083]  ? __do_sys_io_uring_register+0x11e/0xd80
    [    6.566779]  do_syscall_64+0x3c/0x90
    [    6.567247]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
    [...]
    
    To fix the issue, set file alloc range and alloc_hint to zero after
    file tables are freed.
    
    Cc: [email protected]
    Fixes: 4278a0deb1f6 ("io_uring: defer alloc_hint update to io_file_bitmap_set()")
    Signed-off-by: Savino Dicanosa <[email protected]>
    [axboe: add explicit bitmap == NULL check as well]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
kcsan: avoid passing -g for test [+ + +]
Author: Marco Elver <[email protected]>
Date:   Thu Mar 16 23:47:05 2023 +0100

    kcsan: avoid passing -g for test
    
    commit 5eb39cde1e2487ba5ec1802dc5e58a77e700d99e upstream.
    
    Nathan reported that when building with GNU as and a version of clang that
    defaults to DWARF5, the assembler will complain with:
    
      Error: non-constant .uleb128 is not supported
    
    This is because `-g` defaults to the compiler debug info default. If the
    assembler does not support some of the directives used, the above errors
    occur. To fix, remove the explicit passing of `-g`.
    
    All the test wants is that stack traces print valid function names, and
    debug info is not required for that. (I currently cannot recall why I
    added the explicit `-g`.)
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 1fe84fd4a402 ("kcsan: Add test suite")
    Signed-off-by: Marco Elver <[email protected]>
    Reported-by: Nathan Chancellor <[email protected]>
    Cc: Alexander Potapenko <[email protected]>
    Cc: Dmitry Vyukov <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
keys: Do not cache key in task struct if key is requested from kernel thread [+ + +]
Author: David Howells <[email protected]>
Date:   Tue Mar 14 15:15:18 2023 +0000

    keys: Do not cache key in task struct if key is requested from kernel thread
    
    [ Upstream commit 47f9e4c924025c5be87959d3335e66fcbb7f6b5c ]
    
    The key which gets cached in task structure from a kernel thread does not
    get invalidated even after expiry.  Due to which, a new key request from
    kernel thread will be served with the cached key if it's present in task
    struct irrespective of the key validity.  The change is to not cache key in
    task_struct when key requested from kernel thread so that kernel thread
    gets a valid key on every key request.
    
    The problem has been seen with the cifs module doing DNS lookups from a
    kernel thread and the results getting pinned by being attached to that
    kernel thread's cache - and thus not something that can be easily got rid
    of.  The cache would ordinarily be cleared by notify-resume, but kernel
    threads don't do that.
    
    This isn't seen with AFS because AFS is doing request_key() within the
    kernel half of a user thread - which will do notify-resume.
    
    Fixes: 7743c48e54ee ("keys: Cache result of request_key*() temporarily in task_struct")
    Signed-off-by: Bharath SM <[email protected]>
    Signed-off-by: David Howells <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    cc: Shyam Prasad N <[email protected]>
    cc: Steve French <[email protected]>
    cc: [email protected]
    cc: [email protected]
    cc: [email protected]
    Link: https://lore.kernel.org/r/CAGypqWw951d=zYRbdgNR4snUDvJhWL=q3=WOyh7HhSJupjz2vA@mail.gmail.com/
    Signed-off-by: Sasha Levin <[email protected]>

 
kfence: avoid passing -g for test [+ + +]
Author: Marco Elver <[email protected]>
Date:   Thu Mar 16 23:47:04 2023 +0100

    kfence: avoid passing -g for test
    
    commit 2e08ca1802441224f5b7cc6bffbb687f7406de95 upstream.
    
    Nathan reported that when building with GNU as and a version of clang that
    defaults to DWARF5:
    
      $ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- \
                            LLVM=1 LLVM_IAS=0 O=build \
                            mrproper allmodconfig mm/kfence/kfence_test.o
      /tmp/kfence_test-08a0a0.s: Assembler messages:
      /tmp/kfence_test-08a0a0.s:14627: Error: non-constant .uleb128 is not supported
      /tmp/kfence_test-08a0a0.s:14628: Error: non-constant .uleb128 is not supported
      /tmp/kfence_test-08a0a0.s:14632: Error: non-constant .uleb128 is not supported
      /tmp/kfence_test-08a0a0.s:14633: Error: non-constant .uleb128 is not supported
      /tmp/kfence_test-08a0a0.s:14639: Error: non-constant .uleb128 is not supported
      ...
    
    This is because `-g` defaults to the compiler debug info default.  If the
    assembler does not support some of the directives used, the above errors
    occur.  To fix, remove the explicit passing of `-g`.
    
    All the test wants is that stack traces print valid function names, and
    debug info is not required for that.  (I currently cannot recall why I
    added the explicit `-g`.)
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: bc8fbc5f305a ("kfence: add test suite")
    Signed-off-by: Marco Elver <[email protected]>
    Reported-by: Nathan Chancellor <[email protected]>
    Cc: Alexander Potapenko <[email protected]>
    Cc: Dmitry Vyukov <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ksmbd: add low bound validation to FSCTL_QUERY_ALLOCATED_RANGES [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Tue Mar 7 21:56:07 2023 +0900

    ksmbd: add low bound validation to FSCTL_QUERY_ALLOCATED_RANGES
    
    [ Upstream commit 342edb60dcda7a409430359b0cac2864bb9dfe44 ]
    
    Smatch static checker warning:
     fs/ksmbd/vfs.c:1040 ksmbd_vfs_fqar_lseek() warn: no lower bound on 'length'
     fs/ksmbd/vfs.c:1041 ksmbd_vfs_fqar_lseek() warn: no lower bound on 'start'
    
    Fix unexpected result that could caused from negative start and length.
    
    Fixes: f44158485826 ("cifsd: add file operations")
    Reported-by: Dan Carpenter <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Reviewed-by: Sergey Senozhatsky <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ksmbd: add low bound validation to FSCTL_SET_ZERO_DATA [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Sun Mar 5 21:04:00 2023 +0900

    ksmbd: add low bound validation to FSCTL_SET_ZERO_DATA
    
    [ Upstream commit 2d74ec97131b1179a373b6d521f195c84e894eb6 ]
    
    Smatch static checker warning:
     fs/ksmbd/smb2pdu.c:7759 smb2_ioctl()
     warn: no lower bound on 'off'
    
    Fix unexpected result that could caused from negative off and bfz.
    
    Fixes: b5e5f9dfc915 ("ksmbd: check invalid FileOffset and BeyondFinalZero in FSCTL_ZERO_DATA")
    Reported-by: Dan Carpenter <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Reviewed-by: Sergey Senozhatsky <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ksmbd: don't terminate inactive sessions after a few seconds [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Tue Mar 21 15:25:34 2023 +0900

    ksmbd: don't terminate inactive sessions after a few seconds
    
    commit be6f42fad5f5fd1fea9d562df82c38ad6ed3bfe9 upstream.
    
    Steve reported that inactive sessions are terminated after a few
    seconds. ksmbd terminate when receiving -EAGAIN error from
    kernel_recvmsg(). -EAGAIN means there is no data available in timeout.
    So ksmbd should keep connection with unlimited retries instead of
    terminating inactive sessions.
    
    Cc: [email protected]
    Reported-by: Steve French <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: fix possible refcount leak in smb2_open() [+ + +]
Author: ChenXiaoSong <[email protected]>
Date:   Thu Mar 2 21:58:04 2023 +0800

    ksmbd: fix possible refcount leak in smb2_open()
    
    [ Upstream commit 2624b445544ffc1472ccabfb6ec867c199d4c95c ]
    
    Reference count of acls will leak when memory allocation fails. Fix this
    by adding the missing posix_acl_release().
    
    Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
    Signed-off-by: ChenXiaoSong <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ksmbd: fix wrong signingkey creation when encryption is AES256 [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Wed Mar 1 00:01:21 2023 +0900

    ksmbd: fix wrong signingkey creation when encryption is AES256
    
    commit 7a891d4b62d62566323676cb0e922ded4f37afe1 upstream.
    
    MacOS and Win11 support AES256 encrytion and it is included in the cipher
    array of encryption context. Especially on macOS, The most preferred
    cipher is AES256. Connecting to ksmbd fails on newer MacOS clients that
    support AES256 encryption. MacOS send disconnect request after receiving
    final session setup response from ksmbd. Because final session setup is
    signed with signing key was generated incorrectly.
    For signging key, 'L' value should be initialized to 128 if key size is
    16bytes.
    
    Cc: [email protected]
    Reported-by: Miao Lihua <[email protected]>
    Tested-by: Miao Lihua <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: return STATUS_NOT_SUPPORTED on unsupported smb2.0 dialect [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Tue Mar 21 15:36:40 2023 +0900

    ksmbd: return STATUS_NOT_SUPPORTED on unsupported smb2.0 dialect
    
    commit b53e8cfec30b93c120623232ba27c041b1ef8f1a upstream.
    
    ksmbd returned "Input/output error" when mounting with vers=2.0 to
    ksmbd. It should return STATUS_NOT_SUPPORTED on unsupported smb2.0
    dialect.
    
    Cc: [email protected]
    Reported-by: Steve French <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: return unsupported error on smb1 mount [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Thu Mar 23 21:15:52 2023 +0900

    ksmbd: return unsupported error on smb1 mount
    
    commit 39b291b86b5988bf8753c3874d5c773399d09b96 upstream.
    
    ksmbd disconnect connection when mounting with vers=smb1.
    ksmbd should send smb1 negotiate response to client for correct
    unsupported error return. This patch add needed SMB1 macros and fill
    NegProt part of the response for smb1 negotiate response.
    
    Cc: [email protected]
    Reported-by: Steve French <[email protected]>
    Reviewed-by: Sergey Senozhatsky <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: set FILE_NAMED_STREAMS attribute in FS_ATTRIBUTE_INFORMATION [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Wed Mar 1 00:02:30 2023 +0900

    ksmbd: set FILE_NAMED_STREAMS attribute in FS_ATTRIBUTE_INFORMATION
    
    commit 728f14c72b71a19623df329c1c7c9d1452e56f1e upstream.
    
    If vfs objects = streams_xattr in ksmbd.conf FILE_NAMED_STREAMS should
    be set to Attributes in FS_ATTRIBUTE_INFORMATION. MacOS client show
    "Format: SMB (Unknown)" on faked NTFS and no streams support.
    
    Cc: [email protected]
    Reported-by: Miao Lihua <[email protected]>
    Tested-by: Miao Lihua <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 6.2.9 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Mar 30 12:51:43 2023 +0200

    Linux 6.2.9
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Ronald Warsow <[email protected]>
    Tested-by: Markus Reichelt <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Bagas Sanjaya <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Chris Paterson (CIP) <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Conor Dooley <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
lockd: set file_lock start and end when decoding nlm4 testargs [+ + +]
Author: Jeff Layton <[email protected]>
Date:   Tue Mar 14 06:20:58 2023 -0400

    lockd: set file_lock start and end when decoding nlm4 testargs
    
    commit 7ff84910c66c9144cc0de9d9deed9fb84c03aff0 upstream.
    
    Commit 6930bcbfb6ce dropped the setting of the file_lock range when
    decoding a nlm_lock off the wire. This causes the client side grant
    callback to miss matching blocks and reject the lock, only to rerequest
    it 30s later.
    
    Add a helper function to set the file_lock range from the start and end
    values that the protocol uses, and have the nlm_lock decoder call that to
    set up the file_lock args properly.
    
    Fixes: 6930bcbfb6ce ("lockd: detect and reject lock arguments that overflow")
    Reported-by: Amir Goldstein <[email protected]>
    Signed-off-by: Jeff Layton <[email protected]>
    Tested-by: Amir Goldstein <[email protected]>
    Cc: [email protected] #6.0
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
m68k: mm: Fix systems with memory at end of 32-bit address space [+ + +]
Author: Kars de Jong <[email protected]>
Date:   Thu Feb 23 12:23:49 2023 +0100

    m68k: mm: Fix systems with memory at end of 32-bit address space
    
    [ Upstream commit 0d9fad91abfd723ea5070a46d98a9f4496c93ba9 ]
    
    The calculation of end addresses of memory chunks overflowed to 0 when
    a memory chunk is located at the end of 32-bit address space.
    This is the case for the HP300 architecture.
    
    Link: https://lore.kernel.org/linux-m68k/CACz-3rhUo5pgNwdWHaPWmz+30Qo9xCg70wNxdf7o5x-6tXq8QQ@mail.gmail.com/
    Signed-off-by: Kars de Jong <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

m68k: Only force 030 bus error if PC not in exception table [+ + +]
Author: Michael Schmitz <[email protected]>
Date:   Wed Mar 1 15:11:07 2023 +1300

    m68k: Only force 030 bus error if PC not in exception table
    
    [ Upstream commit e36a82bebbf7da814530d5a179bef9df5934b717 ]
    
    __get_kernel_nofault() does copy data in supervisor mode when
    forcing a task backtrace log through /proc/sysrq_trigger.
    This is expected cause a bus error exception on e.g. NULL
    pointer dereferencing when logging a kernel task has no
    workqueue associated. This bus error ought to be ignored.
    
    Our 030 bus error handler is ill equipped to deal with this:
    
    Whenever ssw indicates a kernel mode access on a data fault,
    we don't even attempt to handle the fault and instead always
    send a SEGV signal (or panic). As a result, the check
    for exception handling at the fault PC (buried in
    send_sig_fault() which gets called from do_page_fault()
    eventually) is never used.
    
    In contrast, both 040 and 060 access error handlers do not
    care whether a fault happened on supervisor mode access,
    and will call do_page_fault() on those, ultimately honoring
    the exception table.
    
    Add a check in bus_error030 to call do_page_fault() in case
    we do have an entry for the fault PC in our exception table.
    
    I had attempted a fix for this earlier in 2019 that did rely
    on testing pagefault_disabled() (see link below) to achieve
    the same thing, but this patch should be more generic.
    
    Tested on 030 Atari Falcon.
    
    Reported-by: Eero Tamminen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Michael Schmitz <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
maple_tree: fix mas_skip_node() end slot detection [+ + +]
Author: Liam R. Howlett <[email protected]>
Date:   Tue Mar 7 13:02:46 2023 -0500

    maple_tree: fix mas_skip_node() end slot detection
    
    commit 0fa99fdfe1b38da396d0b2d1496a823bcd0ebea0 upstream.
    
    Patch series "Fix mas_skip_node() for mas_empty_area()", v2.
    
    mas_empty_area() was incorrectly returning an error when there was room.
    The issue was tracked down to mas_skip_node() using the incorrect
    end-of-slot count.  Instead of using the nodes hard limit, the limit of
    data should be used.
    
    mas_skip_node() was also setting the min and max to that of the child
    node, which was unnecessary.  Within these limits being set, there was
    also a bug that corrupted the maple state's max if the offset was set to
    the maximum node pivot.  The bug was without consequence unless there was
    a sufficient gap in the next child node which would cause an error to be
    returned.
    
    This patch set fixes these errors by removing the limit setting from
    mas_skip_node() and uses the mas_data_end() for slot limits, and adds
    tests for all failures discovered.
    
    
    This patch (of 2):
    
    mas_skip_node() is used to move the maple state to the node with a higher
    limit.  It does this by walking up the tree and increasing the slot count.
    Since slot count may not be able to be increased, it may need to walk up
    multiple times to find room to walk right to a higher limit node.  The
    limit of slots that was being used was the node limit and not the last
    location of data in the node.  This would cause the maple state to be
    shifted outside actual data and enter an error state, thus returning
    -EBUSY.
    
    The result of the incorrect error state means that mas_awalk() would
    return an error instead of finding the allocation space.
    
    The fix is to use mas_data_end() in mas_skip_node() to detect the nodes
    data end point and continue walking the tree up until it is safe to move
    to a node with a higher limit.
    
    The walk up the tree also sets the maple state limits so remove the buggy
    code from mas_skip_node().  Setting the limits had the unfortunate side
    effect of triggering another bug if the parent node was full and the there
    was no suitable gap in the second last child, but room in the next child.
    
    mas_skip_node() may also be passed a maple state in an error state from
    mas_anode_descend() when no allocations are available.  Return on such an
    error state immediately.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 54a611b60590 ("Maple Tree: add new data structure")
    Signed-off-by: Liam R. Howlett <[email protected]>
    Reported-by: Snild Dolkow <[email protected]>
      Link: https://lore.kernel.org/linux-mm/[email protected]/
    Tested-by: Snild Dolkow <[email protected]>
    Cc: Peng Zhang <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mlxsw: core_thermal: Fix fan speed in maximum cooling state [+ + +]
Author: Ido Schimmel <[email protected]>
Date:   Fri Mar 17 16:32:59 2023 +0100

    mlxsw: core_thermal: Fix fan speed in maximum cooling state
    
    [ Upstream commit 6d206b1ea9f48433a96edec7028586db1d947911 ]
    
    The cooling levels array is supposed to prevent the system fans from
    being configured below a 20% duty cycle as otherwise some of them get
    stuck at 0 RPM.
    
    Due to an off-by-one error, the last element in the array was not
    initialized, causing it to be set to zero, which in turn lead to fans
    being configured with a 0% duty cycle in maximum cooling state.
    
    Since commit 332fdf951df8 ("mlxsw: thermal: Fix out-of-bounds memory
    accesses") the contents of the array are static. Therefore, instead of
    fixing the initialization of the array, simply remove it and adjust
    thermal_cooling_device_ops::set_cur_state() so that the configured duty
    cycle is never set below 20%.
    
    Before:
    
     # cat /sys/class/thermal/thermal_zone0/cdev0/type
     mlxsw_fan
     # echo 10 > /sys/class/thermal/thermal_zone0/cdev0/cur_state
     # cat /sys/class/hwmon/hwmon0/name
     mlxsw
     # cat /sys/class/hwmon/hwmon0/pwm1
     0
    
    After:
    
     # cat /sys/class/thermal/thermal_zone0/cdev0/type
     mlxsw_fan
     # echo 10 > /sys/class/thermal/thermal_zone0/cdev0/cur_state
     # cat /sys/class/hwmon/hwmon0/name
     mlxsw
     # cat /sys/class/hwmon/hwmon0/pwm1
     255
    
    This bug was uncovered when the thermal subsystem repeatedly tried to
    configure the cooling devices to their maximum state due to another
    issue [1]. This resulted in the fans being stuck at 0 RPM, which
    eventually lead to the system undergoing thermal shutdown.
    
    [1] https://lore.kernel.org/netdev/ZA3CFNhU4AbtsP4G@shredder/
    
    Fixes: a421ce088ac8 ("mlxsw: core: Extend cooling device with cooling levels")
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Vadim Pasternak <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mlxsw: spectrum_fid: Fix incorrect local port type [+ + +]
Author: Ido Schimmel <[email protected]>
Date:   Tue Mar 21 12:42:00 2023 +0100

    mlxsw: spectrum_fid: Fix incorrect local port type
    
    [ Upstream commit bb765a743377d46d8da8e7f7e5128022504741b9 ]
    
    Local port is a 10-bit number, but it was mistakenly stored in a u8,
    resulting in firmware errors when using a netdev corresponding to a
    local port higher than 255.
    
    Fix by storing the local port in u16, as is done in the rest of the
    code.
    
    Fixes: bf73904f5fba ("mlxsw: Add support for 802.1Q FID family")
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Danielle Ratson <[email protected]>
    Signed-off-by: Petr Machata <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/eace1f9d96545ab8a2775db857cb7e291a9b166b.1679398549.git.petrm@nvidia.com
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mm/ksm: fix race with VMA iteration and mm_struct teardown [+ + +]
Author: Liam R. Howlett <[email protected]>
Date:   Wed Mar 8 17:03:10 2023 -0500

    mm/ksm: fix race with VMA iteration and mm_struct teardown
    
    commit 6db504ce55bdbc575723938fc480713c9183f6a2 upstream.
    
    exit_mmap() will tear down the VMAs and maple tree with the mmap_lock held
    in write mode.  Ensure that the maple tree is still valid by checking
    ksm_test_exit() after taking the mmap_lock in read mode, but before the
    for_each_vma() iterator dereferences a destroyed maple tree.
    
    Since the maple tree is destroyed, the flags telling lockdep to check an
    external lock has been cleared.  Skip the for_each_vma() iterator to avoid
    dereferencing a maple tree without the external lock flag, which would
    create a lockdep warning.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: a5f18ba07276 ("mm/ksm: use vma iterators instead of vma linked list")
    Signed-off-by: Liam R. Howlett <[email protected]>
    Reported-by: Pengfei Xu <[email protected]>
      Link: https://lore.kernel.org/lkml/[email protected]/
    Reported-by: [email protected]
      Link: https://syzkaller.appspot.com/bug?id=64a3e95957cd3deab99df7cd7b5a9475af92c93e
    Acked-by: David Hildenbrand <[email protected]>
    Cc: Matthew Wilcox (Oracle) <[email protected]>
    Cc: <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/slab: Fix undefined init_cache_node_node() for NUMA and !SMP [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Mar 21 09:30:59 2023 +0100

    mm/slab: Fix undefined init_cache_node_node() for NUMA and !SMP
    
    commit 66a1c22b709178e7b823d44465d0c2e5ed7492fb upstream.
    
    sh/migor_defconfig:
    
        mm/slab.c: In function ‘slab_memory_callback’:
        mm/slab.c:1127:23: error: implicit declaration of function ‘init_cache_node_node’; did you mean ‘drain_cache_node_node’? [-Werror=implicit-function-declaration]
         1127 |                 ret = init_cache_node_node(nid);
              |                       ^~~~~~~~~~~~~~~~~~~~
              |                       drain_cache_node_node
    
    The #ifdef condition protecting the definition of init_cache_node_node()
    no longer matches the conditions protecting the (multiple) users.
    
    Fix this by syncing the conditions.
    
    Fixes: 76af6a054da40553 ("mm/migrate: add CPU hotplug to demotion #ifdef")
    Reported-by: Randy Dunlap <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
    Acked-by: Randy Dunlap <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Vlastimil Babka <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm: kfence: fix using kfence_metadata without initialization in show_object() [+ + +]
Author: Muchun Song <[email protected]>
Date:   Wed Mar 15 11:44:41 2023 +0800

    mm: kfence: fix using kfence_metadata without initialization in show_object()
    
    commit 1c86a188e03156223a34d09ce290b49bd4dd0403 upstream.
    
    The variable kfence_metadata is initialized in kfence_init_pool(), then,
    it is not initialized if kfence is disabled after booting.  In this case,
    kfence_metadata will be used (e.g.  ->lock and ->state fields) without
    initialization when reading /sys/kernel/debug/kfence/objects.  There will
    be a warning if you enable CONFIG_DEBUG_SPINLOCK.  Fix it by creating
    debugfs files when necessary.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure")
    Signed-off-by: Muchun Song <[email protected]>
    Tested-by: Marco Elver <[email protected]>
    Reviewed-by: Marco Elver <[email protected]>
    Cc: Alexander Potapenko <[email protected]>
    Cc: Dmitry Vyukov <[email protected]>
    Cc: Jann Horn <[email protected]>
    Cc: SeongJae Park <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net/mlx5: E-Switch, Fix an Oops in error handling code [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Feb 27 14:16:10 2023 +0300

    net/mlx5: E-Switch, Fix an Oops in error handling code
    
    [ Upstream commit 640fcdbcf27fc62de9223f958ceb4e897a00e791 ]
    
    The error handling dereferences "vport".  There is nothing we can do if
    it is an error pointer except returning the error code.
    
    Fixes: 133dcfc577ea ("net/mlx5: E-Switch, Alloc and free unique metadata for match")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Roi Dayan <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: Fix steering rules cleanup [+ + +]
Author: Lama Kayal <[email protected]>
Date:   Tue Jan 31 14:07:03 2023 +0200

    net/mlx5: Fix steering rules cleanup
    
    [ Upstream commit 922f56e9a795d6f3dd72d3428ebdd7ee040fa855 ]
    
    vport's mc, uc and multicast rules are not deleted in teardown path when
    EEH happens. Since the vport's promisc settings(uc, mc and all) in
    firmware are reset after EEH, mlx5 driver will try to delete the above
    rules in the initialization path. This cause kernel crash because these
    software rules are no longer valid.
    
    Fix by nullifying these rules right after delete to avoid accessing any dangling
    pointers.
    
    Call Trace:
    __list_del_entry_valid+0xcc/0x100 (unreliable)
    tree_put_node+0xf4/0x1b0 [mlx5_core]
    tree_remove_node+0x30/0x70 [mlx5_core]
    mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core]
    esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core]
    esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core]
    esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core]
    esw_enable_vport+0x130/0x260 [mlx5_core]
    mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core]
    mlx5_device_enable_sriov+0x74/0x440 [mlx5_core]
    mlx5_load_one+0x114c/0x1550 [mlx5_core]
    mlx5_pci_resume+0x68/0xf0 [mlx5_core]
    eeh_report_resume+0x1a4/0x230
    eeh_pe_dev_traverse+0x98/0x170
    eeh_handle_normal_event+0x3e4/0x640
    eeh_handle_event+0x4c/0x370
    eeh_event_handler+0x14c/0x210
    kthread+0x168/0x1b0
    ret_from_kernel_thread+0x5c/0x84
    
    Fixes: a35f71f27a61 ("net/mlx5: E-Switch, Implement promiscuous rx modes vf request handling")
    Signed-off-by: Huy Nguyen <[email protected]>
    Signed-off-by: Lama Kayal <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Reviewed-by: Maor Dickman <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5: Read the TC mapping of all priorities on ETS query [+ + +]
Author: Maher Sanalla <[email protected]>
Date:   Wed Mar 15 11:04:38 2023 +0200

    net/mlx5: Read the TC mapping of all priorities on ETS query
    
    [ Upstream commit 44d553188c38ac74b799dfdcebafef2f7bb70942 ]
    
    When ETS configurations are queried by the user to get the mapping
    assignment between packet priority and traffic class, only priorities up
    to maximum TCs are queried from QTCT register in FW to retrieve their
    assigned TC, leaving the rest of the priorities mapped to the default
    TC #0 which might be misleading.
    
    Fix by querying the TC mapping of all priorities on each ETS query,
    regardless of the maximum number of TCs configured in FW.
    
    Fixes: 820c2c5e773d ("net/mlx5e: Read ETS settings directly from firmware")
    Signed-off-by: Maher Sanalla <[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/mlx5e: Block entering switchdev mode with ns inconsistency [+ + +]
Author: Gavin Li <[email protected]>
Date:   Thu Feb 9 12:48:52 2023 +0200

    net/mlx5e: Block entering switchdev mode with ns inconsistency
    
    [ Upstream commit 662404b24a4c4d839839ed25e3097571f5938b9b ]
    
    Upon entering switchdev mode, VF/SF representors are spawned in the
    devlink instance's net namespace, whereas the PF net device transforms
    into the uplink representor, remaining in the net namespace the PF net
    device was in. Therefore, if a PF net device's namespace is different from
    its parent devlink net namespace, entering switchdev mode can create an
    illegal situation where all representors sharing the same core device
    are NOT in the same net namespace.
    
    To avoid this issue, block entering switchdev mode for devices whose child
    netdev net namespace has diverged from the parent devlink's.
    
    Fixes: 7768d1971de6 ("net/mlx5: E-Switch, Add control for encapsulation")
    Signed-off-by: Gavin Li <[email protected]>
    Reviewed-by: Gavi Teitz <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5e: Overcome slow response for first macsec ASO WQE [+ + +]
Author: Emeel Hakim <[email protected]>
Date:   Mon Mar 20 13:13:55 2023 +0200

    net/mlx5e: Overcome slow response for first macsec ASO WQE
    
    [ Upstream commit 7e3fce82d945cf6e7f99034b113ff2d250d7524d ]
    
    First ASO WQE poll causes a cache miss in hardware hence the resut is
    delayed. It causes to the situation where such WQE is polled earlier
    than it is needed.
    
    Add logic to retry ASO CQ polling operation.
    
    Fixes: 739cfa34518e ("net/mlx5: Make ASO poll CQ usable in atomic context") 
    Signed-off-by: Emeel Hakim <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Reviewed-by: Raed Salem <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5e: Set uplink rep as NETNS_LOCAL [+ + +]
Author: Gavin Li <[email protected]>
Date:   Fri Nov 25 04:15:40 2022 +0200

    net/mlx5e: Set uplink rep as NETNS_LOCAL
    
    [ Upstream commit c83172b0639c8a005c0dd3b36252dc22ddd9f19c ]
    
    Previously, NETNS_LOCAL was not set for uplink representors, inconsistent
    with VF representors, and allowed the uplink representor to be moved
    between net namespaces and separated from the VF representors it shares
    the core device with. Such usage would break the isolation model of
    namespaces, as devices in different namespaces would have access to
    shared memory.
    
    To solve this issue, set NETNS_LOCAL for uplink representors if eswitch is
    in switchdev mode.
    
    Fixes: 7a9fb35e8c3a ("net/mlx5e: Do not reload ethernet ports when changing eswitch mode")
    Signed-off-by: Gavin Li <[email protected]>
    Reviewed-by: Gavi Teitz <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/ps3_gelic_net: Fix RX sk_buff length [+ + +]
Author: Geoff Levand <[email protected]>
Date:   Sat Mar 18 17:39:16 2023 +0000

    net/ps3_gelic_net: Fix RX sk_buff length
    
    [ Upstream commit 19b3bb51c3bc288b3f2c6f8c4450b0f548320625 ]
    
    The Gelic Ethernet device needs to have the RX sk_buffs aligned to
    GELIC_NET_RXBUF_ALIGN, and also the length of the RX sk_buffs must
    be a multiple of GELIC_NET_RXBUF_ALIGN.
    
    The current Gelic Ethernet driver was not allocating sk_buffs large
    enough to allow for this alignment.
    
    Also, correct the maximum and minimum MTU sizes, and add a new
    preprocessor macro for the maximum frame size, GELIC_NET_MAX_FRAME.
    
    Fixes various randomly occurring runtime network errors.
    
    Fixes: 02c1889166b4 ("ps3: gigabit ethernet driver for PS3, take3")
    Signed-off-by: Geoff Levand <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/ps3_gelic_net: Use dma_mapping_error [+ + +]
Author: Geoff Levand <[email protected]>
Date:   Sat Mar 18 17:39:16 2023 +0000

    net/ps3_gelic_net: Use dma_mapping_error
    
    [ Upstream commit bebe933d35a63d4f042fbf4dce4f22e689ba0fcd ]
    
    The current Gelic Etherenet driver was checking the return value of its
    dma_map_single call, and not using the dma_mapping_error() routine.
    
    Fixes runtime problems like these:
    
      DMA-API: ps3_gelic_driver sb_05: device driver failed to check map error
      WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:1027 .check_unmap+0x888/0x8dc
    
    Fixes: 02c1889166b4 ("ps3: gigabit ethernet driver for PS3, take3")
    Reviewed-by: Alexander Duyck <[email protected]>
    Signed-off-by: Geoff Levand <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/sched: act_mirred: better wording on protection against excessive stack growth [+ + +]
Author: Davide Caratti <[email protected]>
Date:   Fri Jan 20 18:01:39 2023 +0100

    net/sched: act_mirred: better wording on protection against excessive stack growth
    
    [ Upstream commit 78dcdffe0418ac8f3f057f26fe71ccf4d8ed851f ]
    
    with commit e2ca070f89ec ("net: sched: protect against stack overflow in
    TC act_mirred"), act_mirred protected itself against excessive stack growth
    using per_cpu counter of nested calls to tcf_mirred_act(), and capping it
    to MIRRED_RECURSION_LIMIT. However, such protection does not detect
    recursion/loops in case the packet is enqueued to the backlog (for example,
    when the mirred target device has RPS or skb timestamping enabled). Change
    the wording from "recursion" to "nesting" to make it more clear to readers.
    
    CC: Jamal Hadi Salim <[email protected]>
    Signed-off-by: Davide Caratti <[email protected]>
    Reviewed-by: Marcelo Ricardo Leitner <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Stable-dep-of: ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress")
    Signed-off-by: Sasha Levin <[email protected]>

 
net/sonic: use dma_mapping_error() for error check [+ + +]
Author: Zhang Changzhong <[email protected]>
Date:   Tue Mar 21 14:45:43 2023 +1100

    net/sonic: use dma_mapping_error() for error check
    
    [ Upstream commit 4107b8746d93ace135b8c4da4f19bbae81db785f ]
    
    The DMA address returned by dma_map_single() should be checked with
    dma_mapping_error(). Fix it accordingly.
    
    Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
    Signed-off-by: Zhang Changzhong <[email protected]>
    Tested-by: Stan Johnson <[email protected]>
    Signed-off-by: Finn Thain <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Link: https://lore.kernel.org/r/6645a4b5c1e364312103f48b7b36783b94e197a2.1679370343.git.fthain@linux-m68k.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: asix: fix modprobe "sysfs: cannot create duplicate filename" [+ + +]
Author: Grant Grundler <[email protected]>
Date:   Tue Mar 21 10:05:39 2023 -0700

    net: asix: fix modprobe "sysfs: cannot create duplicate filename"
    
    [ Upstream commit 8eac0095de355ee31e1b014f79f83d2cd62a2d04 ]
    
    "modprobe asix ; rmmod asix ; modprobe asix" fails with:
       sysfs: cannot create duplicate filename \
            '/devices/virtual/mdio_bus/usb-003:004'
    
    Issue was originally reported by Anton Lundin on 2022-06-22 (link below).
    
    Chrome OS team hit the same issue in Feb, 2023 when trying to find
    work arounds for other issues with AX88172 devices.
    
    The use of devm_mdiobus_register() with usbnet devices results in the
    MDIO data being associated with the USB device. When the asix driver
    is unloaded, the USB device continues to exist and the corresponding
    "mdiobus_unregister()" is NOT called until the USB device is unplugged
    or unauthorized. So the next "modprobe asix" will fail because the MDIO
    phy sysfs attributes still exist.
    
    The 'easy' (from a design PoV) fix is to use the non-devm variants of
    mdiobus_* functions and explicitly manage this use in the asix_bind
    and asix_unbind function calls. I've not explored trying to fix usbnet
    initialization so devm_* stuff will work.
    
    Fixes: e532a096be0e5 ("net: usb: asix: ax88772: add phylib support")
    Reported-by: Anton Lundin <[email protected]>
    Link: https://lore.kernel.org/netdev/[email protected]/T/
    Tested-by: Eizan Miyamoto <[email protected]>
    Signed-off-by: Grant Grundler <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: b53: mmap: fix device tree support [+ + +]
Author: Álvaro Fernández Rojas <[email protected]>
Date:   Thu Mar 16 18:28:07 2023 +0100

    net: dsa: b53: mmap: fix device tree support
    
    [ Upstream commit 30796d0dcb6e41c6558a07950f2ce60c209da867 ]
    
    CPU port should also be enabled in order to get a working switch.
    
    Fixes: a5538a777b73 ("net: dsa: b53: mmap: Add device tree support")
    Signed-off-by: Álvaro Fernández Rojas <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mt7530: move enabling disabling core clock to mt7530_pll_setup() [+ + +]
Author: Arınç ÜNAL <[email protected]>
Date:   Mon Mar 20 22:05:18 2023 +0300

    net: dsa: mt7530: move enabling disabling core clock to mt7530_pll_setup()
    
    [ Upstream commit 8f058a6ef99f0b88a177b58cc46a44ff5112e40a ]
    
    Split the code that enables and disables TRGMII clocks and core clock.
    Move enabling and disabling core clock to mt7530_pll_setup() as it's
    supposed to be run there.
    
    Add 20 ms delay before enabling the core clock as seen on the U-Boot
    MediaTek ethernet driver.
    
    Change the comment for enabling and disabling TRGMII clocks as the code
    seems to affect both TXC and RXC.
    
    Tested rgmii and trgmii modes of port 6 and rgmii mode of port 5 on MCM
    MT7530 on MT7621AT Unielec U7621-06 and standalone MT7530 on MT7623NI
    Bananapi BPI-R2.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Link: https://source.denx.de/u-boot/u-boot/-/blob/29a48bf9ccba45a5e560bb564bbe76e42629325f/drivers/net/mtk_eth.c#L589
    Tested-by: Arınç ÜNAL <[email protected]>
    Signed-off-by: Arınç ÜNAL <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mt7530: move lowering TRGMII driving to mt7530_setup() [+ + +]
Author: Arınç ÜNAL <[email protected]>
Date:   Mon Mar 20 22:05:19 2023 +0300

    net: dsa: mt7530: move lowering TRGMII driving to mt7530_setup()
    
    [ Upstream commit fdcc8ccd823740c18e803b886cec461bc0e64201 ]
    
    Move lowering the TRGMII Tx clock driving to mt7530_setup(), after setting
    the core clock, as seen on the U-Boot MediaTek ethernet driver.
    
    Move the code which looks like it lowers the TRGMII Rx clock driving to
    after the TRGMII Tx clock driving is lowered. This is run after lowering
    the Tx clock driving on the U-Boot MediaTek ethernet driver as well.
    
    This way, the switch should consume less power regardless of port 6 being
    used.
    
    Update the comment explaining mt7530_pad_clk_setup().
    
    Tested rgmii and trgmii modes of port 6 and rgmii mode of port 5 on MCM
    MT7530 on MT7621AT Unielec U7621-06 and standalone MT7530 on MT7623NI
    Bananapi BPI-R2.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Link: https://source.denx.de/u-boot/u-boot/-/blob/29a48bf9ccba45a5e560bb564bbe76e42629325f/drivers/net/mtk_eth.c#L682
    Tested-by: Arınç ÜNAL <[email protected]>
    Signed-off-by: Arınç ÜNAL <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mt7530: move setting ssc_delta to PHY_INTERFACE_MODE_TRGMII case [+ + +]
Author: Arınç ÜNAL <[email protected]>
Date:   Mon Mar 20 22:05:20 2023 +0300

    net: dsa: mt7530: move setting ssc_delta to PHY_INTERFACE_MODE_TRGMII case
    
    [ Upstream commit 407b508bdd70b6848993843d96ed49ac4108fb52 ]
    
    Move setting the ssc_delta variable to under the PHY_INTERFACE_MODE_TRGMII
    case as it's only needed when trgmii is used.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Signed-off-by: Arınç ÜNAL <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: report rx_bytes unadjusted for ETH_HLEN [+ + +]
Author: Vladimir Oltean <[email protected]>
Date:   Sat Mar 18 01:19:00 2023 +0200

    net: dsa: report rx_bytes unadjusted for ETH_HLEN
    
    [ Upstream commit a8eff03545d4cef12ae66a1905627c1818a0f81a ]
    
    We collect the software statistics counters for RX bytes (reported to
    /proc/net/dev and to ethtool -S $dev | grep 'rx_bytes: ") at a time when
    skb->len has already been adjusted by the eth_type_trans() ->
    skb_pull_inline(skb, ETH_HLEN) call to exclude the L2 header.
    
    This means that when connecting 2 DSA interfaces back to back and
    sending 1 packet with length 100, the sending interface will report
    tx_bytes as incrementing by 100, and the receiving interface will report
    rx_bytes as incrementing by 86.
    
    Since accounting for that in scripts is quirky and is something that
    would be DSA-specific behavior (requiring users to know that they are
    running on a DSA interface in the first place), the proposal is that we
    treat it as a bug and fix it.
    
    This design bug has always existed in DSA, according to my analysis:
    commit 91da11f870f0 ("net: Distributed Switch Architecture protocol
    support") also updates skb->dev->stats.rx_bytes += skb->len after the
    eth_type_trans() call. Technically, prior to Florian's commit
    a86d8becc3f0 ("net: dsa: Factor bottom tag receive functions"), each and
    every vendor-specific tagging protocol driver open-coded the same bug,
    until the buggy code was consolidated into something resembling what can
    be seen now. So each and every driver should have its own Fixes: tag,
    because of their different histories until the convergence point.
    I'm not going to do that, for the sake of simplicity, but just blame the
    oldest appearance of buggy code.
    
    There are 2 ways to fix the problem. One is the obvious way, and the
    other is how I ended up doing it. Obvious would have been to move
    dev_sw_netstats_rx_add() one line above eth_type_trans(), and below
    skb_push(skb, ETH_HLEN). But DSA processing is not as simple as that.
    We count the bytes after removing everything DSA-related from the
    packet, to emulate what the packet's length was, on the wire, when the
    user port received it.
    
    When eth_type_trans() executes, dsa_untag_bridge_pvid() has not run yet,
    so in case the switch driver requests this behavior - commit
    412a1526d067 ("net: dsa: untag the bridge pvid from rx skbs") has the
    details - the obvious variant of the fix wouldn't have worked, because
    the positioning there would have also counted the not-yet-stripped VLAN
    header length, something which is absent from the packet as seen on the
    wire (there it may be untagged, whereas software will see it as
    PVID-tagged).
    
    Fixes: f613ed665bb3 ("net: dsa: Add support for 64-bit statistics")
    Signed-off-by: Vladimir Oltean <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: tag_brcm: legacy: fix daisy-chained switches [+ + +]
Author: Álvaro Fernández Rojas <[email protected]>
Date:   Sun Mar 19 10:55:40 2023 +0100

    net: dsa: tag_brcm: legacy: fix daisy-chained switches
    
    [ Upstream commit 032a954061afd4b7426c3eb6bfd2952ef1e9a384 ]
    
    When BCM63xx internal switches are connected to switches with a 4-byte
    Broadcom tag, it does not identify the packet as VLAN tagged, so it adds one
    based on its PVID (which is likely 0).
    Right now, the packet is received by the BCM63xx internal switch and the 6-byte
    tag is properly processed. The next step would to decode the corresponding
    4-byte tag. However, the internal switch adds an invalid VLAN tag after the
    6-byte tag and the 4-byte tag handling fails.
    In order to fix this we need to remove the invalid VLAN tag after the 6-byte
    tag before passing it to the 4-byte tag decoding.
    
    Fixes: 964dbf186eaa ("net: dsa: tag_brcm: add support for legacy tags")
    Signed-off-by: Álvaro Fernández Rojas <[email protected]>
    Reviewed-by: Michal Swiatkowski <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mdio: fix owner field for mdio buses registered using ACPI [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Thu Mar 16 16:33:17 2023 -0700

    net: mdio: fix owner field for mdio buses registered using ACPI
    
    [ Upstream commit 30b605b8501e321f79e19c3238aa6ca31da6087c ]
    
    Bus ownership is wrong when using acpi_mdiobus_register() to register an
    mdio bus. That function is not inline, so when it calls
    mdiobus_register() the wrong THIS_MODULE value is captured.
    
    CC: Maxime Bizon <[email protected]>
    Fixes: 803ca24d2f92 ("net: mdio: Add ACPI support code for mdio")
    Signed-off-by: Florian Fainelli <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mdio: fix owner field for mdio buses registered using device-tree [+ + +]
Author: Maxime Bizon <[email protected]>
Date:   Thu Mar 16 16:33:16 2023 -0700

    net: mdio: fix owner field for mdio buses registered using device-tree
    
    [ Upstream commit 99669259f3361d759219811e670b7e0742668556 ]
    
    Bus ownership is wrong when using of_mdiobus_register() to register an mdio
    bus. That function is not inline, so when it calls mdiobus_register() the wrong
    THIS_MODULE value is captured.
    
    Signed-off-by: Maxime Bizon <[email protected]>
    Fixes: 90eff9096c01 ("net: phy: Allow splitting MDIO bus/device support from PHYs")
    [florian: fix kdoc, added Fixes tag]
    Signed-off-by: Florian Fainelli <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mdio: thunder: Add missing fwnode_handle_put() [+ + +]
Author: Liang He <[email protected]>
Date:   Wed Mar 22 14:20:57 2023 +0800

    net: mdio: thunder: Add missing fwnode_handle_put()
    
    [ Upstream commit b1de5c78ebe9858ccec9d49af2f76724f1d47e3e ]
    
    In device_for_each_child_node(), we should add fwnode_handle_put()
    when break out of the iteration device_for_each_child_node()
    as it will automatically increase and decrease the refcounter.
    
    Fixes: 379d7ac7ca31 ("phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.")
    Signed-off-by: Liang He <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mscc: ocelot: fix stats region batching [+ + +]
Author: Vladimir Oltean <[email protected]>
Date:   Tue Mar 21 03:03:23 2023 +0200

    net: mscc: ocelot: fix stats region batching
    
    [ Upstream commit 6acc72a43eac78a309160d0a7512bbc59bcdd757 ]
    
    The blamed commit changed struct ocelot_stat_layout :: "u32 offset" to
    "u32 reg".
    
    However, "u32 reg" is not quite a register address, but an enum
    ocelot_reg, which in itself encodes an enum ocelot_target target in the
    upper bits, and an index into the ocelot->map[target][] array in the
    lower bits.
    
    So, whereas the previous code comparison between stats_layout[i].offset
    and last + 1 was correct (because those "offsets" at the time were
    32-bit relative addresses), the new code, comparing layout[i].reg to
    last + 4 is not correct, because the "reg" here is an enum/index, not an
    actual register address.
    
    What we want to compare are indeed register addresses, but to do that,
    we need to actually go through the same motions as
    __ocelot_bulk_read_ix() itself.
    
    With this bug, all statistics counters are deemed by
    ocelot_prepare_stats_regions() as constituting their own region.
    (Truncated) log on VSC9959 (Felix) below (prints added by me):
    
    Before:
    
    region of 1 contiguous counters starting with SYS:STAT:CNT[0x000]
    region of 1 contiguous counters starting with SYS:STAT:CNT[0x001]
    region of 1 contiguous counters starting with SYS:STAT:CNT[0x002]
    ...
    region of 1 contiguous counters starting with SYS:STAT:CNT[0x041]
    region of 1 contiguous counters starting with SYS:STAT:CNT[0x042]
    region of 1 contiguous counters starting with SYS:STAT:CNT[0x080]
    region of 1 contiguous counters starting with SYS:STAT:CNT[0x081]
    ...
    region of 1 contiguous counters starting with SYS:STAT:CNT[0x0ac]
    region of 1 contiguous counters starting with SYS:STAT:CNT[0x100]
    region of 1 contiguous counters starting with SYS:STAT:CNT[0x101]
    ...
    region of 1 contiguous counters starting with SYS:STAT:CNT[0x111]
    
    After:
    
    region of 67 contiguous counters starting with SYS:STAT:CNT[0x000]
    region of 45 contiguous counters starting with SYS:STAT:CNT[0x080]
    region of 18 contiguous counters starting with SYS:STAT:CNT[0x100]
    
    Since commit d87b1c08f38a ("net: mscc: ocelot: use bulk reads for
    stats") intended bulking as a performance improvement, and since now,
    with trivial-sized regions, performance is even worse than without
    bulking at all, this could easily qualify as a performance regression.
    
    Fixes: d4c367650704 ("net: mscc: ocelot: keep ocelot_stat_layout by reg address, not offset")
    Signed-off-by: Vladimir Oltean <[email protected]>
    Acked-by: Colin Foster <[email protected]>
    Tested-by: Colin Foster <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: Ensure state transitions are processed from phy_stop() [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Thu Mar 16 13:33:24 2023 -0700

    net: phy: Ensure state transitions are processed from phy_stop()
    
    [ Upstream commit 4203d84032e28f893594a453bd8bc9c3b15c7334 ]
    
    In the phy_disconnect() -> phy_stop() path, we will be forcibly setting
    the PHY state machine to PHY_HALTED. This invalidates the old_state !=
    phydev->state condition in phy_state_machine() such that we will neither
    display the state change for debugging, nor will we invoke the
    link_change_notify() callback.
    
    Factor the code by introducing phy_process_state_change(), and ensure
    that we process the state change from phy_stop() as well.
    
    Fixes: 5c5f626bcace ("net: phy: improve handling link_change_notify callback")
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: qcom/emac: Fix use after free bug in emac_remove due to race condition [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Sat Mar 18 16:05:26 2023 +0800

    net: qcom/emac: Fix use after free bug in emac_remove due to race condition
    
    [ Upstream commit 6b6bc5b8bd2d4ca9e1efa9ae0f98a0b0687ace75 ]
    
    In emac_probe, &adpt->work_thread is bound with
    emac_work_thread. Then it will be started by timeout
    handler emac_tx_timeout or a IRQ handler emac_isr.
    
    If we remove the driver which will call emac_remove
      to make cleanup, there may be a unfinished work.
    
    The possible sequence is as follows:
    
    Fix it by finishing the work before cleanup in the emac_remove
    and disable timeout response.
    
    CPU0                  CPU1
    
                        |emac_work_thread
    emac_remove         |
    free_netdev         |
    kfree(netdev);      |
                        |emac_reinit_locked
                        |emac_mac_down
                        |//use netdev
    Fixes: b9b17debc69d ("net: emac: emac gigabit ethernet controller driver")
    Signed-off-by: Zheng Wang <[email protected]>
    
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: stmmac: Fix for mismatched host/device DMA address width [+ + +]
Author: Jochen Henneberg <[email protected]>
Date:   Fri Mar 17 09:08:17 2023 +0100

    net: stmmac: Fix for mismatched host/device DMA address width
    
    [ Upstream commit 070246e4674b125860d311c18ce2623e73e2bd51 ]
    
    Currently DMA address width is either read from a RO device register
    or force set from the platform data. This breaks DMA when the host DMA
    address width is <=32it but the device is >32bit.
    
    Right now the driver may decide to use a 2nd DMA descriptor for
    another buffer (happens in case of TSO xmit) assuming that 32bit
    addressing is used due to platform configuration but the device will
    still use both descriptor addresses as one address.
    
    This can be observed with the Intel EHL platform driver that sets
    32bit for addr64 but the MAC reports 40bit. The TX queue gets stuck in
    case of TCP with iptables NAT configuration on TSO packets.
    
    The logic should be like this: Whatever we do on the host side (memory
    allocation GFP flags) should happen with the host DMA width, whenever
    we decide how to set addresses on the device registers we must use the
    device DMA address width.
    
    This patch renames the platform address width field from addr64 (term
    used in device datasheet) to host_addr and uses this value exclusively
    for host side operations while all chip operations consider the device
    DMA width as read from the device register.
    
    Fixes: 7cfc4486e7ea ("stmmac: intel: Configure EHL PSE0 GbE and PSE1 GbE to 32 bits DMA addressing")
    Signed-off-by: Jochen Henneberg <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: cdc_mbim: avoid altsetting toggling for Telit FE990 [+ + +]
Author: Enrico Sau <[email protected]>
Date:   Mon Mar 6 12:59:33 2023 +0100

    net: usb: cdc_mbim: avoid altsetting toggling for Telit FE990
    
    [ Upstream commit 418383e6ed6b4624a54ec05c535f13d184fbf33b ]
    
    Add quirk CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE for Telit FE990
    0x1081 composition in order to avoid bind error.
    
    Signed-off-by: Enrico Sau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: lan78xx: Limit packet length to skb->len [+ + +]
Author: Szymon Heidrich <[email protected]>
Date:   Sat Mar 18 10:25:52 2023 +0100

    net: usb: lan78xx: Limit packet length to skb->len
    
    [ Upstream commit 7f247f5a2c18b3f21206cdd51193df4f38e1b9f5 ]
    
    Packet length retrieved from descriptor may be larger than
    the actual socket buffer length. In such case the cloned
    skb passed up the network stack will leak kernel memory contents.
    
    Additionally prevent integer underflow when size is less than
    ETH_FCS_LEN.
    
    Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
    Signed-off-by: Szymon Heidrich <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: qmi_wwan: add Telit 0x1080 composition [+ + +]
Author: Enrico Sau <[email protected]>
Date:   Mon Mar 6 13:05:28 2023 +0100

    net: usb: qmi_wwan: add Telit 0x1080 composition
    
    [ Upstream commit 382e363d5bed0cec5807b35761d14e55955eee63 ]
    
    Add the following Telit FE990 composition:
    
    0x1080: tty, adb, rmnet, tty, tty, tty, tty
    
    Signed-off-by: Enrico Sau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: smsc95xx: Limit packet length to skb->len [+ + +]
Author: Szymon Heidrich <[email protected]>
Date:   Thu Mar 16 11:19:54 2023 +0100

    net: usb: smsc95xx: Limit packet length to skb->len
    
    [ Upstream commit ff821092cf02a70c2bccd2d19269f01e29aa52cf ]
    
    Packet length retrieved from descriptor may be larger than
    the actual socket buffer length. In such case the cloned
    skb passed up the network stack will leak kernel memory contents.
    
    Fixes: 2f7ca802bdae ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
    Signed-off-by: Szymon Heidrich <[email protected]>
    Reviewed-by: Jakub Kicinski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFS: Correct timing for assigning access cache timestamp [+ + +]
Author: Chengen Du <[email protected]>
Date:   Wed Mar 8 16:03:27 2023 +0800

    NFS: Correct timing for assigning access cache timestamp
    
    [ Upstream commit 21fd9e8700de86d1169f6336e97d7a74916ed04a ]
    
    When the user's login time is newer than the cache's timestamp,
    the original entry in the RB-tree will be replaced by a new entry.
    Currently, the timestamp is only set if the entry is not found in
    the RB-tree, which can cause the timestamp to be undefined when
    the entry exists. This may result in a significant increase in
    ACCESS operations if the timestamp is set to zero.
    
    Signed-off-by: Chengen Du <[email protected]>
    Fixes: 0eb43812c027 ("NFS: Clear the file access cache upon login”)
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

NFS: Fix /proc/PID/io read_bytes for buffered reads [+ + +]
Author: Dave Wysochanski <[email protected]>
Date:   Thu Mar 9 13:58:52 2023 -0500

    NFS: Fix /proc/PID/io read_bytes for buffered reads
    
    [ Upstream commit 9c88ea00fef03031ce6554531e89be82f6a42835 ]
    
    Prior to commit 8786fde8421c ("Convert NFS from readpages to
    readahead"), nfs_readpages() used the old mm interface read_cache_pages()
    which called task_io_account_read() for each NFS page read.  After
    this commit, nfs_readpages() is converted to nfs_readahead(), which
    now uses the new mm interface readahead_page().  The new interface
    requires callers to call task_io_account_read() themselves.
    In addition, to nfs_readahead() task_io_account_read() should also
    be called from nfs_read_folio().
    
    Fixes: 8786fde8421c ("Convert NFS from readpages to readahead")
    Link: https://lore.kernel.org/linux-nfs/CAPt2mGNEYUk5u8V4abe=5MM5msZqmvzCVrtCP4Qw1n=gCHCnww@mail.gmail.com/
    Signed-off-by: Dave Wysochanski <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfsd: don't replace page in rq_pages if it's a continuation of last page [+ + +]
Author: Jeff Layton <[email protected]>
Date:   Fri Mar 17 13:13:08 2023 -0400

    nfsd: don't replace page in rq_pages if it's a continuation of last page
    
    [ Upstream commit 27c934dd8832dd40fd34776f916dc201e18b319b ]
    
    The splice read calls nfsd_splice_actor to put the pages containing file
    data into the svc_rqst->rq_pages array. It's possible however to get a
    splice result that only has a partial page at the end, if (e.g.) the
    filesystem hands back a short read that doesn't cover the whole page.
    
    nfsd_splice_actor will plop the partial page into its rq_pages array and
    return. Then later, when nfsd_splice_actor is called again, the
    remainder of the page may end up being filled out. At this point,
    nfsd_splice_actor will put the page into the array _again_ corrupting
    the reply. If this is done enough times, rq_next_page will overrun the
    array and corrupt the trailing fields -- the rq_respages and
    rq_next_page pointers themselves.
    
    If we've already added the page to the array in the last pass, don't add
    it to the array a second time when dealing with a splice continuation.
    This was originally handled properly in nfsd_splice_actor, but commit
    91e23b1c3982 ("NFSD: Clean up nfsd_splice_actor()") removed the check
    for it.
    
    Fixes: 91e23b1c3982 ("NFSD: Clean up nfsd_splice_actor()")
    Cc: Al Viro <[email protected]>
    Reported-by: Dario Lesca <[email protected]>
    Tested-by: David Critch <[email protected]>
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2150630
    Signed-off-by: Jeff Layton <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nilfs2: fix kernel-infoleak in nilfs_ioctl_wrap_copy() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Tue Mar 7 17:55:48 2023 +0900

    nilfs2: fix kernel-infoleak in nilfs_ioctl_wrap_copy()
    
    commit 003587000276f81d0114b5ce773d80c119d8cb30 upstream.
    
    The ioctl helper function nilfs_ioctl_wrap_copy(), which exchanges a
    metadata array to/from user space, may copy uninitialized buffer regions
    to user space memory for read-only ioctl commands NILFS_IOCTL_GET_SUINFO
    and NILFS_IOCTL_GET_CPINFO.
    
    This can occur when the element size of the user space metadata given by
    the v_size member of the argument nilfs_argv structure is larger than the
    size of the metadata element (nilfs_suinfo structure or nilfs_cpinfo
    structure) on the file system side.
    
    KMSAN-enabled kernels detect this issue as follows:
    
     BUG: KMSAN: kernel-infoleak in instrument_copy_to_user
     include/linux/instrumented.h:121 [inline]
     BUG: KMSAN: kernel-infoleak in _copy_to_user+0xc0/0x100 lib/usercopy.c:33
      instrument_copy_to_user include/linux/instrumented.h:121 [inline]
      _copy_to_user+0xc0/0x100 lib/usercopy.c:33
      copy_to_user include/linux/uaccess.h:169 [inline]
      nilfs_ioctl_wrap_copy+0x6fa/0xc10 fs/nilfs2/ioctl.c:99
      nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline]
      nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290
      nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343
      __do_compat_sys_ioctl fs/ioctl.c:968 [inline]
      __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910
      __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910
      do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
      __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
      do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203
      do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246
      entry_SYSENTER_compat_after_hwframe+0x70/0x82
    
     Uninit was created at:
      __alloc_pages+0x9f6/0xe90 mm/page_alloc.c:5572
      alloc_pages+0xab0/0xd80 mm/mempolicy.c:2287
      __get_free_pages+0x34/0xc0 mm/page_alloc.c:5599
      nilfs_ioctl_wrap_copy+0x223/0xc10 fs/nilfs2/ioctl.c:74
      nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline]
      nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290
      nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343
      __do_compat_sys_ioctl fs/ioctl.c:968 [inline]
      __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910
      __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910
      do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
      __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
      do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203
      do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246
      entry_SYSENTER_compat_after_hwframe+0x70/0x82
    
     Bytes 16-127 of 3968 are uninitialized
     ...
    
    This eliminates the leak issue by initializing the page allocated as
    buffer using get_zeroed_page().
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
      Link: https://lkml.kernel.org/r/[email protected]
    Tested-by: Ryusuke Konishi <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nvme-tcp: fix nvme_tcp_term_pdu to match spec [+ + +]
Author: Caleb Sander <[email protected]>
Date:   Mon Mar 20 09:57:36 2023 -0600

    nvme-tcp: fix nvme_tcp_term_pdu to match spec
    
    [ Upstream commit aa01c67de5926fdb276793180564f172c55fb0d7 ]
    
    The FEI field of C2HTermReq/H2CTermReq is 4 bytes but not 4-byte-aligned
    in the NVMe/TCP specification (it is located at offset 10 in the PDU).
    Split it into two 16-bit integers in struct nvme_tcp_term_pdu
    so no padding is inserted. There should also be 10 reserved bytes after.
    There are currently no users of this type.
    
    Fixes: fc221d05447aa6db ("nvme-tcp: Add protocol header")
    Reported-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Caleb Sander <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-vf: Add missing free for alloc_percpu [+ + +]
Author: Jiasheng Jiang <[email protected]>
Date:   Fri Mar 17 14:43:37 2023 +0800

    octeontx2-vf: Add missing free for alloc_percpu
    
    [ Upstream commit f038f3917baf04835ba2b7bcf2a04ac93fbf8a9c ]
    
    Add the free_percpu for the allocated "vf->hw.lmt_info" in order to avoid
    memory leak, same as the "pf->hw.lmt_info" in
    `drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`.
    
    Fixes: 5c0512072f65 ("octeontx2-pf: cn10k: Use runtime allocated LMTLINE region")
    Signed-off-by: Jiasheng Jiang <[email protected]>
    Reviewed-by: Michal Swiatkowski <[email protected]>
    Acked-by: Geethasowjanya Akula <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf/core: Fix perf_output_begin parameter is incorrectly invoked in perf_event_bpf_output [+ + +]
Author: Yang Jihong <[email protected]>
Date:   Tue Mar 14 04:47:35 2023 +0000

    perf/core: Fix perf_output_begin parameter is incorrectly invoked in perf_event_bpf_output
    
    [ Upstream commit eb81a2ed4f52be831c9fb879752d89645a312c13 ]
    
    syzkaller reportes a KASAN issue with stack-out-of-bounds.
    The call trace is as follows:
      dump_stack+0x9c/0xd3
      print_address_description.constprop.0+0x19/0x170
      __kasan_report.cold+0x6c/0x84
      kasan_report+0x3a/0x50
      __perf_event_header__init_id+0x34/0x290
      perf_event_header__init_id+0x48/0x60
      perf_output_begin+0x4a4/0x560
      perf_event_bpf_output+0x161/0x1e0
      perf_iterate_sb_cpu+0x29e/0x340
      perf_iterate_sb+0x4c/0xc0
      perf_event_bpf_event+0x194/0x2c0
      __bpf_prog_put.constprop.0+0x55/0xf0
      __cls_bpf_delete_prog+0xea/0x120 [cls_bpf]
      cls_bpf_delete_prog_work+0x1c/0x30 [cls_bpf]
      process_one_work+0x3c2/0x730
      worker_thread+0x93/0x650
      kthread+0x1b8/0x210
      ret_from_fork+0x1f/0x30
    
    commit 267fb27352b6 ("perf: Reduce stack usage of perf_output_begin()")
    use on-stack struct perf_sample_data of the caller function.
    
    However, perf_event_bpf_output uses incorrect parameter to convert
    small-sized data (struct perf_bpf_event) into large-sized data
    (struct perf_sample_data), which causes memory overwriting occurs in
    __perf_event_header__init_id.
    
    Fixes: 267fb27352b6 ("perf: Reduce stack usage of perf_output_begin()")
    Signed-off-by: Yang Jihong <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
perf/x86/amd/core: Always clear status for idx [+ + +]
Author: Breno Leitao <[email protected]>
Date:   Tue Mar 21 04:33:38 2023 -0700

    perf/x86/amd/core: Always clear status for idx
    
    [ Upstream commit 263f5ecaf7080513efc248ec739b6d9e00f4129f ]
    
    The variable 'status' (which contains the unhandled overflow bits) is
    not being properly masked in some cases, displaying the following
    warning:
    
      WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270
    
    This seems to be happening because the loop is being continued before
    the status bit being unset, in case x86_perf_event_set_period()
    returns 0. This is also causing an inconsistency because the "handled"
    counter is incremented, but the status bit is not cleaned.
    
    Move the bit cleaning together above, together when the "handled"
    counter is incremented.
    
    Fixes: 7685665c390d ("perf/x86/amd/core: Add PerfMonV2 overflow handling")
    Signed-off-by: Breno Leitao <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Sandipan Das <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
perf: fix perf_event_context->time [+ + +]
Author: Song Liu <[email protected]>
Date:   Mon Mar 13 10:16:08 2023 -0700

    perf: fix perf_event_context->time
    
    [ Upstream commit baf1b12a67f5b24f395baca03e442ce27cab0c18 ]
    
    Time readers rely on perf_event_context->[time|timestamp|timeoffset] to get
    accurate time_enabled and time_running for an event. The difference between
    ctx->timestamp and ctx->time is the among of time when the context is not
    enabled. __update_context_time(ctx, false) is used to increase timestamp,
    but not time. Therefore, it should only be called in ctx_sched_in() when
    EVENT_TIME was not enabled.
    
    Fixes: 09f5e7dc7ad7 ("perf: Fix perf_event_read_local() time")
    Signed-off-by: Song Liu <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/chrome: cros_ec_chardev: fix kernel data leak from ioctl [+ + +]
Author: Tzung-Bi Shih <[email protected]>
Date:   Fri Mar 24 09:06:58 2023 +0800

    platform/chrome: cros_ec_chardev: fix kernel data leak from ioctl
    
    [ Upstream commit b20cf3f89c56b5f6a38b7f76a8128bf9f291bbd3 ]
    
    It is possible to peep kernel page's data by providing larger `insize`
    in struct cros_ec_command[1] when invoking EC host commands.
    
    Fix it by using zeroed memory.
    
    [1]: https://elixir.bootlin.com/linux/v6.2/source/include/linux/platform_data/cros_ec_proto.h#L74
    
    Fixes: eda2e30c6684 ("mfd / platform: cros_ec: Miscellaneous character device to talk with the EC")
    Signed-off-by: Tzung-Bi Shih <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/x86: int3472: Add GPIOs to Surface Go 3 Board data [+ + +]
Author: Daniel Scally <[email protected]>
Date:   Thu Mar 2 10:26:11 2023 +0000

    platform/x86: int3472: Add GPIOs to Surface Go 3 Board data
    
    [ Upstream commit e8059d393158e927e36898aca89986a52025b9f3 ]
    
    Add the INT347E GPIO lookup table to the board data for the Surface
    Go 3. This is necessary to allow the ov7251 IR camera to probe
    properly on that platform.
    
    Signed-off-by: Daniel Scally <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
power: supply: bq24190: Fix use after free bug in bq24190_remove due to race condition [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Fri Mar 10 01:47:28 2023 +0800

    power: supply: bq24190: Fix use after free bug in bq24190_remove due to race condition
    
    [ Upstream commit 47c29d69212911f50bdcdd0564b5999a559010d4 ]
    
    In bq24190_probe, &bdi->input_current_limit_work is bound
    with bq24190_input_current_limit_work. When external power
    changed, it will call bq24190_charger_external_power_changed
     to start the work.
    
    If we remove the module which will call bq24190_remove to make
    cleanup, there may be a unfinished work. The possible
    sequence is as follows:
    
    CPU0                  CPUc1
    
                        |bq24190_input_current_limit_work
    bq24190_remove      |
    power_supply_unregister  |
    device_unregister   |
    power_supply_dev_release|
    kfree(psy)          |
                        |
                        | power_supply_get_property_from_supplier
                        |   //use
    
    Fix it by finishing the work before cleanup in the bq24190_remove
    
    Fixes: 97774672573a ("power_supply: Initialize changed_work before calling device_add")
    Signed-off-by: Zheng Wang <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

power: supply: da9150: Fix use after free bug in da9150_charger_remove due to race condition [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Sun Mar 12 01:46:50 2023 +0800

    power: supply: da9150: Fix use after free bug in da9150_charger_remove due to race condition
    
    [ Upstream commit 06615d11cc78162dfd5116efb71f29eb29502d37 ]
    
    In da9150_charger_probe, &charger->otg_work is bound with
    da9150_charger_otg_work. da9150_charger_otg_ncb may be
    called to start the work.
    
    If we remove the module which will call da9150_charger_remove
    to make cleanup, there may be a unfinished work. The possible
    sequence is as follows:
    
    Fix it by canceling the work before cleanup in the da9150_charger_remove
    
    CPU0                  CPUc1
    
                        |da9150_charger_otg_work
    da9150_charger_remove      |
    power_supply_unregister  |
    device_unregister   |
    power_supply_dev_release|
    kfree(psy)          |
                        |
                        |   power_supply_changed(charger->usb);
                        |   //use
    
    Fixes: c1a281e34dae ("power: Add support for DA9150 Charger")
    Signed-off-by: Zheng Wang <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info [+ + +]
Author: Daniil Tatianin <[email protected]>
Date:   Thu Mar 16 13:29:21 2023 +0300

    qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info
    
    [ Upstream commit 25143b6a01d0cc5319edd3de22ffa2578b045550 ]
    
    We have to make sure that the info returned by the helper is valid
    before using it.
    
    Found by Linux Verification Center (linuxtesting.org) with the SVACE
    static analysis tool.
    
    Fixes: f990c82c385b ("qed*: Add support for ndo_set_vf_trust")
    Fixes: 733def6a04bf ("qed*: IOV link control")
    Signed-off-by: Daniil Tatianin <[email protected]>
    Reviewed-by: Michal Swiatkowski <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "kasan: drop skip_kasan_poison variable in free_pages_prepare" [+ + +]
Author: Peter Collingbourne <[email protected]>
Date:   Thu Mar 9 20:29:13 2023 -0800

    Revert "kasan: drop skip_kasan_poison variable in free_pages_prepare"
    
    commit f446883d12b8bfa486f7c98d403054d61d38c989 upstream.
    
    This reverts commit 487a32ec24be819e747af8c2ab0d5c515508086a.
    
    should_skip_kasan_poison() reads the PG_skip_kasan_poison flag from
    page->flags.  However, this line of code in free_pages_prepare():
    
            page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
    
    clears most of page->flags, including PG_skip_kasan_poison, before calling
    should_skip_kasan_poison(), which meant that it would never return true as
    a result of the page flag being set.  Therefore, fix the code to call
    should_skip_kasan_poison() before clearing the flags, as we were doing
    before the reverted patch.
    
    This fixes a measurable performance regression introduced in the reverted
    commit, where munmap() takes longer than intended if HW tags KASAN is
    supported and enabled at runtime.  Without this patch, we see a
    single-digit percentage performance regression in a particular
    mmap()-heavy benchmark when enabling HW tags KASAN, and with the patch,
    there is no statistically significant performance impact when enabling HW
    tags KASAN.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 487a32ec24be ("kasan: drop skip_kasan_poison variable in free_pages_prepare")
      Link: https://linux-review.googlesource.com/id/Ic4f13affeebd20548758438bb9ed9ca40e312b79
    Signed-off-by: Peter Collingbourne <[email protected]>
    Reviewed-by: Andrey Konovalov <[email protected]>
    Cc: Andrey Ryabinin <[email protected]>
    Cc: Catalin Marinas <[email protected]> [arm64]
    Cc: Evgenii Stepanov <[email protected]>
    Cc: Vincenzo Frascino <[email protected]>
    Cc: Will Deacon <[email protected]>
    Cc: <[email protected]>    [6.1]
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
riscv: Bump COMMAND_LINE_SIZE value to 1024 [+ + +]
Author: Alexandre Ghiti <[email protected]>
Date:   Tue Mar 16 15:34:20 2021 -0400

    riscv: Bump COMMAND_LINE_SIZE value to 1024
    
    [ Upstream commit 61fc1ee8be26bc192d691932b0a67eabee45d12f ]
    
    Increase COMMAND_LINE_SIZE as the current default value is too low
    for syzbot kernel command line.
    
    There has been considerable discussion on this patch that has led to a
    larger patch set removing COMMAND_LINE_SIZE from the uapi headers on all
    ports.  That's not quite done yet, but it's gotten far enough we're
    confident this is not a uABI change so this is safe.
    
    Reported-by: Dmitry Vyukov <[email protected]>
    Signed-off-by: Alexandre Ghiti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [Palmer: it's not uabi]
    Link: https://lore.kernel.org/linux-riscv/[email protected]/#t
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: Handle zicsr/zifencei issues between clang and binutils [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Mon Mar 13 16:00:23 2023 -0700

    riscv: Handle zicsr/zifencei issues between clang and binutils
    
    commit e89c2e815e76471cb507bd95728bf26da7976430 upstream.
    
    There are two related issues that appear in certain combinations with
    clang and GNU binutils.
    
    The first occurs when a version of clang that supports zicsr or zifencei
    via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
    of GNU binutils that do not recognize zicsr and zifencei in the
    '-march=' value (i.e., < 2.36):
    
      riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
      riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
      riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
      riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
    
    The second occurs when a version of clang that does not support zicsr or
    zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
    version of GNU as that defaults to a newer ISA base spec, which requires
    specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
    2.38):
    
      ../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
      ../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
      clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
    
    This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
    build with binutils 2.38") (see [2] for additional information) but
    older versions of clang miss out on it because the cc-option check
    fails:
    
      clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
      clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
    
    To resolve the first issue, only attempt to add zicsr and zifencei to
    the march string when using the GNU assembler 2.38 or newer, which is
    when the default ISA spec was updated, requiring these extensions to be
    specified explicitly. LLVM implements an older version of the base
    specification for all currently released versions, so these instructions
    are available as part of the 'i' extension. If LLVM's implementation is
    updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
    CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
    
    To resolve the second issue, use version 2.2 of the base ISA spec when
    using an older version of clang that does not support zicsr or zifencei
    via '-march=', as that is the spec version most compatible with the one
    clang/LLVM implements and avoids the need to specify zicsr and zifencei
    explicitly due to still being a part of 'i'.
    
    [1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
    [2]: https://lore.kernel.org/[email protected]/
    
    Cc: [email protected]
    Link: https://github.com/ClangBuiltLinux/linux/issues/1808
    Co-developed-by: Conor Dooley <[email protected]>
    Signed-off-by: Conor Dooley <[email protected]>
    Signed-off-by: Nathan Chancellor <[email protected]>
    Acked-by: Conor Dooley <[email protected]>
    Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

riscv: mm: Fix incorrect ASID argument when flushing TLB [+ + +]
Author: Dylan Jhong <[email protected]>
Date:   Mon Mar 13 11:49:06 2023 +0800

    riscv: mm: Fix incorrect ASID argument when flushing TLB
    
    commit 9a801afd3eb95e1a89aba17321062df06fb49d98 upstream.
    
    Currently, we pass the CONTEXTID instead of the ASID to the TLB flush
    function. We should only take the ASID field to prevent from touching
    the reserved bit field.
    
    Fixes: 3f1e782998cd ("riscv: add ASID-based tlbflushing methods")
    Signed-off-by: Dylan Jhong <[email protected]>
    Reviewed-by: Sergey Matyukevich <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
sched/fair: Sanitize vruntime of entity being migrated [+ + +]
Author: Vincent Guittot <[email protected]>
Date:   Fri Mar 17 17:08:10 2023 +0100

    sched/fair: Sanitize vruntime of entity being migrated
    
    commit a53ce18cacb477dd0513c607f187d16f0fa96f71 upstream.
    
    Commit 829c1651e9c4 ("sched/fair: sanitize vruntime of entity being placed")
    fixes an overflowing bug, but ignore a case that se->exec_start is reset
    after a migration.
    
    For fixing this case, we delay the reset of se->exec_start after
    placing the entity which se->exec_start to detect long sleeping task.
    
    In order to take into account a possible divergence between the clock_task
    of 2 rqs, we increase the threshold to around 104 days.
    
    Fixes: 829c1651e9c4 ("sched/fair: sanitize vruntime of entity being placed")
    Originally-by: Zhang Qiao <[email protected]>
    Signed-off-by: Vincent Guittot <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Tested-by: Zhang Qiao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

sched/fair: sanitize vruntime of entity being placed [+ + +]
Author: Zhang Qiao <[email protected]>
Date:   Mon Jan 30 13:22:16 2023 +0100

    sched/fair: sanitize vruntime of entity being placed
    
    commit 829c1651e9c4a6f78398d3e67651cef9bb6b42cc upstream.
    
    When a scheduling entity is placed onto cfs_rq, its vruntime is pulled
    to the base level (around cfs_rq->min_vruntime), so that the entity
    doesn't gain extra boost when placed backwards.
    
    However, if the entity being placed wasn't executed for a long time, its
    vruntime may get too far behind (e.g. while cfs_rq was executing a
    low-weight hog), which can inverse the vruntime comparison due to s64
    overflow.  This results in the entity being placed with its original
    vruntime way forwards, so that it will effectively never get to the cpu.
    
    To prevent that, ignore the vruntime of the entity being placed if it
    didn't execute for much longer than the characteristic sheduler time
    scale.
    
    [rkagan: formatted, adjusted commit log, comments, cutoff value]
    Signed-off-by: Zhang Qiao <[email protected]>
    Co-developed-by: Roman Kagan <[email protected]>
    Signed-off-by: Roman Kagan <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
scsi: core: Add BLIST_SKIP_VPD_PAGES for SKhynix H28U74301AMR [+ + +]
Author: Joel Selvaraj <[email protected]>
Date:   Sun Mar 12 23:14:02 2023 -0500

    scsi: core: Add BLIST_SKIP_VPD_PAGES for SKhynix H28U74301AMR
    
    commit a204b490595de71016b2360a1886ec8c12d0afac upstream.
    
    Xiaomi Poco F1 (qcom/sdm845-xiaomi-beryllium*.dts) comes with a SKhynix
    H28U74301AMR UFS. The sd_read_cpr() operation leads to a 120 second
    timeout, making the device bootup very slow:
    
    [  121.457736] sd 0:0:0:1: [sdb] tag#23 timing out command, waited 120s
    
    Setting the BLIST_SKIP_VPD_PAGES allows the device to skip the failing
    sd_read_cpr operation and boot normally.
    
    Signed-off-by: Joel Selvaraj <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: hisi_sas: Check devm_add_action() return value [+ + +]
Author: Kang Chen <[email protected]>
Date:   Mon Feb 27 11:10:30 2023 +0800

    scsi: hisi_sas: Check devm_add_action() return value
    
    [ Upstream commit 06d1a90de60208054cca15ef200138cfdbb642a9 ]
    
    In case devm_add_action() fails, check it in the caller of
    interrupt_preinit_v3_hw().
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Kang Chen <[email protected]>
    Acked-by: Xiang Chen <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: lpfc: Avoid usage of list iterator variable after loop [+ + +]
Author: Jakob Koschel <[email protected]>
Date:   Wed Mar 1 18:19:14 2023 +0100

    scsi: lpfc: Avoid usage of list iterator variable after loop
    
    [ Upstream commit 2850b23e9f9ae3696e472d2883ea1b43aafa884e ]
    
    If the &epd_pool->list is empty when executing
    lpfc_get_io_buf_from_expedite_pool() the function would return an invalid
    pointer. Even in the case if the list is guaranteed to be populated, the
    iterator variable should not be used after the loop to be more robust for
    future changes.
    
    Linus proposed to avoid any use of the list iterator variable after the
    loop, in the attempt to move the list iterator variable declaration into
    the macro to avoid any potential misuse after the loop [1].
    
    Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1]
    Signed-off-by: Jakob Koschel <[email protected]>
    Link: https://lore.kernel.org/r/20230301-scsi-lpfc-avoid-list-iterator-after-loop-v1-1-325578ae7561@gmail.com
    Reviewed-by: Justin Tee <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: lpfc: Check kzalloc() in lpfc_sli4_cgn_params_read() [+ + +]
Author: Justin Tee <[email protected]>
Date:   Mon Feb 27 20:43:36 2023 -0800

    scsi: lpfc: Check kzalloc() in lpfc_sli4_cgn_params_read()
    
    [ Upstream commit 312320b0e0ec21249a17645683fe5304d796aec1 ]
    
    If kzalloc() fails in lpfc_sli4_cgn_params_read(), then we rely on
    lpfc_read_object()'s routine to NULL check pdata.
    
    Currently, an early return error is thrown from lpfc_read_object() to
    protect us from NULL ptr dereference, but the errno code is -ENODEV.
    
    Change the errno code to a more appropriate -ENOMEM.
    
    Reported-by: Kang Chen <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Justin Tee <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: mpi3mr: Bad drive in topology results kernel crash [+ + +]
Author: Ranjan Kumar <[email protected]>
Date:   Tue Feb 28 06:08:35 2023 -0800

    scsi: mpi3mr: Bad drive in topology results kernel crash
    
    [ Upstream commit 8e45183978d64699df639e795235433a60f35047 ]
    
    When the SAS Transport Layer support is enabled and a device exposed to
    the OS by the driver fails INQUIRY commands, the driver frees up the memory
    allocated for an internal HBA port data structure. However, in some places,
    the reference to the freed memory is not cleared. When the firmware sends
    the Device Info change event for the same device again, the freed memory is
    accessed and that leads to memory corruption and OS crash.
    
    Signed-off-by: Ranjan Kumar <[email protected]>
    Signed-off-by: Sreekanth Reddy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: mpi3mr: Driver unload crashes host when enhanced logging is enabled [+ + +]
Author: Ranjan Kumar <[email protected]>
Date:   Tue Feb 28 06:08:31 2023 -0800

    scsi: mpi3mr: Driver unload crashes host when enhanced logging is enabled
    
    [ Upstream commit 5b06a7169c59ce0c77ef8b9c82aa07c478f82aac ]
    
    Prevent driver from trying to dereference a NULL pointer in a debug print
    while removing a device during driver unload.
    
    Signed-off-by: Ranjan Kumar <[email protected]>
    Signed-off-by: Sreekanth Reddy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: mpi3mr: NVMe command size greater than 8K fails [+ + +]
Author: Ranjan Kumar <[email protected]>
Date:   Tue Feb 28 06:08:34 2023 -0800

    scsi: mpi3mr: NVMe command size greater than 8K fails
    
    [ Upstream commit 4f297e856a7b5da2f2c66a12e739666e23943560 ]
    
    A wrong variable is checked while populating PRP entries in the PRP page
    and this results in failure. No PRP entries in the PRP page were
    successfully created and any NVMe Encapsulated commands with PRP of size
    greater than 8K failed.
    
    Signed-off-by: Ranjan Kumar <[email protected]>
    Signed-off-by: Sreekanth Reddy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: mpi3mr: Wait for diagnostic save during controller init [+ + +]
Author: Ranjan Kumar <[email protected]>
Date:   Tue Feb 28 06:08:32 2023 -0800

    scsi: mpi3mr: Wait for diagnostic save during controller init
    
    [ Upstream commit 0a319f1629495d27879b7ebf6eee62b8cf6e4c37 ]
    
    If a controller reset operation is triggered to recover the controller from
    a fault state, then wait for the snapdump to be saved in the firmware
    region before proceeding to reset the controller.
    
    Signed-off-by: Ranjan Kumar <[email protected]>
    Signed-off-by: Sreekanth Reddy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qla2xxx: Add option to disable FC2 Target support [+ + +]
Author: Daniel Wagner <[email protected]>
Date:   Wed Feb 8 16:20:14 2023 +0100

    scsi: qla2xxx: Add option to disable FC2 Target support
    
    [ Upstream commit 877b03795fcf29ff2e2351f7e574ecc9b9c51732 ]
    
    Commit 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target") added
    support for FC2 Targets. Unfortunately, there are older setups which break
    with this new feature enabled.
    
    Allow to disable it via module option.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Daniel Wagner <[email protected]>
    Reviewed-by: Himanshu Madhani <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qla2xxx: Perform lockless command completion in abort path [+ + +]
Author: Nilesh Javali <[email protected]>
Date:   Sun Mar 12 21:37:10 2023 -0700

    scsi: qla2xxx: Perform lockless command completion in abort path
    
    commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9 upstream.
    
    While adding and removing the controller, the following call trace was
    observed:
    
    WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50
    CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1
    RIP: 0010:dma_free_attrs+0x33/0x50
    
    Call Trace:
       qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx]
       qla2x00_abort_srb+0x8e/0x250 [qla2xxx]
       ? ql_dbg+0x70/0x100 [qla2xxx]
       __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx]
       qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx]
       qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx]
       qla2x00_remove_one+0x364/0x400 [qla2xxx]
       pci_device_remove+0x36/0xa0
       __device_release_driver+0x17a/0x230
       device_release_driver+0x24/0x30
       pci_stop_bus_device+0x68/0x90
       pci_stop_and_remove_bus_device_locked+0x16/0x30
       remove_store+0x75/0x90
       kernfs_fop_write_iter+0x11c/0x1b0
       new_sync_write+0x11f/0x1b0
       vfs_write+0x1eb/0x280
       ksys_write+0x5f/0xe0
       do_syscall_64+0x5c/0x80
       ? do_user_addr_fault+0x1d8/0x680
       ? do_syscall_64+0x69/0x80
       ? exc_page_fault+0x62/0x140
       ? asm_exc_page_fault+0x8/0x30
       entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    The command was completed in the abort path during driver unload with a
    lock held, causing the warning in abort path. Hence complete the command
    without any lock held.
    
    Reported-by: Lin Li <[email protected]>
    Tested-by: Lin Li <[email protected]>
    Cc: [email protected]
    Signed-off-by: Nilesh Javali <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Himanshu Madhani <[email protected]>
    Reviewed-by: John Meneghini <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: qla2xxx: Synchronize the IOCB count to be in order [+ + +]
Author: Quinn Tran <[email protected]>
Date:   Sun Mar 12 21:37:11 2023 -0700

    scsi: qla2xxx: Synchronize the IOCB count to be in order
    
    commit d3affdeb400f3adc925bd996f3839481f5291839 upstream.
    
    A system hang was observed with the following call trace:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 15 PID: 86747 Comm: nvme Kdump: loaded Not tainted 6.2.0+ #1
    Hardware name: Dell Inc. PowerEdge R6515/04F3CJ, BIOS 2.7.3 03/31/2022
    RIP: 0010:__wake_up_common+0x55/0x190
    Code: 41 f6 01 04 0f 85 b2 00 00 00 48 8b 43 08 4c 8d
          40 e8 48 8d 43 08 48 89 04 24 48 89 c6\
          49 8d 40 18 48 39 c6 0f 84 e9 00 00 00 <49> 8b 40 18 89 6c 24 14 31
          ed 4c 8d 60 e8 41 8b 18 f6 c3 04 75 5d
    RSP: 0018:ffffb05a82afbba0 EFLAGS: 00010082
    RAX: 0000000000000000 RBX: ffff8f9b83a00018 RCX: 0000000000000000
    RDX: 0000000000000001 RSI: ffff8f9b83a00020 RDI: ffff8f9b83a00018
    RBP: 0000000000000001 R08: ffffffffffffffe8 R09: ffffb05a82afbbf8
    R10: 70735f7472617473 R11: 5f30307832616c71 R12: 0000000000000001
    R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
    FS:  00007f815cf4c740(0000) GS:ffff8f9eeed80000(0000)
            knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 000000010633a000 CR4: 0000000000350ee0
    Call Trace:
        <TASK>
        __wake_up_common_lock+0x83/0xd0
        qla_nvme_ls_req+0x21b/0x2b0 [qla2xxx]
        __nvme_fc_send_ls_req+0x1b5/0x350 [nvme_fc]
        nvme_fc_xmt_disconnect_assoc+0xca/0x110 [nvme_fc]
        nvme_fc_delete_association+0x1bf/0x220 [nvme_fc]
        ? nvme_remove_namespaces+0x9f/0x140 [nvme_core]
        nvme_do_delete_ctrl+0x5b/0xa0 [nvme_core]
        nvme_sysfs_delete+0x5f/0x70 [nvme_core]
        kernfs_fop_write_iter+0x12b/0x1c0
        vfs_write+0x2a3/0x3b0
        ksys_write+0x5f/0xe0
        do_syscall_64+0x5c/0x90
        ? syscall_exit_work+0x103/0x130
        ? syscall_exit_to_user_mode+0x12/0x30
        ? do_syscall_64+0x69/0x90
        ? exit_to_user_mode_loop+0xd0/0x130
        ? exit_to_user_mode_prepare+0xec/0x100
        ? syscall_exit_to_user_mode+0x12/0x30
        ? do_syscall_64+0x69/0x90
        ? syscall_exit_to_user_mode+0x12/0x30
        ? do_syscall_64+0x69/0x90
        entry_SYSCALL_64_after_hwframe+0x72/0xdc
        RIP: 0033:0x7f815cd3eb97
    
    The IOCB counts are out of order and that would block any commands from
    going out and subsequently hang the system. Synchronize the IOCB count to
    be in correct order.
    
    Fixes: 5f63a163ed2f ("scsi: qla2xxx: Fix exchange oversubscription for management commands")
    Cc: [email protected]
    Signed-off-by: Quinn Tran <[email protected]>
    Signed-off-by: Nilesh Javali <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Himanshu Madhani <[email protected]>
    Reviewed-by: John Meneghini <[email protected]>
    Tested-by: Lin Li <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Wed Mar 15 14:21:54 2023 +0800

    scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()
    
    [ Upstream commit a13faca032acbf2699293587085293bdfaafc8ae ]
    
    If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not
    freed, which will cause following memleak:
    
    unreferenced object 0xffff88810b2c6980 (size 32):
      comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff  @9$.............
      backtrace:
        [<0000000098f3a26d>] alua_activate+0xb0/0x320
        [<000000003b529641>] scsi_dh_activate+0xb2/0x140
        [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath]
        [<000000007adc9ace>] process_one_work+0x3c5/0x730
        [<00000000c457a985>] worker_thread+0x93/0x650
        [<00000000cb80e628>] kthread+0x1ba/0x210
        [<00000000a1e61077>] ret_from_fork+0x22/0x30
    
    Fix the problem by freeing 'qdata' in error path.
    
    Fixes: 625fe857e4fa ("scsi: scsi_dh_alua: Check scsi_device_get() return value")
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Benjamin Block <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: storvsc: Handle BlockSize change in Hyper-V VHD/VHDX file [+ + +]
Author: Michael Kelley <[email protected]>
Date:   Mon Feb 27 08:48:34 2023 -0800

    scsi: storvsc: Handle BlockSize change in Hyper-V VHD/VHDX file
    
    [ Upstream commit 11d9874c4204a785f43d899a1ab12f9dc8d9de3e ]
    
    Hyper-V uses a VHD or VHDX file on the host as the underlying storage for a
    virtual disk.  The VHD/VHDX file format is a sparse format where real disk
    space on the host is assigned in chunks that the VHD/VHDX file format calls
    the BlockSize.  This BlockSize is not to be confused with the 512-byte (or
    4096-byte) sector size of the underlying storage device.  The default block
    size for a new VHD/VHDX file is 32 Mbytes.  When a guest VM touches any
    disk space within a 32 Mbyte chunk of the VHD/VHDX file, Hyper-V allocates
    32 Mbytes of real disk space for that section of the VHD/VHDX. Similarly,
    if a discard operation is done that covers an entire 32 Mbyte chunk,
    Hyper-V will free the real disk space for that portion of the VHD/VHDX.
    This BlockSize is surfaced in Linux as the "discard_granularity" in
    /sys/block/sd<x>/queue, which makes sense.
    
    Hyper-V also has differencing disks that can overlay a VHD/VHDX file to
    capture changes to the VHD/VHDX while preserving the original VHD/VHDX.
    One example of this differencing functionality is for VM snapshots.  When a
    snapshot is created, a differencing disk is created.  If the snapshot is
    rolled back, Hyper-V can just delete the differencing disk, and the VM will
    see the original disk contents at the time the snapshot was taken.
    Differencing disks are used in other scenarios as well.
    
    The BlockSize for a differencing disk defaults to 2 Mbytes, not 32 Mbytes.
    The smaller default is used because changes to differencing disks are
    typically scattered all over, and Hyper-V doesn't want to allocate 32
    Mbytes of real disk space for a stray write here or there.  The smaller
    BlockSize provides more efficient use of real disk space.
    
    When a differencing disk is added to a VHD/VHDX, Hyper-V reports
    UNIT_ATTENTION with a sense code indicating "Operating parameters have
    changed", because the value of discard_granularity should be changed to 2
    Mbytes. When the differencing disk is removed, discard_granularity should
    be changed back to 32 Mbytes.  However, current code simply reports a
    message from scsi_report_sense() and the value of
    /sys/block/sd<x>/queue/discard_granularity is not updated. The message
    isn't very actionable by a sysadmin.
    
    Fix this by having the storvsc driver check for the sense code indicating
    that the underly VHD/VHDX block size has changed, and do a rescan of the
    device to pick up the new discard_granularity.  With this change the entire
    transition to/from differencing disks is handled automatically and
    transparently, with no confusing messages being output.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Michael Kelley <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: target: iscsi: Fix an error message in iscsi_check_key() [+ + +]
Author: Maurizio Lombardi <[email protected]>
Date:   Tue Feb 14 15:15:56 2023 +0100

    scsi: target: iscsi: Fix an error message in iscsi_check_key()
    
    [ Upstream commit 6cc55c969b7ce8d85e09a636693d4126c3676c11 ]
    
    The first half of the error message is printed by pr_err(), the second half
    is printed by pr_debug(). The user will therefore see only the first part
    of the message and will miss some useful information.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Maurizio Lombardi <[email protected]>
    Reviewed-by: Mike Christie <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: Add soft dependency on governor_simpleondemand [+ + +]
Author: Adrien Thierry <[email protected]>
Date:   Mon Feb 20 09:07:40 2023 -0500

    scsi: ufs: core: Add soft dependency on governor_simpleondemand
    
    [ Upstream commit 2ebe16155dc8bd4e602cad5b5f65458d2eaa1a75 ]
    
    The ufshcd driver uses simpleondemand governor for devfreq. Add it to the
    list of ufshcd softdeps to allow userspace initramfs tools like dracut to
    automatically pull the governor module into the initramfs together with UFS
    drivers.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Adrien Thierry <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/bpf: check that modifier resolves after pointer [+ + +]
Author: Lorenz Bauer <[email protected]>
Date:   Mon Mar 6 11:21:38 2023 +0000

    selftests/bpf: check that modifier resolves after pointer
    
    [ Upstream commit dfdd608c3b365f0fd49d7e13911ebcde06b9865b ]
    
    Add a regression test that ensures that a VAR pointing at a
    modifier which follows a PTR (or STRUCT or ARRAY) is resolved
    correctly by the datasec validator.
    
    Signed-off-by: Lorenz Bauer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/x86/amx: Add a ptrace test [+ + +]
Author: Chang S. Bae <[email protected]>
Date:   Mon Feb 27 13:05:04 2023 -0800

    selftests/x86/amx: Add a ptrace test
    
    commit 62faca1ca10cc84e99ae7f38aa28df2bc945369b upstream.
    
    Include a test case to validate the XTILEDATA injection to the target.
    
    Also, it ensures the kernel's ability to copy states between different
    XSAVE formats.
    
    Refactor the memcmp() code to be usable for the state validation.
    
    Signed-off-by: Chang S. Bae <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/all/20230227210504.18520-3-chang.seok.bae%40intel.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
sh: sanitize the flags on sigreturn [+ + +]
Author: Al Viro <[email protected]>
Date:   Mon Mar 6 01:20:30 2023 +0000

    sh: sanitize the flags on sigreturn
    
    [ Upstream commit 573b22ccb7ce9ab7f0539a2e11a9d3609a8783f5 ]
    
    We fetch %SR value from sigframe; it might have been modified by signal
    handler, so we can't trust it with any bits that are not modifiable in
    user mode.
    
    Signed-off-by: Al Viro <[email protected]>
    Cc: Rich Felker <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
smb3: fix unusable share after force unmount failure [+ + +]
Author: Steve French <[email protected]>
Date:   Thu Mar 23 16:20:02 2023 -0500

    smb3: fix unusable share after force unmount failure
    
    commit 491eafce1a51c457701351a4bf40733799745314 upstream.
    
    If user does forced unmount ("umount -f") while files are still open
    on the share (as was seen in a Kubernetes example running on SMB3.1.1
    mount) then we were marking the share as "TID_EXITING" in umount_begin()
    which caused all subsequent operations (except write) to fail ... but
    unfortunately when umount_begin() is called we do not know yet that
    there are open files or active references on the share that would prevent
    unmount from succeeding.  Kubernetes had example when they were doing
    umount -f when files were open which caused the share to become
    unusable until the files were closed (and the umount retried).
    
    Fix this so that TID_EXITING is not set until we are about to send
    the tree disconnect (not at the beginning of forced umounts in
    umount_begin) so that if "umount -f" fails (due to open files or
    references) the mount is still usable.
    
    Cc: [email protected]
    Reviewed-by: Shyam Prasad N <[email protected]>
    Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

smb3: lower default deferred close timeout to address perf regression [+ + +]
Author: Steve French <[email protected]>
Date:   Thu Mar 23 15:10:26 2023 -0500

    smb3: lower default deferred close timeout to address perf regression
    
    commit 7e0e76d99079be13c9961dde7c93b2d1ee665af4 upstream.
    
    Performance tests with large number of threads noted that the change
    of the default closetimeo (deferred close timeout between when
    close is done by application and when client has to send the close
    to the server), to 5 seconds from 1 second, significantly degraded
    perf in some cases like this (in the filebench example reported,
    the stats show close requests on the wire taking twice as long,
    and 50% regression in filebench perf). This is stil configurable
    via mount parm closetimeo, but to be safe, decrease default back
    to its previous value of 1 second.
    
    Reported-by: Yin Fengwei <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]/
    Fixes: 5efdd9122eff ("smb3: allow deferred close timeout to be configurable")
    Cc: [email protected] # 6.0+
    Tested-by: Yin Fengwei <[email protected]>
    Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
    Reviewed-by: Shyam Prasad N <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
soc: qcom: llcc: Fix slice configuration values for SC8280XP [+ + +]
Author: Abel Vesa <[email protected]>
Date:   Mon Mar 6 15:55:27 2023 +0200

    soc: qcom: llcc: Fix slice configuration values for SC8280XP
    
    commit 77bf4b3ed42e31d29b255fcd6530fb7a1e217e89 upstream.
    
    The slice IDs for CVPFW, CPUSS1 and CPUWHT currently overflow the 32bit
    LLCC config registers, which means it is writing beyond the upper limit
    of the ATTR0_CFGn and ATTR1_CFGn range of registers. But the most obvious
    impact is the fact that the mentioned slices do not get configured at all,
    which will result in reduced performance. Fix that by using the slice ID
    values taken from the latest LLCC SC table.
    
    Fixes: ec69dfbdc426 ("soc: qcom: llcc: Add sc8180x and sc8280xp configurations")
    Cc: [email protected]      # 5.19+
    Signed-off-by: Abel Vesa <[email protected]>
    Tested-by: Juerg Haefliger <[email protected]>
    Reviewed-by: Sai Prakash Ranjan <[email protected]>
    Acked-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Johan Hovold <[email protected]>
    Signed-off-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tee: amdtee: fix race condition in amdtee_open_session [+ + +]
Author: Rijo Thomas <[email protected]>
Date:   Tue Feb 28 15:11:20 2023 +0530

    tee: amdtee: fix race condition in amdtee_open_session
    
    commit f8502fba45bd30e1a6a354d9d898bc99d1a11e6d upstream.
    
    There is a potential race condition in amdtee_open_session that may
    lead to use-after-free. For instance, in amdtee_open_session() after
    sess->sess_mask is set, and before setting:
    
        sess->session_info[i] = session_info;
    
    if amdtee_close_session() closes this same session, then 'sess' data
    structure will be released, causing kernel panic when 'sess' is
    accessed within amdtee_open_session().
    
    The solution is to set the bit sess->sess_mask as the last step in
    amdtee_open_session().
    
    Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver")
    Cc: [email protected]
    Signed-off-by: Rijo Thomas <[email protected]>
    Acked-by: Sumit Garg <[email protected]>
    Signed-off-by: Jens Wiklander <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
test_maple_tree: add more testing for mas_empty_area() [+ + +]
Author: Liam R. Howlett <[email protected]>
Date:   Tue Mar 7 13:02:47 2023 -0500

    test_maple_tree: add more testing for mas_empty_area()
    
    commit 4bd6dded6318dc8e2514d74868c1f8fb38b61a60 upstream.
    
    Test robust filling of an entire area of the tree, then test one beyond.
    This is to test the walking back up the tree at the end of nodes and error
    condition.  Test inspired by the reproducer code provided by Snild Dolkow.
    
    The last test in the function tests for the case of a corrupted maple
    state caused by the incorrect limits set during mas_skip_node().  There
    needs to be a gap in the second last child and last child, but the search
    must rule out the second last child's gap.  This would avoid correcting
    the maple state to the correct max limit and return an error.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Cc: Snild Dolkow <[email protected]>
    Link: https://lore.kernel.org/linux-mm/[email protected]/
    Fixes: e15e06a83923 ("lib/test_maple_tree: add testing for maple tree")
    Signed-off-by: Liam R. Howlett <[email protected]>
    Cc: Peng Zhang <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
thermal/drivers/mellanox: Use generic thermal_zone_get_trip() function [+ + +]
Author: Daniel Lezcano <[email protected]>
Date:   Fri Oct 14 09:32:51 2022 +0200

    thermal/drivers/mellanox: Use generic thermal_zone_get_trip() function
    
    [ Upstream commit 44a29a4dab73411671e0b84817a5f07e291b1501 ]
    
    The thermal framework gives the possibility to register the trip
    points with the thermal zone. When that is done, no get_trip_* ops are
    needed and they can be removed.
    
    Convert ops content logic into generic trip points and register them with the
    thermal zone.
    
    Signed-off-by: Daniel Lezcano <[email protected]>
    Signed-off-by: Vadim Pasternak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 6d206b1ea9f4 ("mlxsw: core_thermal: Fix fan speed in maximum cooling state")
    Signed-off-by: Sasha Levin <[email protected]>

 
thunderbolt: Add missing UNSET_INBOUND_SBTX for retimer access [+ + +]
Author: Gil Fine <[email protected]>
Date:   Fri Mar 3 00:17:24 2023 +0200

    thunderbolt: Add missing UNSET_INBOUND_SBTX for retimer access
    
    commit cd0c1e582b055dea615001b8bd8eccaf6f69f7ce upstream.
    
    According to USB4 retimer specification, the process of firmware update
    sequence requires issuing a SET_INBOUND_SBTX port operation that later
    shall be followed by UNSET_INBOUND_SBTX port operation. This last step
    is not currently issued by the driver but it is necessary to make sure
    the retimers are put back to passthrough mode even during enumeration.
    
    If this step is missing the link may not come up properly after
    soft-reboot for example.
    
    For this reason issue UNSET_INBOUND_SBTX after SET_INBOUND_SBTX for
    enumeration and also when the NVM upgrade is run.
    
    Reported-by: Christian Schaubschläger <[email protected]>
    Link: https://lore.kernel.org/linux-usb/[email protected]/
    Cc: [email protected]
    Signed-off-by: Gil Fine <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Add quirk to disable CLx [+ + +]
Author: Sanjay R Mehta <[email protected]>
Date:   Tue Feb 14 13:13:50 2023 -0600

    thunderbolt: Add quirk to disable CLx
    
    commit 7af9da8ce8f9a16221ecd8ba4280582f5bd452fc upstream.
    
    Add QUIRK_NO_CLX to disable the CLx state for hardware which
    doesn't supports it.
    
    AMD Yellow Carp and Pink Sardine don't support CLx state,
    hence disabling it using QUIRK_NO_CLX.
    
    Cc: [email protected]
    Signed-off-by: Sanjay R Mehta <[email protected]>
    Signed-off-by: Basavaraj Natikar <[email protected]>
    [mw: added debug log when the quirk is run]
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Call tb_check_quirks() after initializing adapters [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Fri Feb 3 15:55:41 2023 +0200

    thunderbolt: Call tb_check_quirks() after initializing adapters
    
    commit d2d6ddf188f609861489d5d188d545856a3ed399 upstream.
    
    In order to apply quirks based on certain adapter types move call to
    tb_check_quirks() happen after the adapters are initialized. This should
    not affect the existing quirks.
    
    Cc: [email protected]
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Disable interrupt auto clear for rings [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Fri Mar 10 11:20:50 2023 -0600

    thunderbolt: Disable interrupt auto clear for rings
    
    commit 468c49f44759720a312e52d44a71c3949ed63d7c upstream.
    
    When interrupt auto clear is programmed, any read to the interrupt
    status register will clear all interrupts.  If two interrupts have
    come in before one can be serviced then this will cause lost interrupts.
    
    On AMD USB4 routers this has manifested in odd problems particularly
    with long strings of control tranfers such as reading the DROM via bit
    banging.
    
    Instead of clearing interrupts automatically, clear the bit corresponding
    to the given ring's interrupt in the ISR.
    
    Fixes: 7a1808f82a37 ("thunderbolt: Handle ring interrupt by reading interrupt status register")
    Cc: Sanju Mehta <[email protected]>
    Cc: [email protected]
    Tested-by: Anson Tsao <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Fix memory leak in margining [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Fri Mar 3 11:25:08 2023 +0200

    thunderbolt: Fix memory leak in margining
    
    commit acec726473822bc6b585961f4ca2a11fa7f28341 upstream.
    
    Memory for the usb4->margining needs to be relased for the upstream port
    of the router as well, even though the debugfs directory gets released
    with the router device removal. Fix this.
    
    Fixes: d0f1e0c2a699 ("thunderbolt: Add support for receiver lane margining")
    Cc: [email protected]
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Rename shadowed variables bit to interrupt_bit and auto_clear_bit [+ + +]
Author: Tom Rix <[email protected]>
Date:   Wed Mar 15 18:04:50 2023 -0400

    thunderbolt: Rename shadowed variables bit to interrupt_bit and auto_clear_bit
    
    commit 58cdfe6f58b35f17f56386f5fcf937168a423ad1 upstream.
    
    cppcheck reports
    drivers/thunderbolt/nhi.c:74:7: style: Local variable 'bit' shadows outer variable [shadowVariable]
      int bit;
          ^
    drivers/thunderbolt/nhi.c:66:6: note: Shadowed declaration
     int bit = ring_interrupt_index(ring) & 31;
         ^
    drivers/thunderbolt/nhi.c:74:7: note: Shadow variable
      int bit;
          ^
    For readablity rename the outer to interrupt_bit and the innner
    to auto_clear_bit.
    
    Fixes: 468c49f44759 ("thunderbolt: Disable interrupt auto clear for ring")
    Cc: [email protected]
    Signed-off-by: Tom Rix <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Use const qualifier for `ring_interrupt_index` [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Fri Mar 10 11:20:49 2023 -0600

    thunderbolt: Use const qualifier for `ring_interrupt_index`
    
    commit 1716efdb07938bd6510e1127d02012799112c433 upstream.
    
    `ring_interrupt_index` doesn't change the data for `ring` so mark it as
    const. This is needed by the following patch that disables interrupt
    auto clear for rings.
    
    Cc: Sanju Mehta <[email protected]>
    Cc: [email protected]
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Use scale field when allocating USB3 bandwidth [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Tue Dec 27 11:55:26 2022 +0200

    thunderbolt: Use scale field when allocating USB3 bandwidth
    
    commit c82510b1d87bdebfe916048857d2ef46f1778aa5 upstream.
    
    When tunneling aggregated USB3 (20 Gb/s) the bandwidth values that are
    programmed to the ADP_USB3_CS_2 go higher than 4096 and that does not
    fit anymore to the 12-bit field. Fix this by scaling the value using
    the scale field accordingly.
    
    Fixes: 3b1d8d577ca8 ("thunderbolt: Implement USB3 bandwidth negotiation routines")
    Cc: [email protected]
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tracing/hwlat: Replace sched_setaffinity with set_cpus_allowed_ptr [+ + +]
Author: Costa Shulyupin <[email protected]>
Date:   Thu Mar 16 16:45:35 2023 +0200

    tracing/hwlat: Replace sched_setaffinity with set_cpus_allowed_ptr
    
    [ Upstream commit 71c7a30442b724717a30d5e7d1662ba4904eb3d4 ]
    
    There is a problem with the behavior of hwlat in a container,
    resulting in incorrect output. A warning message is generated:
    "cpumask changed while in round-robin mode, switching to mode none",
    and the tracing_cpumask is ignored. This issue arises because
    the kernel thread, hwlatd, is not a part of the container, and
    the function sched_setaffinity is unable to locate it using its PID.
    Additionally, the task_struct of hwlatd is already known.
    Ultimately, the function set_cpus_allowed_ptr achieves
    the same outcome as sched_setaffinity, but employs task_struct
    instead of PID.
    
    Test case:
    
      # cd /sys/kernel/tracing
      # echo 0 > tracing_on
      # echo round-robin > hwlat_detector/mode
      # echo hwlat > current_tracer
      # unshare --fork --pid bash -c 'echo 1 > tracing_on'
      # dmesg -c
    
    Actual behavior:
    
    [573502.809060] hwlat_detector: cpumask changed while in round-robin mode, switching to mode none
    
    Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
    
    Cc: Masami Hiramatsu <[email protected]>
    Fixes: 0330f7aa8ee63 ("tracing: Have hwlat trace migrate across tracing_cpumask CPUs")
    Signed-off-by: Costa Shulyupin <[email protected]>
    Acked-by: Daniel Bristot de Oliveira <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS583Gen 2 [+ + +]
Author: Yaroslav Furman <[email protected]>
Date:   Sun Mar 12 11:07:45 2023 +0200

    uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS583Gen 2
    
    commit a37eb61b6ec064ac794b8a1e89fd33eb582fe51d upstream.
    
    Just like other JMicron JMS5xx enclosures, it chokes on report-opcodes,
    let's avoid them.
    
    Signed-off-by: Yaroslav Furman <[email protected]>
    Cc: stable <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: cdns3: Fix issue with using incorrect PCI device function [+ + +]
Author: Pawel Laszczak <[email protected]>
Date:   Wed Mar 8 07:44:27 2023 -0500

    usb: cdns3: Fix issue with using incorrect PCI device function
    
    commit 1272fd652a226ccb34e9f47371b6121948048438 upstream.
    
    PCI based platform can have more than two PCI functions.
    USBSS PCI Glue driver during initialization should
    consider only DRD/HOST/DEVICE PCI functions and
    all other should be ignored. This patch adds additional
    condition which causes that only DRD and HOST/DEVICE
    function will be accepted.
    
    cc: <[email protected]>
    Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
    Signed-off-by: Pawel Laszczak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: cdnsp: changes PCI Device ID to fix conflict with CNDS3 driver [+ + +]
Author: Pawel Laszczak <[email protected]>
Date:   Thu Mar 9 01:30:48 2023 -0500

    usb: cdnsp: changes PCI Device ID to fix conflict with CNDS3 driver
    
    commit 96b96b2a567fb34dd41c87e6cf01f6902ce8cae4 upstream.
    
    Patch changes CDNS_DEVICE_ID in USBSSP PCI Glue driver to remove
    the conflict with Cadence USBSS driver.
    
    cc: <[email protected]>
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    Signed-off-by: Pawel Laszczak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: cdnsp: Fixes issue with redundant Status Stage [+ + +]
Author: Pawel Laszczak <[email protected]>
Date:   Tue Mar 7 06:14:20 2023 -0500

    usb: cdnsp: Fixes issue with redundant Status Stage
    
    commit 5bc38d33a5a1209fd4de65101d1ae8255ea12c6e upstream.
    
    In some cases, driver trees to send Status Stage twice.
    The first one from upper layer of gadget usb subsystem and
    second time from controller driver.
    This patch fixes this issue and remove tricky handling of
    SET_INTERFACE from controller driver which is no longer
    needed.
    
    cc: <[email protected]>
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    Signed-off-by: Pawel Laszczak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: chipdea: core: fix return -EINVAL if request role is the same with current role [+ + +]
Author: Xu Yang <[email protected]>
Date:   Fri Mar 17 14:15:15 2023 +0800

    usb: chipdea: core: fix return -EINVAL if request role is the same with current role
    
    commit 3670de80678961eda7fa2220883fc77c16868951 upstream.
    
    It should not return -EINVAL if the request role is the same with current
    role, return non-error and without do anything instead.
    
    Fixes: a932a8041ff9 ("usb: chipidea: core: add sysfs group")
    cc: <[email protected]>
    Acked-by: Peter Chen <[email protected]>
    Signed-off-by: Xu Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: chipidea: core: fix possible concurrent when switch role [+ + +]
Author: Xu Yang <[email protected]>
Date:   Fri Mar 17 14:15:16 2023 +0800

    usb: chipidea: core: fix possible concurrent when switch role
    
    commit 451b15ed138ec15bffbebb58a00ebdd884c3e659 upstream.
    
    The user may call role_store() when driver is handling
    ci_handle_id_switch() which is triggerred by otg event or power lost
    event. Unfortunately, the controller may go into chaos in this case.
    Fix this by protecting it with mutex lock.
    
    Fixes: a932a8041ff9 ("usb: chipidea: core: add sysfs group")
    cc: <[email protected]>
    Acked-by: Peter Chen <[email protected]>
    Signed-off-by: Xu Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: dwc2: drd: fix inconsistent mode if role-switch-default-mode="host" [+ + +]
Author: Ziyang Huang <[email protected]>
Date:   Tue Feb 21 18:30:04 2023 +0800

    usb: dwc2: drd: fix inconsistent mode if role-switch-default-mode="host"
    
    commit 82f5332d3b9872ab5b287e85c57b76d8bb640cd1 upstream.
    
    Some boards might use USB-A female connector for USB ports, however,
    the port could be connected to a dual-mode USB controller, making it
    also behaves as a peripheral device if male-to-male cable is connected.
    
    In this case, the dts looks like this:
    
            &usb0 {
                    status = "okay";
                    dr_mode = "otg";
                    usb-role-switch;
                    role-switch-default-mode = "host";
            };
    
    After boot, dwc2_ovr_init() sets GOTGCTL to GOTGCTL_AVALOVAL and call
    dwc2_force_mode() with parameter host=false, which causes inconsistent
    mode - The hardware is in peripheral mode while the kernel status is
    in host mode.
    
    What we can do now is to call dwc2_drd_role_sw_set() to switch to
    device mode, and everything should work just fine now, even switching
    back to none(default) mode afterwards.
    
    Fixes: e14acb876985 ("usb: dwc2: drd: add role-switch-default-node support")
    Cc: stable <[email protected]>
    Signed-off-by: Ziyang Huang <[email protected]>
    Tested-by: Fabrice Gasnier <[email protected]>
    Acked-by: Minas Harutyunyan <[email protected]>
    Reviewed-by: Amelie Delaunay <[email protected]>
    Link: https://lore.kernel.org/r/SG2PR01MB204837BF68EDB0E343D2A375C9A59@SG2PR01MB2048.apcprd01.prod.exchangelabs.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: dwc2: fix a devres leak in hw_enable upon suspend resume [+ + +]
Author: Fabrice Gasnier <[email protected]>
Date:   Thu Mar 16 09:41:27 2023 +0100

    usb: dwc2: fix a devres leak in hw_enable upon suspend resume
    
    commit f747313249b74f323ddf841a9c8db14d989f296a upstream.
    
    Each time the platform goes to low power, PM suspend / resume routines
    call: __dwc2_lowlevel_hw_enable -> devm_add_action_or_reset().
    This adds a new devres each time.
    This may also happen at runtime, as dwc2_lowlevel_hw_enable() can be
    called from udc_start().
    
    This can be seen with tracing:
    - echo 1 > /sys/kernel/debug/tracing/events/dev/devres_log/enable
    - go to low power
    - cat /sys/kernel/debug/tracing/trace
    
    A new "ADD" entry is found upon each low power cycle:
    ... devres_log: 49000000.usb-otg ADD 82a13bba devm_action_release (8 bytes)
    ... devres_log: 49000000.usb-otg ADD 49889daf devm_action_release (8 bytes)
    ...
    
    A second issue is addressed here:
    - regulator_bulk_enable() is called upon each PM cycle (suspend/resume).
    - regulator_bulk_disable() never gets called.
    
    So the reference count for these regulators constantly increase, by one
    upon each low power cycle, due to missing regulator_bulk_disable() call
    in __dwc2_lowlevel_hw_disable().
    
    The original fix that introduced the devm_add_action_or_reset() call,
    fixed an issue during probe, that happens due to other errors in
    dwc2_driver_probe() -> dwc2_core_reset(). Then the probe fails without
    disabling regulators, when dr_mode == USB_DR_MODE_PERIPHERAL.
    
    Rather fix the error path: disable all the low level hardware in the
    error path, by using the "hsotg->ll_hw_enabled" flag. Checking dr_mode
    has been introduced to avoid a dual call to dwc2_lowlevel_hw_disable().
    "ll_hw_enabled" should achieve the same (and is used currently in the
    remove() routine).
    
    Fixes: 54c196060510 ("usb: dwc2: Always disable regulators on driver teardown")
    Fixes: 33a06f1300a7 ("usb: dwc2: Fix error path in gadget registration")
    Cc: stable <[email protected]>
    Signed-off-by: Fabrice Gasnier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: dwc2: fix a race, don't power off/on phy for dual-role mode [+ + +]
Author: Fabrice Gasnier <[email protected]>
Date:   Wed Mar 15 15:44:33 2023 +0100

    usb: dwc2: fix a race, don't power off/on phy for dual-role mode
    
    commit 5021383242ada277a38bd052a4c12ed4707faccb upstream.
    
    When in dual role mode (dr_mode == USB_DR_MODE_OTG), platform probe
    successively basically calls:
    - dwc2_gadget_init()
    - dwc2_hcd_init()
    - dwc2_lowlevel_hw_disable() since recent change [1]
    - usb_add_gadget_udc()
    
    The PHYs (and so the clocks it may provide) shouldn't be disabled for all
    SoCs, in OTG mode, as the HCD part has been initialized.
    
    On STM32 this creates some weird race condition upon boot, when:
    - initially attached as a device, to a HOST
    - and there is a gadget script invoked to setup the device part.
    Below issue becomes systematic, as long as the gadget script isn't
    started by userland: the hardware PHYs (and so the clocks provided by the
    PHYs) remains disabled.
    It ends up in having an endless interrupt storm, before the watchdog
    resets the platform.
    
    [   16.924163] dwc2 49000000.usb-otg: EPs: 9, dedicated fifos, 952 entries in SPRAM
    [   16.962704] dwc2 49000000.usb-otg: DWC OTG Controller
    [   16.966488] dwc2 49000000.usb-otg: new USB bus registered, assigned bus number 2
    [   16.974051] dwc2 49000000.usb-otg: irq 77, io mem 0x49000000
    [   17.032170] hub 2-0:1.0: USB hub found
    [   17.042299] hub 2-0:1.0: 1 port detected
    [   17.175408] dwc2 49000000.usb-otg: Mode Mismatch Interrupt: currently in Host mode
    [   17.181741] dwc2 49000000.usb-otg: Mode Mismatch Interrupt: currently in Host mode
    [   17.189303] dwc2 49000000.usb-otg: Mode Mismatch Interrupt: currently in Host mode
    ...
    
    The host part is also not functional, until the gadget part is configured.
    
    The HW may only be disabled for peripheral mode (original init), e.g.
    dr_mode == USB_DR_MODE_PERIPHERAL, until the gadget driver initializes.
    
    But when in USB_DR_MODE_OTG, the HW should remain enabled, as the HCD part
    is able to run, while the gadget part isn't necessarily configured.
    
    I don't fully get the of purpose the original change, that claims disabling
    the hardware is missing. It creates conditions on SOCs using the PHY
    initialization to be completely non working in OTG mode. Original
    change [1] should be reworked to be platform specific.
    
    [1] https://lore.kernel.org/r/20221206-dwc2-gadget-dual-role-v1-2-36515e1092cd@theobroma-systems.com
    
    Fixes: ade23d7b7ec5 ("usb: dwc2: power on/off phy for peripheral mode in dual-role mode")
    Cc: stable <[email protected]>
    Signed-off-by: Fabrice Gasnier <[email protected]>
    Reviewed-by: Quentin Schulz <[email protected]>
    Tested-by: Quentin Schulz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: dwc3: gadget: Add 1ms delay after end transfer command without IOC [+ + +]
Author: Wesley Cheng <[email protected]>
Date:   Mon Mar 6 12:05:57 2023 -0800

    usb: dwc3: gadget: Add 1ms delay after end transfer command without IOC
    
    commit d8a2bb4eb75866275b5cf7de2e593ac3449643e2 upstream.
    
    Previously, there was a 100uS delay inserted after issuing an end transfer
    command for specific controller revisions.  This was due to the fact that
    there was a GUCTL2 bit field which enabled synchronous completion of the
    end transfer command once the CMDACT bit was cleared in the DEPCMD
    register.  Since this bit does not exist for all controller revisions and
    the current implementation heavily relies on utizling the EndTransfer
    command completion interrupt, add the delay back in for uses where the
    interrupt on completion bit is not set, and increase the duration to 1ms
    for the controller to complete the command.
    
    An issue was seen where the USB request buffer was unmapped while the DWC3
    controller was still accessing the TRB.  However, it was confirmed that the
    end transfer command was successfully submitted. (no end transfer timeout)
    In situations, such as dwc3_gadget_soft_disconnect() and
    __dwc3_gadget_ep_disable(), the dwc3_remove_request() is utilized, which
    will issue the end transfer command, and follow up with
    dwc3_gadget_giveback().  At least for the USB ep disable path, it is
    required for any pending and started requests to be completed and returned
    to the function driver in the same context of the disable call.  Without
    the GUCTL2 bit, it is not ensured that the end transfer is completed before
    the buffers are unmapped.
    
    Fixes: cf2f8b63f7f1 ("usb: dwc3: gadget: Remove END_TRANSFER delay")
    Cc: stable <[email protected]>
    Signed-off-by: Wesley Cheng <[email protected]>
    Acked-by: Thinh Nguyen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: gadget: u_audio: don't let userspace block driver unbind [+ + +]
Author: Alvin Šipraga <[email protected]>
Date:   Thu Mar 2 17:36:47 2023 +0100

    usb: gadget: u_audio: don't let userspace block driver unbind
    
    commit 6c67ed9ad9b83e453e808f9b31a931a20a25629b upstream.
    
    In the unbind callback for f_uac1 and f_uac2, a call to snd_card_free()
    via g_audio_cleanup() will disconnect the card and then wait for all
    resources to be released, which happens when the refcount falls to zero.
    Since userspace can keep the refcount incremented by not closing the
    relevant file descriptor, the call to unbind may block indefinitely.
    This can cause a deadlock during reboot, as evidenced by the following
    blocked task observed on my machine:
    
      task:reboot  state:D stack:0   pid:2827  ppid:569    flags:0x0000000c
      Call trace:
       __switch_to+0xc8/0x140
       __schedule+0x2f0/0x7c0
       schedule+0x60/0xd0
       schedule_timeout+0x180/0x1d4
       wait_for_completion+0x78/0x180
       snd_card_free+0x90/0xa0
       g_audio_cleanup+0x2c/0x64
       afunc_unbind+0x28/0x60
       ...
       kernel_restart+0x4c/0xac
       __do_sys_reboot+0xcc/0x1ec
       __arm64_sys_reboot+0x28/0x30
       invoke_syscall+0x4c/0x110
       ...
    
    The issue can also be observed by opening the card with arecord and
    then stopping the process through the shell before unbinding:
    
      # arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null
      Recording WAVE '/dev/null' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
      ^Z[1]+  Stopped                    arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null
      # echo gadget.0 > /sys/bus/gadget/drivers/configfs-gadget/unbind
      (observe that the unbind command never finishes)
    
    Fix the problem by using snd_card_free_when_closed() instead, which will
    still disconnect the card as desired, but defer the task of freeing the
    resources to the core once userspace closes its file descriptor.
    
    Fixes: 132fcb460839 ("usb: gadget: Add Audio Class 2.0 Driver")
    Cc: [email protected]
    Signed-off-by: Alvin Šipraga <[email protected]>
    Reviewed-by: Ruslan Bilovol <[email protected]>
    Reviewed-by: John Keeping <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: misc: onboard-hub: add support for Microchip USB2517 USB 2.0 hub [+ + +]
Author: Alexander Stein <[email protected]>
Date:   Thu Feb 23 08:39:20 2023 +0100

    usb: misc: onboard-hub: add support for Microchip USB2517 USB 2.0 hub
    
    commit f7c13cb48e85538709850589b496c4ddb3d3898e upstream.
    
    Add support for Microchip USB2517 USB 2.0 hub to the onboard usb hub
    driver. Adopt the generic usb-device compatible ("usbVID,PID").
    This hub has the same reset timings as USB2514, so reuse that one.
    There is also an USB2517I which just has industrial temperature range.
    
    Signed-off-by: Alexander Stein <[email protected]>
    Cc: stable <[email protected]>
    Acked-by: Matthias Kaehlcke <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: tcpm: fix create duplicate source-capabilities file [+ + +]
Author: Xu Yang <[email protected]>
Date:   Wed Feb 15 13:49:51 2023 +0800

    usb: typec: tcpm: fix create duplicate source-capabilities file
    
    commit a826492fc9dfe32afd70fff93955ae8174bbf14b upstream.
    
    The kernel will dump in the below cases:
    sysfs: cannot create duplicate filename
    '/devices/virtual/usb_power_delivery/pd1/source-capabilities'
    
    1. After soft reset has completed, an Explicit Contract negotiation occurs.
    The sink device will receive source capabilitys again. This will cause
    a duplicate source-capabilities file be created.
    2. Power swap twice on a device that is initailly sink role.
    
    This will unregister existing capabilities when above cases occurs.
    
    Fixes: 8203d26905ee ("usb: typec: tcpm: Register USB Power Delivery Capabilities")
    cc: <[email protected]>
    Signed-off-by: Xu Yang <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: tcpm: fix warning when handle discover_identity message [+ + +]
Author: Xu Yang <[email protected]>
Date:   Thu Feb 16 11:15:15 2023 +0800

    usb: typec: tcpm: fix warning when handle discover_identity message
    
    commit abfc4fa28f0160df61c7149567da4f6494dfb488 upstream.
    
    Since both source and sink device can send discover_identity message in
    PD3, kernel may dump below warning:
    
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 169 at drivers/usb/typec/tcpm/tcpm.c:1446 tcpm_queue_vdm+0xe0/0xf0
    Modules linked in:
    CPU: 0 PID: 169 Comm: 1-0050 Not tainted 6.1.1-00038-g6a3c36cf1da2-dirty #567
    Hardware name: NXP i.MX8MPlus EVK board (DT)
    pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : tcpm_queue_vdm+0xe0/0xf0
    lr : tcpm_queue_vdm+0x2c/0xf0
    sp : ffff80000c19bcd0
    x29: ffff80000c19bcd0 x28: 0000000000000001 x27: ffff0000d11c8ab8
    x26: ffff0000d11cc000 x25: 0000000000000000 x24: 00000000ff008081
    x23: 0000000000000001 x22: 00000000ff00a081 x21: ffff80000c19bdbc
    x20: 0000000000000000 x19: ffff0000d11c8080 x18: ffffffffffffffff
    x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000d716f580
    x14: 0000000000000001 x13: ffff0000d716f507 x12: 0000000000000001
    x11: 0000000000000000 x10: 0000000000000020 x9 : 00000000000ee098
    x8 : 00000000ffffffff x7 : 000000000000001c x6 : ffff0000d716f580
    x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
    x2 : ffff80000c19bdbc x1 : 00000000ff00a081 x0 : 0000000000000004
    Call trace:
    tcpm_queue_vdm+0xe0/0xf0
    tcpm_pd_rx_handler+0x340/0x1ab0
    kthread_worker_fn+0xcc/0x18c
    kthread+0x10c/0x110
    ret_from_fork+0x10/0x20
    ---[ end trace 0000000000000000 ]---
    
    Below sequences may trigger this warning:
    
    tcpm_send_discover_work(work)
      tcpm_send_vdm(port, USB_SID_PD, CMD_DISCOVER_IDENT, NULL, 0);
       tcpm_queue_vdm(port, header, data, count);
        port->vdm_state = VDM_STATE_READY;
    
    vdm_state_machine_work(work);
                            <-- received discover_identity from partner
     vdm_run_state_machine(port);
      port->vdm_state = VDM_STATE_SEND_MESSAGE;
       mod_vdm_delayed_work(port, x);
    
    tcpm_pd_rx_handler(work);
     tcpm_pd_data_request(port, msg);
      tcpm_handle_vdm_request(port, msg->payload, cnt);
       tcpm_queue_vdm(port, response[0], &response[1], rlen - 1);
    --> WARN_ON(port->vdm_state > VDM_STATE_DONE);
    
    For this case, the state machine could still send out discover
    identity message later if we skip current discover_identity message.
    So we should handle the received message firstly and override the pending
    discover_identity message without warning in this case. Then, a delayed
    send_discover work will send discover_identity message again.
    
    Fixes: e00943e91678 ("usb: typec: tcpm: PD3.0 sinks can send Discover Identity even in device mode")
    cc: <[email protected]>
    Signed-off-by: Xu Yang <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: ucsi: Fix NULL pointer deref in ucsi_connector_change() [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Wed Mar 8 16:42:42 2023 +0100

    usb: ucsi: Fix NULL pointer deref in ucsi_connector_change()
    
    commit f87fb985452ab2083967103ac00bfd68fb182764 upstream.
    
    When ucsi_init() fails, ucsi->connector is NULL, yet in case of
    ucsi_acpi we may still get events which cause the ucs_acpi code to call
    ucsi_connector_change(), which then derefs the NULL ucsi->connector
    pointer.
    
    Fix this by not setting ucsi->ntfy inside ucsi_init() until ucsi_init()
    has succeeded, so that ucsi_connector_change() ignores the events
    because UCSI_ENABLE_NTFY_CONNECTOR_CHANGE is not set in the ntfy mask.
    
    Fixes: bdc62f2bae8f ("usb: typec: ucsi: Simplified registration and I/O API")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217106
    Cc: [email protected]
    Reviewed-by: Heikki Krogerus <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: ucsi_acpi: Increase the command completion timeout [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Wed Mar 8 16:42:44 2023 +0100

    usb: ucsi_acpi: Increase the command completion timeout
    
    commit 02d210f434249a7edbc160969b75df030dc6934d upstream.
    
    Commit 130a96d698d7 ("usb: typec: ucsi: acpi: Increase command
    completion timeout value") increased the timeout from 5 seconds
    to 60 seconds due to issues related to alternate mode discovery.
    
    After the alternate mode discovery switch to polled mode
    the timeout was reduced, but instead of being set back to
    5 seconds it was reduced to 1 second.
    
    This is causing problems when using a Lenovo ThinkPad X1 yoga gen7
    connected over Type-C to a LG 27UL850-W (charging DP over Type-C).
    
    When the monitor is already connected at boot the following error
    is logged: "PPM init failed (-110)", /sys/class/typec is empty and
    on unplugging the NULL pointer deref fixed earlier in this series
    happens.
    
    When the monitor is connected after boot the following error
    is logged instead: "GET_CONNECTOR_STATUS failed (-110)".
    
    Setting the timeout back to 5 seconds fixes both cases.
    
    Fixes: e08065069fc7 ("usb: typec: ucsi: acpi: Reduce the command completion timeout")
    Cc: [email protected]
    Reviewed-by: Heikki Krogerus <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
wifi: mac80211: fix qos on mesh interfaces [+ + +]
Author: Felix Fietkau <[email protected]>
Date:   Tue Mar 14 10:59:50 2023 +0100

    wifi: mac80211: fix qos on mesh interfaces
    
    commit 4e348c6c6e23491ae6eb5e077848a42d0562339c upstream.
    
    When ieee80211_select_queue is called for mesh, the sta pointer is usually
    NULL, since the nexthop is looked up much later in the tx path.
    Explicitly check for unicast address in that case in order to make qos work
    again.
    
    Cc: [email protected]
    Fixes: 50e2ab392919 ("wifi: mac80211: fix queue selection for mesh/OCB interfaces")
    Signed-off-by: Felix Fietkau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: mac80211: Serialize ieee80211_handle_wake_tx_queue() [+ + +]
Author: Alexander Wetzel <[email protected]>
Date:   Tue Mar 14 22:11:22 2023 +0100

    wifi: mac80211: Serialize ieee80211_handle_wake_tx_queue()
    
    commit 007ae9b268ba7553e479608cf9735d3c4672a2ab upstream.
    
    ieee80211_handle_wake_tx_queue must not run concurrent multiple times.
    It calls ieee80211_txq_schedule_start() and the drivers migrated to iTXQ
    do not expect overlapping drv_tx() calls.
    
    This fixes 'c850e31f79f0 ("wifi: mac80211: add internal handler for
    wake_tx_queue")', which introduced ieee80211_handle_wake_tx_queue.
    Drivers started to use it with 'a790cc3a4fad ("wifi: mac80211: add
    wake_tx_queue callback to drivers")'.
    But only after fixing an independent bug with
    '4444bc2116ae ("wifi: mac80211: Proper mark iTXQs for resumption")'
    problematic concurrent calls really happened and exposed the initial
    issue.
    
    Fixes: c850e31f79f0 ("wifi: mac80211: add internal handler for wake_tx_queue")
    Reported-by: Thomas Mann <[email protected]>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217119
    Link: https://lore.kernel.org/r/[email protected]/
    Link: https://lore.kernel.org/r/[email protected]>
    CC: <[email protected]>
    Signed-off-by: Alexander Wetzel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [add missing spin_lock_init() noticed by Felix]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: mt76: connac: do not check WED status for non-mmio devices [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Mon Mar 6 18:42:51 2023 +0100

    wifi: mt76: connac: do not check WED status for non-mmio devices
    
    [ Upstream commit 5683e1488aa9b0805a9403d215e48fed29d6d923 ]
    
    WED is supported just for mmio devices, so do not check it for usb or
    sdio devices. This patch fixes the crash reported below:
    
    [   21.946627] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d
    [   22.525298] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3)
    [   22.548274] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d
    [   22.557694] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3)
    [   22.565885] wlp0s3u1i3: authenticated
    [   22.569502] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 1/3)
    [   22.578966] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=30 aid=3)
    [   22.579113] wlp0s3u1i3: c4:41:1e:f5:2b:1d rejected association temporarily; comeback duration 1000 TU (1024 ms)
    [   23.649518] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 2/3)
    [   23.752528] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=0 aid=3)
    [   23.797450] wlp0s3u1i3: associated
    [   24.959527] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
    [   24.959640] BUG: unable to handle page fault for address: ffff88800c223200
    [   24.959706] #PF: supervisor instruction fetch in kernel mode
    [   24.959788] #PF: error_code(0x0011) - permissions violation
    [   24.959846] PGD 2c01067 P4D 2c01067 PUD 2c02067 PMD c2a8063 PTE 800000000c223163
    [   24.959957] Oops: 0011 [#1] PREEMPT SMP
    [   24.960009] CPU: 0 PID: 391 Comm: wpa_supplicant Not tainted 6.2.0-kvm #18
    [   24.960089] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
    [   24.960191] RIP: 0010:0xffff88800c223200
    [   24.960446] RSP: 0018:ffffc90000ff7698 EFLAGS: 00010282
    [   24.960513] RAX: ffff888028397010 RBX: ffff88800c26e630 RCX: 0000000000000058
    [   24.960598] RDX: ffff88800c26f844 RSI: 0000000000000006 RDI: ffff888028397010
    [   24.960682] RBP: ffff88800ea72f00 R08: 18b873fbab2b964c R09: be06b38235f3c63c
    [   24.960766] R10: 18b873fbab2b964c R11: be06b38235f3c63c R12: 0000000000000001
    [   24.960853] R13: ffff88800c26f84c R14: ffff8880063f0ff8 R15: ffff88800c26e644
    [   24.960950] FS:  00007effcea327c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
    [   24.961036] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   24.961106] CR2: ffff88800c223200 CR3: 000000000eaa2000 CR4: 00000000000006b0
    [   24.961190] Call Trace:
    [   24.961219]  <TASK>
    [   24.961245]  ? mt76_connac_mcu_add_key+0x2cf/0x310
    [   24.961313]  ? mt7921_set_key+0x150/0x200
    [   24.961365]  ? drv_set_key+0xa9/0x1b0
    [   24.961418]  ? ieee80211_key_enable_hw_accel+0xd9/0x240
    [   24.961485]  ? ieee80211_key_replace+0x3f3/0x730
    [   24.961541]  ? crypto_shash_setkey+0x89/0xd0
    [   24.961597]  ? ieee80211_key_link+0x2d7/0x3a0
    [   24.961664]  ? crypto_aead_setauthsize+0x31/0x50
    [   24.961730]  ? sta_info_hash_lookup+0xa6/0xf0
    [   24.961785]  ? ieee80211_add_key+0x1fc/0x250
    [   24.961842]  ? rdev_add_key+0x41/0x140
    [   24.961882]  ? nl80211_parse_key+0x6c/0x2f0
    [   24.961940]  ? nl80211_new_key+0x24a/0x290
    [   24.961984]  ? genl_rcv_msg+0x36c/0x3a0
    [   24.962036]  ? rdev_mod_link_station+0xe0/0xe0
    [   24.962102]  ? nl80211_set_key+0x410/0x410
    [   24.962143]  ? nl80211_pre_doit+0x200/0x200
    [   24.962187]  ? genl_bind+0xc0/0xc0
    [   24.962217]  ? netlink_rcv_skb+0xaa/0xd0
    [   24.962259]  ? genl_rcv+0x24/0x40
    [   24.962300]  ? netlink_unicast+0x224/0x2f0
    [   24.962345]  ? netlink_sendmsg+0x30b/0x3d0
    [   24.962388]  ? ____sys_sendmsg+0x109/0x1b0
    [   24.962388]  ? ____sys_sendmsg+0x109/0x1b0
    [   24.962440]  ? __import_iovec+0x2e/0x110
    [   24.962482]  ? ___sys_sendmsg+0xbe/0xe0
    [   24.962525]  ? mod_objcg_state+0x25c/0x330
    [   24.962576]  ? __dentry_kill+0x19e/0x1d0
    [   24.962618]  ? call_rcu+0x18f/0x270
    [   24.962660]  ? __dentry_kill+0x19e/0x1d0
    [   24.962702]  ? __x64_sys_sendmsg+0x70/0x90
    [   24.962744]  ? do_syscall_64+0x3d/0x80
    [   24.962796]  ? exit_to_user_mode_prepare+0x1b/0x70
    [   24.962852]  ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [   24.962913]  </TASK>
    [   24.962939] Modules linked in:
    [   24.962981] CR2: ffff88800c223200
    [   24.963022] ---[ end trace 0000000000000000 ]---
    [   24.963087] RIP: 0010:0xffff88800c223200
    [   24.963323] RSP: 0018:ffffc90000ff7698 EFLAGS: 00010282
    [   24.963376] RAX: ffff888028397010 RBX: ffff88800c26e630 RCX: 0000000000000058
    [   24.963458] RDX: ffff88800c26f844 RSI: 0000000000000006 RDI: ffff888028397010
    [   24.963538] RBP: ffff88800ea72f00 R08: 18b873fbab2b964c R09: be06b38235f3c63c
    [   24.963622] R10: 18b873fbab2b964c R11: be06b38235f3c63c R12: 0000000000000001
    [   24.963705] R13: ffff88800c26f84c R14: ffff8880063f0ff8 R15: ffff88800c26e644
    [   24.963788] FS:  00007effcea327c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
    [   24.963871] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   24.963941] CR2: ffff88800c223200 CR3: 000000000eaa2000 CR4: 00000000000006b0
    [   24.964018] note: wpa_supplicant[391] exited with irqs disabled
    
    Fixes: d1369e515efe ("wifi: mt76: connac: introduce mt76_connac_mcu_sta_wed_update utility routine")
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Acked-by: Felix Fietkau <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/c42168429453474213fa8244bf4b069de4531f40.1678124335.git.lorenzo@kernel.org
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: do not run mt76_unregister_device() on unregistered hw [+ + +]
Author: Lorenzo Bianconi <[email protected]>
Date:   Thu Feb 23 00:10:25 2023 +0100

    wifi: mt76: do not run mt76_unregister_device() on unregistered hw
    
    [ Upstream commit 41130c32f3a18fcc930316da17f3a5f3bc326aa1 ]
    
    Trying to probe a mt7921e pci card without firmware results in a
    successful probe where ieee80211_register_hw hasn't been called. When
    removing the driver, ieee802111_unregister_hw is called unconditionally
    leading to a kernel NULL pointer dereference.
    Fix the issue running mt76_unregister_device routine just for registered
    hw.
    
    Link: https://bugs.debian.org/1029116
    Link: https://bugs.kali.org/view.php?id=8140
    Reported-by: Stuart Hayhurst <[email protected]>
    Fixes: 1c71e03afe4b ("mt76: mt7921: move mt7921_init_hw in a dedicated work")
    Tested-by: Helmut Grohne <[email protected]>
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/be3457d82f4e44bb71a22b2b5db27b644a37b1e1.1677107277.git.lorenzo@kernel.org
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/fpu/xstate: Prevent false-positive warning in __copy_xstate_uabi_buf() [+ + +]
Author: Chang S. Bae <[email protected]>
Date:   Mon Feb 27 13:05:03 2023 -0800

    x86/fpu/xstate: Prevent false-positive warning in __copy_xstate_uabi_buf()
    
    commit b15888840207c2bfe678dd1f68a32db54315e71f upstream.
    
    __copy_xstate_to_uabi_buf() copies either from the tasks XSAVE buffer
    or from init_fpstate into the ptrace buffer. Dynamic features, like
    XTILEDATA, have an all zeroes init state and are not saved in
    init_fpstate, which means the corresponding bit is not set in the
    xfeatures bitmap of the init_fpstate header.
    
    But __copy_xstate_to_uabi_buf() retrieves addresses for both the tasks
    xstate and init_fpstate unconditionally via __raw_xsave_addr().
    
    So if the tasks XSAVE buffer has a dynamic feature set, then the
    address retrieval for init_fpstate triggers the warning in
    __raw_xsave_addr() which checks the feature bit in the init_fpstate
    header.
    
    Remove the address retrieval from init_fpstate for extended features.
    They have an all zeroes init state so init_fpstate has zeros for them.
    Then zeroing the user buffer for the init state is the same as copying
    them from init_fpstate.
    
    Fixes: 2308ee57d93d ("x86/fpu/amx: Enable the AMX feature in 64-bit mode")
    Reported-by: Mingwei Zhang <[email protected]>
    Link: https://lore.kernel.org/kvm/[email protected]/
    Signed-off-by: Chang S. Bae <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Tested-by: Mingwei Zhang <[email protected]>
    Link: https://lore.kernel.org/all/20230227210504.18520-2-chang.seok.bae%40intel.com
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/mm: Do not shuffle CPU entry areas without KASLR [+ + +]
Author: Michal Koutný <[email protected]>
Date:   Mon Mar 6 20:31:44 2023 +0100

    x86/mm: Do not shuffle CPU entry areas without KASLR
    
    commit a3f547addcaa10df5a226526bc9e2d9a94542344 upstream.
    
    The commit 97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area") fixed
    an omission of KASLR on CPU entry areas. It doesn't take into account
    KASLR switches though, which may result in unintended non-determinism
    when a user wants to avoid it (e.g. debugging, benchmarking).
    
    Generate only a single combination of CPU entry areas offsets -- the
    linear array that existed prior randomization when KASLR is turned off.
    
    Since we have 3f148f331814 ("x86/kasan: Map shadow for percpu pages on
    demand") and followups, we can use the more relaxed guard
    kasrl_enabled() (in contrast to kaslr_memory_enabled()).
    
    Fixes: 97e3d26b5e5f ("x86/mm: Randomize per-cpu entry area")
    Signed-off-by: Michal Koutný <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/all/20230306193144.24605-1-mkoutny%40suse.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
xirc2ps_cs: Fix use after free bug in xirc2ps_detach [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Fri Mar 17 00:15:26 2023 +0800

    xirc2ps_cs: Fix use after free bug in xirc2ps_detach
    
    [ Upstream commit e8d20c3ded59a092532513c9bd030d1ea66f5f44 ]
    
    In xirc2ps_probe, the local->tx_timeout_task was bounded
    with xirc2ps_tx_timeout_task. When timeout occurs,
    it will call xirc_tx_timeout->schedule_work to start the
    work.
    
    When we call xirc2ps_detach to remove the driver, there
    may be a sequence as follows:
    
    Stop responding to timeout tasks and complete scheduled
    tasks before cleanup in xirc2ps_detach, which will fix
    the problem.
    
    CPU0                  CPU1
    
                        |xirc2ps_tx_timeout_task
    xirc2ps_detach      |
      free_netdev       |
        kfree(dev);     |
                        |
                        | do_reset
                        |   //use dev
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Zheng Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
xsk: Add missing overflow check in xdp_umem_reg [+ + +]
Author: Kal Conley <[email protected]>
Date:   Wed Mar 8 18:40:13 2023 +0100

    xsk: Add missing overflow check in xdp_umem_reg
    
    [ Upstream commit c7df4813b149362248d6ef7be41a311e27bf75fe ]
    
    The number of chunks can overflow u32. Make sure to return -EINVAL on
    overflow. Also remove a redundant u32 cast assigning umem->npgs.
    
    Fixes: bbff2f321a86 ("xsk: new descriptor addressing scheme")
    Signed-off-by: Kal Conley <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Magnus Karlsson <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>