May 2024 - Linux-stable-mirror

[PATCH 6.1] arm64: atomics: lse: remove stale dependency on JUMP_LABEL

by Oleksandr Tymoshenko

From: Mark Rutland <mark.rutland(a)arm.com> [ Upstream commit 657eef0a5420a02c02945ed8c87f2ddcbd255772 ] Currently CONFIG_ARM64_USE_LSE_ATOMICS depends upon CONFIG_JUMP_LABEL, as the inline atomics were indirected with a static branch. However, since commit: 21fb26bfb01ffe0d ("arm64: alternatives: add alternative_has_feature_*()") ... we use an alternative_branch (which is always available) rather than a static branch, and hence the dependency is unnecessary. Remove the stale dependency, along with the stale include. This will allow the use of LSE atomics in kernels built with CONFIG_JUMP_LABEL=n, and reduces the risk of circular header dependencies via <asm/lse.h>. Signed-off-by: Mark Rutland <mark.rutland(a)arm.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Link: https://lore.kernel.org/r/20221114125424.2998268-1-mark.rutland@arm.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Oleksandr Tymoshenko <ovt(a)google.com> --- arch/arm64/Kconfig | 1 - arch/arm64/include/asm/lse.h | 1 - 2 files changed, 2 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index c15f71501c6c..044b98a62f7b 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1752,7 +1752,6 @@ config ARM64_LSE_ATOMICS config ARM64_USE_LSE_ATOMICS bool "Atomic instructions" - depends on JUMP_LABEL default y help As part of the Large System Extensions, ARMv8.1 introduces new diff --git a/arch/arm64/include/asm/lse.h b/arch/arm64/include/asm/lse.h index c503db8e73b0..f99d74826a7e 100644 --- a/arch/arm64/include/asm/lse.h +++ b/arch/arm64/include/asm/lse.h @@ -10,7 +10,6 @@ #include <linux/compiler_types.h> #include <linux/export.h> -#include <linux/jump_label.h> #include <linux/stringify.h> #include <asm/alternative.h> #include <asm/alternative-macros.h> --- base-commit: 4078fa637fcd80c8487680ec2e4ef7c58308e9aa change-id: 20240521-lse-atomics-6-1-b0960e206035 Best regards, -- Oleksandr Tymoshenko <ovt(a)google.com>

22 minutes

1
0
0 0

[PATCH v2] Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot

by Zijun Hu

Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") will cause below regression issue: BT can't be enabled after below steps: cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA6390. The commit is to fix a use-after-free issue within qca_serdev_shutdown() by adding condition to avoid the serdev is flushed or wrote after closed but also introduces this regression issue regarding above steps since the VSC is not sent to reset controller during warm reboot. Fixed by sending the VSC to reset controller within qca_serdev_shutdown() once BT was ever enabled, and the use-after-free issue is also fixed by this change since the serdev is still opened before it is flushed or wrote. Verified by the reported machine Dell XPS 13 9310 laptop over below two kernel commits: commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of bluetooth-next tree. commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of linus mainline tree. Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") Cc: stable(a)vger.kernel.org Reported-by: Wren Turkal <wt(a)penguintechs.org> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> Tested-by: Wren Turkal <wt(a)penguintechs.org> --- V1 -> V2: Add comments and more commit messages V1 discussion link: https://lore.kernel.org/linux-bluetooth/d553edef-c1a4-4d52-a892-715549d31eb… drivers/bluetooth/hci_qca.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 0c9c9ee56592..9a0bc86f9aac 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2450,15 +2450,27 @@ static void qca_serdev_shutdown(struct device *dev) struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev); struct hci_uart *hu = &qcadev->serdev_hu; struct hci_dev *hdev = hu->hdev; - struct qca_data *qca = hu->priv; const u8 ibs_wake_cmd[] = { 0xFD }; const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 }; if (qcadev->btsoc_type == QCA_QCA6390) { - if (test_bit(QCA_BT_OFF, &qca->flags) || - !test_bit(HCI_RUNNING, &hdev->flags)) + /* The purpose of sending the VSC is to reset SOC into a initial + * state and the state will ensure next hdev->setup() success. + * if HCI_QUIRK_NON_PERSISTENT_SETUP is set, it means that + * hdev->setup() can do its job regardless of SoC state, so + * don't need to send the VSC. + * if HCI_SETUP is set, it means that hdev->setup() was never + * invoked and the SOC is already in the initial state, so + * don't also need to send the VSC. + */ + if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks) || + hci_dev_test_flag(hdev, HCI_SETUP)) return; + /* The serdev must be in open state when conrol logic arrives + * here, so also fix the use-after-free issue caused by that + * the serdev is flushed or wrote after it is closed. + */ serdev_device_write_flush(serdev); ret = serdev_device_write_buf(serdev, ibs_wake_cmd, sizeof(ibs_wake_cmd)); -- 2.7.4

23 minutes

3
3
0 0

[PATCH] dt-bindings: dma: fsl-edma: fix dma-channels constraints

by Krzysztof Kozlowski

dma-channels is a number, not a list. Apply proper constraints on the actual number. Fixes: 6eb439dff645 ("dt-bindings: fsl-dma: fsl-edma: add edma3 compatible string") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Documentation/devicetree/bindings/dma/fsl,edma.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml index 825f4715499e..9ef99eb54104 100644 --- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml +++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml @@ -60,8 +60,8 @@ properties: - 3 dma-channels: - minItems: 1 - maxItems: 64 + minimum: 1 + maximum: 64 clocks: minItems: 1 -- 2.43.0

51 minutes

3
2
0 0

[PATCH] usb: typec: tcpm: Ignore received Hard Reset in TOGGLING state

by Kyle Tso

Similar to what fixed in Commit a6fe37f428c1 ("usb: typec: tcpm: Skip hard reset when in error recovery"), the handling of the received Hard Reset has to be skipped during TOGGLING state. [ 4086.021288] VBUS off [ 4086.021295] pending state change SNK_READY -> SNK_UNATTACHED @ 650 ms [rev2 NONE_AMS] [ 4086.022113] VBUS VSAFE0V [ 4086.022117] state change SNK_READY -> SNK_UNATTACHED [rev2 NONE_AMS] [ 4086.022447] VBUS off [ 4086.022450] state change SNK_UNATTACHED -> SNK_UNATTACHED [rev2 NONE_AMS] [ 4086.023060] VBUS VSAFE0V [ 4086.023064] state change SNK_UNATTACHED -> SNK_UNATTACHED [rev2 NONE_AMS] [ 4086.023070] disable BIST MODE TESTDATA [ 4086.023766] disable vbus discharge ret:0 [ 4086.023911] Setting usb_comm capable false [ 4086.028874] Setting voltage/current limit 0 mV 0 mA [ 4086.028888] polarity 0 [ 4086.030305] Requesting mux state 0, usb-role 0, orientation 0 [ 4086.033539] Start toggling [ 4086.038496] state change SNK_UNATTACHED -> TOGGLING [rev2 NONE_AMS] // This Hard Reset is unexpected [ 4086.038499] Received hard reset [ 4086.038501] state change TOGGLING -> HARD_RESET_START [rev2 HARD_RESET] Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable(a)vger.kernel.org Signed-off-by: Kyle Tso <kyletso(a)google.com> --- drivers/usb/typec/tcpm/tcpm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 8a1af08f71b6..9c1cb8c11bd6 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -6172,6 +6172,7 @@ static void _tcpm_pd_hard_reset(struct tcpm_port *port) port->tcpc->set_bist_data(port->tcpc, false); switch (port->state) { + case TOGGLING: case ERROR_RECOVERY: case PORT_RESET: case PORT_RESET_WAIT_OFF: -- 2.45.0.rc1.225.g2a3ae87e7f-goog

1 hour, 19 minutes

2
1
0 0

[PATCH v1] usb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps

by Amit Sunil Dhamne

There could be a potential use-after-free case in tcpm_register_source_caps(). This could happen when: * new (say invalid) source caps are advertised * the existing source caps are unregistered * tcpm_register_source_caps() returns with an error as usb_power_delivery_register_capabilities() fails This causes port->partner_source_caps to hold on to the now freed source caps. Reset port->partner_source_caps value to NULL after unregistering existing source caps. Fixes: 230ecdf71a64 ("usb: typec: tcpm: unregister existing source caps before re-registration") Cc: stable(a)vger.kernel.org Signed-off-by: Amit Sunil Dhamne <amitsd(a)google.com> --- drivers/usb/typec/tcpm/tcpm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 8a1af08f71b6..be4127ef84e9 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -3014,8 +3014,10 @@ static int tcpm_register_source_caps(struct tcpm_port *port) memcpy(caps.pdo, port->source_caps, sizeof(u32) * port->nr_source_caps); caps.role = TYPEC_SOURCE; - if (cap) + if (cap) { usb_power_delivery_unregister_capabilities(cap); + port->partner_source_caps = NULL; + } cap = usb_power_delivery_register_capabilities(port->partner_pd, &caps); if (IS_ERR(cap)) base-commit: 51474ab44abf907023a8a875e799b07de461e466 -- 2.45.0.rc1.225.g2a3ae87e7f-goog

1 hour, 20 minutes

4
3
0 0

[PATCH net] net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe()

by Romain Gantois

In the prueth_probe() function, if one of the calls to emac_phy_connect() fails due to of_phy_connect() returning NULL, then the subsequent call to phy_attached_info() will dereference a NULL pointer. Check the return code of emac_phy_connect and fail cleanly if there is an error. Fixes: 128d5874c082 ("net: ti: icssg-prueth: Add ICSSG ethernet driver") Cc: stable(a)vger.kernel.org Signed-off-by: Romain Gantois <romain.gantois(a)bootlin.com> --- Hello everyone, There is a possible NULL pointer dereference in the prueth_probe() function of the icssg_prueth driver. I discovered this while testing a platform with one PRUETH MAC enabled out of the two available. These are the requirements to reproduce the bug: prueth_probe() is called either eth0_node or eth1_node is not NULL in emac_phy_connect: of_phy_connect() returns NULL Then, the following leads to the NULL pointer dereference: prueth->emac[PRUETH_MAC0]->ndev->phydev is set to NULL prueth->emac[PRUETH_MAC0]->ndev->phydev is passed to phy_attached_info() -> phy_attached_print() dereferences phydev which is NULL This series provides a fix by checking the return code of emac_phy_connect(). Best Regards, Romain --- drivers/net/ethernet/ti/icssg/icssg_prueth.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.c b/drivers/net/ethernet/ti/icssg/icssg_prueth.c index 7c9e9518f555a..1ea3fbd5e954e 100644 --- a/drivers/net/ethernet/ti/icssg/icssg_prueth.c +++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.c @@ -1039,7 +1039,12 @@ static int prueth_probe(struct platform_device *pdev) prueth->registered_netdevs[PRUETH_MAC0] = prueth->emac[PRUETH_MAC0]->ndev; - emac_phy_connect(prueth->emac[PRUETH_MAC0]); + ret = emac_phy_connect(prueth->emac[PRUETH_MAC0]); + if (ret) { + dev_err(dev, + "can't connect to MII0 PHY, error -%d", ret); + goto netdev_unregister; + } phy_attached_info(prueth->emac[PRUETH_MAC0]->ndev->phydev); } @@ -1051,7 +1056,12 @@ static int prueth_probe(struct platform_device *pdev) } prueth->registered_netdevs[PRUETH_MAC1] = prueth->emac[PRUETH_MAC1]->ndev; - emac_phy_connect(prueth->emac[PRUETH_MAC1]); + ret = emac_phy_connect(prueth->emac[PRUETH_MAC1]); + if (ret) { + dev_err(dev, + "can't connect to MII1 PHY, error %d", ret); + goto netdev_unregister; + } phy_attached_info(prueth->emac[PRUETH_MAC1]->ndev->phydev); } --- base-commit: e4a87abf588536d1cdfb128595e6e680af5cf3ed change-id: 20240521-icssg-prueth-fix-03b03064c5ce Best regards, -- Romain Gantois <romain.gantois(a)bootlin.com>

1 hour, 26 minutes

2
1
0 0

[PATCH v3] ata: ahci: Do not apply Intel PCS quirk on Intel Alder Lake

by Jason Nader

Commit b8b8b4e0c052 ("ata: ahci: Add Intel Alder Lake-P AHCI controller to low power chipsets list") added Intel Alder Lake to the ahci_pci_tbl. Because of the way that the Intel PCS quirk was implemented, having an explicit entry in the ahci_pci_tbl caused the Intel PCS quirk to be applied. (The quirk was not being applied if there was no explict entry.) Thus, entries that were added to the ahci_pci_tbl also got the Intel PCS quirk applied. The quirk was cleaned up in commit 7edbb6059274 ("ahci: clean up intel_pcs_quirk"), such that it is clear which entries that actually applies the Intel PCS quirk. Newer Intel AHCI controllers do not need the Intel PCS quirk, and applying it when not needed actually breaks some platforms. Do not apply the Intel PCS quirk for Intel Alder Lake. This is in line with how things worked before commit b8b8b4e0c052 ("ata: ahci: Add Intel Alder Lake-P AHCI controller to low power chipsets list"), such that certain platforms using Intel Alder Lake will work once again. Cc: stable(a)vger.kernel.org # 6.7 Fixes: b8b8b4e0c052 ("ata: ahci: Add Intel Alder Lake-P AHCI controller to low power chipsets list") Signed-off-by: Jason Nader <dev(a)kayoway.com> --- drivers/ata/ahci.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 6548f10e61d9..07d66d2c5f0d 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -429,7 +429,6 @@ static const struct pci_device_id ahci_pci_tbl[] = { { PCI_VDEVICE(INTEL, 0x02d7), board_ahci_pcs_quirk }, /* Comet Lake PCH RAID */ /* Elkhart Lake IDs 0x4b60 & 0x4b62 https://sata-io.org/product/8803 not tested yet */ { PCI_VDEVICE(INTEL, 0x4b63), board_ahci_pcs_quirk }, /* Elkhart Lake AHCI */ - { PCI_VDEVICE(INTEL, 0x7ae2), board_ahci_pcs_quirk }, /* Alder Lake-P AHCI */ /* JMicron 360/1/3/5/6, match class to avoid IDE function */ { PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, -- 2.45.1

1 hour, 37 minutes

1
0
0 0

[PATCH v4 0/5] Pinephone video out fixes (flipping between two frames)

by Frank Oltmanns

On some pinephones the video output sometimes freezes (flips between two frames) [1]. It seems to be that the reason for this behaviour is that PLL-MIPI is outside its limits, and the GPU is not running at a fixed rate. In this patch series I propose the following changes: 1. sunxi-ng: Adhere to the following constraints given in the Allwinner A64 Manual regarding PLL-MIPI: * M/N <= 3 * (PLL_VIDEO0)/M >= 24MHz * 500MHz <= clockrate <= 1400MHz 2. Remove two operating points from the A64 DTS OPPs, so that the GPU runs at a fixed rate of 432 MHz. Note, that when pinning the GPU to 432 MHz the issue [1] completely disappears for me. I've searched the BSP and could not find any indication that supports the idea of having the three OPPs. The only frequency I found in the BPSs for A64 is 432 MHz, which has also proven stable for me. I very much appreciate your feedback! [1] https://gitlab.com/postmarketOS/pmaports/-/issues/805 Signed-off-by: Frank Oltmanns <frank(a)oltmanns.dev> --- Changes in v4: - sunxi-ng: common: Address review comments. - Link to v3: https://lore.kernel.org/r/20240304-pinephone-pll-fixes-v3-0-94ab828f269a@ol… Changes in v3: - dts: Pin GPU to 432 MHz. - nkm and a64: Move minimum and maximum rate handling to the common part of the sunxi-ng driver. - Removed st7703 patch from series. - Link to v2: https://lore.kernel.org/r/20240205-pinephone-pll-fixes-v2-0-96a46a2d8c9b@ol… Changes in v2: - dts: Increase minimum GPU frequency to 192 MHz. - nkm and a64: Add minimum and maximum rate for PLL-MIPI. - nkm: Use the same approach for skipping invalid rates in ccu_nkm_find_best() as in ccu_nkm_find_best_with_parent_adj(). - nkm: Improve names for ratio struct members and hence get rid of describing comments. - nkm and a64: Correct description in the commit messages: M/N <= 3 - Remove patches for nm as they were not needed. - st7703: Rework the commit message to cover more background for the change. - Link to v1: https://lore.kernel.org/r/20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@ol… --- Frank Oltmanns (5): clk: sunxi-ng: common: Support minimum and maximum rate clk: sunxi-ng: a64: Set minimum and maximum rate for PLL-MIPI clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and parent rate arm64: dts: allwinner: a64: Run GPU at 432 MHz arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 -------- drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +++++++++----- drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++ drivers/clk/sunxi-ng/ccu_common.h | 3 +++ drivers/clk/sunxi-ng/ccu_nkm.c | 21 +++++++++++++++++++++ drivers/clk/sunxi-ng/ccu_nkm.h | 2 ++ 6 files changed, 54 insertions(+), 13 deletions(-) --- base-commit: dcb6c8ee6acc6c347caec1e73fb900c0f4ff9806 change-id: 20231218-pinephone-pll-fixes-0ccdfde273e4 Best regards, -- Frank Oltmanns <frank(a)oltmanns.dev>

1 hour, 38 minutes

5
9
0 0

Kernel 6.8.4 regression: aacraid controller not initialized any more, system boot hangs

by Peter Schneider

Hi all, I am running a dual Xeon machine as my personal virtualization server at home, using Proxmox VE, and with their latest update 8.2 which brings kernel 6.8.4-2-pve, I am seeing a serious regression which breaks my setup because it does not boot any more. The last message I see displayed during boot is: "Timed out for waiting the udev queue being empty.", and then it hangs indefinitely. Previous kernel 6.5.13-5-pve worked fine, with the following caveat: I had similar problems initially with earlier kernels too, so from the very beginning with this machine using PVE, I had to set grub parameter rootdelay=60. With that, everything was fine, the busses settled and RAID controller and root device was found and system booted. With the newer 6.8.4 kernel, not any more, although I even tried to increase rootdelay parameter to 120. I was able to reproduce and bisect this regression also with mainline kernels (also with stable 6.8.8 and 6.9-rc), so I thought it would be a good idea to report it upstream to you guys. This is an older server machine: 2-socket Ivy Bridge Xeon E5-2697 v2 (24C/48T) in an Asus Z9PE-D16/2L motherboard (Intel C-602A chipset); BIOS patched to the latest available from Asus. All memory slots occupied, so 256 GB RAM in total. It also has Asus ASMB6 iKVM BMC, which supplies virtual storage devices (seel below dmesg) to which ISO images can be attached via network to boot/install OS from. Storage config: I have two single M4 256 GiB SATA SSD drives attached to internal mainboard SATA ports; one of them is my root device and PVE installation drive. The other one I use for storing ISO images. My main VM storage is attached to a battery backed-up Adaptec 5805 SATA/SAS RAID controller (w/ latest FW build 18948) attached to SATA/SAS enclosure of my Supermicro server casing, having eight disk drives in total: I have one RAID1 Array, consisting of two Samsung 1 TiB SATA SSDs for VM root disk images, and one RAID5 Array, consisting of 6 Hitachi 1 TiB HDDs which I use for storing VM data disk images. On both arrays, I use a LVM thin pool as PVE storage location. When everything boots up, the system is running just fine and smoothly with ~15 VMs at the same time (and has for years!). Although this is "only" a homelab server, I love it dearly and use it for many private projects VMs, among them runing Windows Server VM with MS SQL Server, and Linux server VMs running Oracle Database Server (I'm a database guy). I attach dmesg output of previous working kernel 6.5.13-5-pve, my git bisect log and output of lspci -v. The last successful kernel messages I see from the failing kernels version is this: ... [ 5.540424] usb-storage 1-1.3.4:1.0: USB Mass Storage device detected [ 5.540670] scsi host10: usb-storage 1-1.3.4:1.0 [ 5.947794] scsi 8:0:0:0: CD-ROM AMI Virtual CDROM0 1.00 PQ: 0 ANSI: 0 CCS [ 6.267830] scsi 9:0:0:0: Direct-Access AMI Virtual Floppy0 1.00 PQ: 0 ANSI: 0 CCS [ 6.555845] scsi 10:0:0:0: Direct-Access AMI Virtual HDISK0 1.00 PQ: 0 ANSI: 0 CCS and then the error message "Timed out for waiting the udev queue being empty." and the system hangs. In case of working kernels, the boot process would continue with this: ... [ 5.947794] scsi 8:0:0:0: CD-ROM AMI Virtual CDROM0 1.00 PQ: 0 ANSI: 0 CCS [ 6.267830] scsi 9:0:0:0: Direct-Access AMI Virtual Floppy0 1.00 PQ: 0 ANSI: 0 CCS [ 6.555845] scsi 10:0:0:0: Direct-Access AMI Virtual HDISK0 1.00 PQ: 0 ANSI: 0 CCS [ 32.592054] scsi 0:3:1:0: Enclosure ADAPTEC Virtual SGPIO 1 0001 PQ: 0 ANSI: 5 [ 61.536097] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 61.536215] sd 0:0:0:0: [sda] 1998565376 512-byte logical blocks: (1.02 TB/953 GiB) [ 61.536236] sd 0:0:1:0: Attached scsi generic sg1 type 0 [ 61.536239] sd 0:0:0:0: [sda] Write Protect is off [ 61.536246] sd 0:0:0:0: [sda] Mode Sense: 12 00 10 08 [ 61.536283] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA [ 61.536340] scsi 0:1:0:0: Attached scsi generic sg2 type 0 [ 61.536383] sd 0:0:1:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [ 61.536400] sd 0:0:1:0: [sdb] 9762222080 512-byte logical blocks: (5.00 TB/4.54 TiB) [ 61.536414] sd 0:0:1:0: [sdb] Write Protect is off [ 61.536418] sd 0:0:1:0: [sdb] Mode Sense: 12 00 10 08 [ 61.536439] sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA [ 61.536455] scsi 0:1:1:0: Attached scsi generic sg3 type 0 [ 61.536616] scsi 0:1:2:0: Attached scsi generic sg4 type 0 [ 61.536750] scsi 0:1:3:0: Attached scsi generic sg5 type 0 [ 61.536840] scsi 0:1:4:0: Attached scsi generic sg6 type 0 [ 61.536930] scsi 0:1:5:0: Attached scsi generic sg7 type 0 [ 61.537027] scsi 0:1:6:0: Attached scsi generic sg8 type 0 [ 61.537122] scsi 0:1:7:0: Attached scsi generic sg9 type 0 [ 61.537248] sd 0:0:1:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [ 61.537274] scsi 0:3:0:0: Attached scsi generic sg10 type 13 [ 61.537390] scsi 0:3:1:0: Attached scsi generic sg11 type 13 [ 61.537558] scsi 1:0:0:0: Direct-Access ATA M4-CT256M4SSD2 0309 PQ: 0 ANSI: 5 [ 61.537851] sd 1:0:0:0: Attached scsi generic sg12 type 0 [ 61.537919] scsi: waiting for bus probes to complete ... [ 61.537973] sd 1:0:0:0: [sdc] 500118192 512-byte logical blocks: (256 GB/238 GiB) [ 61.537986] sd 1:0:0:0: [sdc] Write Protect is off [ 61.537989] sd 1:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 61.538002] sd 1:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 61.538022] sd 1:0:0:0: [sdc] Preferred minimum I/O size 512 bytes [ 61.538924] sdc: sdc1 sdc2 < sdc5 > ... so it seems to me the initialiation of the the Adaptec controller is the culprit. I have tested and reproduced the regression with mainline kernels according to the following list (please excuse me if it's too long ;-) See at the very bottom for first bad commit I found this way. I always built as "make olddefconfig" using the 6.5.13-5-pve config as starting point. ------------------------------------------------------------------- Proxmox Virtual Environmet (PVE) Kernels ======================================== 6.5.13-5-pve WORKS last working PVE (8.1) kernel; 5.15-pve and 6.2-pve work too 6.8.4-2-pve NOPE PVE release 8.2 Mainline Kernels ================ 6.9.0-rc6+ NOPE Most recent (2024-05-01) 6.9.0-rc5+ NOPE Most recent (2024-04-27) 6.8.8 NOPE Most recent released (2024-04-29) 6.8.7 NOPE Most recent released (2024-04-27) 6.8.4 NOPE Same version as most recent released PVE 8.2 Kernel 6.5.13 WORKS My tests, reverts on top of 6.8.8 ================================= 6.8.8+ WORKS Revert "Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi" - This reverts commit 6d20acbf3e3a32d331947dbc3802cf2d1a399e7d, reversing changes made to fef85269a19d277f23fc5ff08a3c356beeb54cb3 6.8.8+ WORKS Revert "scsi: core: Consult supported VPD page list prior to fetching page" - This reverts commit b5fc07a5fb56216a49e6c1d0b172d5464d99a89b (this is the first bad commit of my bisect session, see below, and a single patch as part of the above merged tag 'scsi-fixes') Bisecting, starting from 6.9.0-rc5 (bad) and 6.5.13 (good) ========================================================== root@linus:/usr/src/linux# git checkout master Bereits auf 'master' Ihr Branch ist auf demselben Stand wie 'origin/master'. root@linus:/usr/src/linux# git log commit 9d1ddab261f3e2af7c384dc02238784ce0cf9f98 (HEAD -> master, origin/master, origin/HEAD) Merge: 71b1543c83d6 77d8aa79ecfb Author: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Tue Apr 23 09:37:32 2024 -0700 Merge tag '6.9-rc5-smb-client-fixes' of git://git.samba.org/sfrench/cifs-2.6 root@linus:/usr/src/linux# cp /boot/config-6.5.13-5-pve .config root@linus:/usr/src/linux# git bisect start Status: warte auf guten und schlechten Commit root@linus:/usr/src/linux# git bisect bad Status: warte auf gute(n) Commit(s), schlechter Commit bekannt root@linus:/usr/src/linux# git bisect good v6.5.13 Binäre Suche: eine Merge-Basis muss geprüft werden [2dde18cd1d8fac735875f2e4987f11817cc0bc2c] Linux 6.5 root@linus:/usr/src/linux# make olddefconfig .config:10571:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC .config:10572:warning: symbol value 'm' invalid for ANDROID_BINDERFS # # configuration written to .config # root@linus:/usr/src/linux# make -j 48 => 6.5.0 (Merge Base) WORKS root@linus:/usr/src/linux# git bisect good Binäre Suche: danach noch 32111 Commits zum Testen übrig (ungefähr 15 Schritte) [0f5cc96c367f2e780eb492cc9cab84e3b2ca88da] Merge tag 's390-6.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux root@linus:/usr/src/linux# make -j 48 => 6.7.0-rc2+ WORKS root@linus:/usr/src/linux# git bisect good Binäre Suche: danach noch 16056 Commits zum Testen übrig (ungefähr 14 Schritte) [ee138217c32ccbfa75d5ea6b766158148e98f6fa] Merge tag 'btree-remove-btnum-6.9_2024-02-23' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.9-mergeC => 6.8.0-rc4+ WORKS root@linus:/usr/src/linux# git bisect good Binäre Suche: danach noch 8214 Commits zum Testen übrig (ungefähr 13 Schritte) [e5e038b7ae9da96b93974bf072ca1876899a01a3] Merge tag 'fs_for_v6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs => 6.8.0+ NOPE => does not find root device, does not boot; message: "BUG: arch topology borken the CPU domain not a subset of > the NUMA domain" message: "Timed out for waiting the udev queue being empty." root@linus:/usr/src/linux# git bisect bad Binäre Suche: danach noch 3954 Commits zum Testen übrig (ungefähr 12 Schritte) [f153fbe1ea11939e2514ba4b3b62bbd946e2892c] Merge tag 'erofs-for-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs => 6.8.0+ (HEAD losgelöst bei f153fbe1ea11) NOPE => same as above root@linus:/usr/src/linux# git bisect bad Binäre Suche: danach noch 1945 Commits zum Testen übrig (ungefähr 11 Schritte) [1ddeeb2a058d7b2a58ed9e820396b4ceb715d529] Merge tag 'for-6.9/block-20240310' of git://git.kernel.dk/linux => 6.8.0+ (HEAD losgelöst bei 1ddeeb2a058d) NOPE => same as above root@linus:/usr/src/linux# git bisect bad Binäre Suche: danach noch 970 Commits zum Testen übrig (ungefähr 10 Schritte) [2652b99e43403dc464f3648483ffb38e48872fe4] ice: virtchnl: stop pretending to support RSS over AQ or registers => 6.8.0-rc6+ (2652b99e4340) NOPE => same root@linus:/usr/src/linux# git bisect bad Binäre Suche: danach noch 506 Commits zum Testen übrig (ungefähr 9 Schritte) [efa80dcbb7a3ecc4a1b2f54624c49b5a612f92b3] Merge tag 'trace-v6.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace => 6.8.0-rc5+ (efa80dcbb7a3) WORKS root@linus:/usr/src/linux# git bisect good Binäre Suche: danach noch 251 Commits zum Testen übrig (ungefähr 8 Schritte) [c6a597fcc7ad7335a3ecf8f5287a0459f793a257] Merge tag 'loongarch-fixes-6.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson => 6.8.0-rc5+ (c6a597fcc7ad) WORKS root@linus:/usr/src/linux# git bisect good Binäre Suche: danach noch 126 Commits zum Testen übrig (ungefähr 7 Schritte) [cf1182944c7cc9f1c21a8a44e0d29abe12527412] Merge tag 'lsm-pr-20240227' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm => 6.8.0-rc6+ (cf1182944c7c) NOPE root@linus:/usr/src/linux# git bisect bad Binäre Suche: danach noch 62 Commits zum Testen übrig (ungefähr 6 Schritte) [4ca0d9894fd517a2f2c0c10d26ebe99ab4396fe3] Merge tag 'erofs-for-6.8-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs => 6.8.0-rc5+ (4ca0d9894fd5) NOPE root@linus:/usr/src/linux# git bisect bad Binäre Suche: danach noch 36 Commits zum Testen übrig (ungefähr 5 Schritte) [ac389bc0ca56e1a2f92b2a17e58298390a3879a8] Merge tag 'cxl-fixes-6.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl => 6.8.0-rc5+ (ac389bc0ca56) NOPE root@linus:/usr/src/linux# git bisect bad Binäre Suche: danach noch 12 Commits zum Testen übrig (ungefähr 4 Schritte) [40de53fd002c6ba087a623722915e8006ed68a02] Merge branch 'for-6.8/cxl-cper' into for-6.8/cxl => 6.8.0-rc5+ (40de53fd002c) WORKS root@linus:/usr/src/linux# git bisect good Binäre Suche: danach noch 6 Commits zum Testen übrig (ungefähr 3 Schritte) [9ddf190a7df77b77817f955fdb9c2ae9d1c9c9a3] scsi: jazz_esp: Only build if SCSI core is builtin => 6.8.0-rc1+ (9ddf190a7df7) NOPE root@linus:/usr/src/linux# git bisect bad Binäre Suche: danach noch 2 Commits zum Testen übrig (ungefähr 2 Schritte) [de959094eb2197636f7c803af0943cb9d3b35804] scsi: target: pscsi: Fix bio_put() for error case => 6.8.0-rc1+ (de959094eb21) NOPE root@linus:/usr/src/linux# git bisect bad Binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 1 Schritt) [b5fc07a5fb56216a49e6c1d0b172d5464d99a89b] scsi: core: Consult supported VPD page list prior to fetching page => 6.8.0-rc1+ (b5fc07a5fb56) NOPE root@linus:/usr/src/linux# git bisect bad Binäre Suche: danach noch 0 Commits zum Testen übrig (ungefähr 0 Schritte) [321da3dc1f3c92a12e3c5da934090d2992a8814c] scsi: sd: usb_storage: uas: Access media prior to querying device properties => 6.8.0-rc1+ (321da3dc1f3c) WORKS root@linus:/usr/src/linux# git bisect good b5fc07a5fb56216a49e6c1d0b172d5464d99a89b is the first bad commit commit b5fc07a5fb56216a49e6c1d0b172d5464d99a89b Author: Martin K. Petersen <martin.petersen(a)oracle.com> Date: Wed Feb 14 17:14:11 2024 -0500 scsi: core: Consult supported VPD page list prior to fetching page Commit c92a6b5d6335 ("scsi: core: Query VPD size before getting full page") removed the logic which checks whether a VPD page is present on the supported pages list before asking for the page itself. That was done because SPC helpfully states "The Supported VPD Pages VPD page list may or may not include all the VPD pages that are able to be returned by the device server". Testing had revealed a few devices that supported some of the 0xBn pages but didn't actually list them in page 0. Julian Sikorski bisected a problem with his drive resetting during discovery to the commit above. As it turns out, this particular drive firmware will crash if we attempt to fetch page 0xB9. Various approaches were attempted to work around this. In the end, reinstating the logic that consults VPD page 0 before fetching any other page was the path of least resistance. A firmware update for the devices which originally compelled us to remove the check has since been released. Link: https://lore.kernel.org/r/20240214221411.2888112-1-martin.petersen@oracle.c… Fixes: c92a6b5d6335 ("scsi: core: Query VPD size before getting full page") Cc: stable(a)vger.kernel.org Cc: Bart Van Assche <bvanassche(a)acm.org> Reported-by: Julian Sikorski <belegdol(a)gmail.com> Tested-by: Julian Sikorski <belegdol(a)gmail.com> Reviewed-by: Lee Duncan <lee.duncan(a)suse.com> Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> drivers/scsi/scsi.c | 22 ++++++++++++++++++++-- include/scsi/scsi_device.h | 4 ---- 2 files changed, 20 insertions(+), 6 deletions(-) root@linus:/usr/src/linux# ------------------------------------------------------------------- Beste Grüße, Peter Schneider -- Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@googlem… https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@gmail.c…

1 hour, 41 minutes

2
8
0 0

[PATCH] btrfs: re-introduce 'norecovery' mount option

by Qu Wenruo

Although 'norecovery' mount option is marked deprecated for a long time and a warning message is introduced during the deprecation window, it's still actively utilized by several projects that need a safely way to mount a btrfs without any writes. Furthermore this 'norecovery' mount option is supported by most major filesystems, which makes it harder to validate our motivation. This patch would re-introduce the 'norecovery' mount option, and output a message to recommend 'rescue=nologreplay' option. Link: https://lore.kernel.org/linux-btrfs/ZkxZT0J-z0GYvfy8@gardel-login/#t Link: https://github.com/systemd/systemd/pull/32892 Link: https://bugzilla.suse.com/show_bug.cgi?id=1222429 Reported-by: Lennart Poettering <lennart(a)poettering.net> Reported-by: Jiri Slaby <jslaby(a)suse.com> Fixes: a1912f712188 ("btrfs: remove code for inode_cache and recovery mount options") Cc: stable(a)vger.kernel.org # 6.8+ Signed-off-by: Qu Wenruo <wqu(a)suse.com> --- fs/btrfs/super.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 2dbc930a20f7..f05cce7c8b8d 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -119,6 +119,7 @@ enum { Opt_thread_pool, Opt_treelog, Opt_user_subvol_rm_allowed, + Opt_norecovery, /* Rescue options */ Opt_rescue, @@ -245,6 +246,8 @@ static const struct fs_parameter_spec btrfs_fs_parameters[] = { __fsparam(NULL, "nologreplay", Opt_nologreplay, fs_param_deprecated, NULL), /* Deprecated, with alias rescue=usebackuproot */ __fsparam(NULL, "usebackuproot", Opt_usebackuproot, fs_param_deprecated, NULL), + /* For compatibility only, alias for "rescue=nologreplay". */ + fsparam_flag("norecovery", Opt_norecovery), /* Debugging options. */ fsparam_flag_no("enospc_debug", Opt_enospc_debug), @@ -438,6 +441,11 @@ static int btrfs_parse_param(struct fs_context *fc, struct fs_parameter *param) "'nologreplay' is deprecated, use 'rescue=nologreplay' instead"); btrfs_set_opt(ctx->mount_opt, NOLOGREPLAY); break; + case Opt_norecovery: + btrfs_info(NULL, +"'norecovery' is for compatibility only, recommended to use 'rescue=nologreplay'"); + btrfs_set_opt(ctx->mount_opt, NOLOGREPLAY); + break; case Opt_flushoncommit: if (result.negated) btrfs_clear_opt(ctx->mount_opt, FLUSHONCOMMIT); -- 2.45.1

1 hour, 47 minutes

4
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024