February 2024 - Linux-stable-mirror

[PATCH RESEND 0/2] ARM: prctl: Reject PR_SET_MDWE where not supported

by Zev Weiss

[Resending as per Russell's request...] Hello, I noticed after a recent kernel update that my ARM926 system started segfaulting on any execve() after calling prctl(PR_SET_MDWE). After some investigation it appears that ARMv5 is incapable of providing the appropriate protections for MDWE, since any readable memory is also implicitly executable. (Note that I'm not an expert in either ARM arch details or the mm subsystem, so please bear with me if I've botched something in the above analysis.) The prctl_set_mdwe() function already had some special-case logic added disabling it on PARISC (commit 793838138c15, "prctl: Disable prctl(PR_SET_MDWE) on parisc"); this patch series (1) generalizes that check to use an arch_*() function, and (2) adds a corresponding override for ARM to disable MDWE on pre-ARMv6 CPUs. With the series applied, prctl(PR_SET_MDWE) is rejected on ARMv5 and subsequent execve() calls (as well as mmap(PROT_READ|PROT_WRITE)) can succeed instead of unconditionally failing; on ARMv6 the prctl works as it did previously. Thanks, Zev [0] https://lore.kernel.org/all/2023112456-linked-nape-bf19@gregkh/ Zev Weiss (2): prctl: Generalize PR_SET_MDWE support check to be per-arch ARM: prctl: Reject PR_SET_MDWE on pre-ARMv6 arch/arm/include/asm/mman.h | 14 ++++++++++++++ arch/parisc/include/asm/mman.h | 14 ++++++++++++++ include/linux/mman.h | 8 ++++++++ kernel/sys.c | 7 +++++-- 4 files changed, 41 insertions(+), 2 deletions(-) create mode 100644 arch/arm/include/asm/mman.h create mode 100644 arch/parisc/include/asm/mman.h -- 2.43.2

1 year, 7 months

3
5
0 0

[PATCH v3 1/1] driver core: Keep the supplier fwnode consistent with the device

by Herve Codina

The commit 3a2dbc510c43 ("driver core: fw_devlink: Don't purge child fwnode's consumer links") introduces the possibility to use the supplier's parent device instead of the supplier itself. In that case the supplier fwnode used is not updated and is no more consistent with the supplier device used. Use the fwnode consistent with the supplier device when checking flags. Fixes: 3a2dbc510c43 ("driver core: fw_devlink: Don't purge child fwnode's consumer links") Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- Changes v2 -> v3: Do not update the supplier handle in order to keep the original handle for debug traces. Changes v1 -> v2: Remove sup_handle check and related pr_debug() call as sup_handle cannot be invalid if sup_dev is valid. drivers/base/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 4d8b315c48a1..440b52ec027f 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -2082,7 +2082,7 @@ static int fw_devlink_create_devlink(struct device *con, * supplier device indefinitely. */ if (sup_dev->links.status == DL_DEV_NO_DRIVER && - sup_handle->flags & FWNODE_FLAG_INITIALIZED) { + sup_dev->fwnode->flags & FWNODE_FLAG_INITIALIZED) { dev_dbg(con, "Not linking %pfwf - dev might never probe\n", sup_handle); -- 2.41.0

1 year, 7 months

2
3
0 0

[REGRESSION] 6.7.1: md: raid5 hang and unresponsive system; successfully bisected

by Dan Moulding

After upgrading from 6.7.0 to 6.7.1 a couple of my systems with md RAID-5 arrays started experiencing hangs. It starts with some processes which write to the array getting stuck. The whole system eventually becomes unresponsive and unclean shutdown must be performed (poweroff and reboot don't work). While trying to diagnose the issue, I noticed that the md0_raid5 kernel thread consumes 100% CPU after the issue occurs. No relevant warnings or errors were found in dmesg. On 6.7.1, I can reproduce the issue somewhat reliably by copying a large amount of data to the array. I am unable to reproduce the issue at all on 6.7.0. The bisection was a bit difficult since I don't have a 100% reliable method to reproduce the problem, but with some perseverence I eventually managed to whittle it down to commit 0de40f76d567 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"). After reverting that commit (i.e. reapplying the reverted commit) on top of 6.7.1 I can no longer reproduce the problem at all. Some details that might be relevant: - Both systems are running MD RAID-5 with a journal device. - mdadm in monitor mode is always running on both systems. - Both systems were previously running 6.7.0 and earlier just fine. - The older of the two systems has been running a raid5 array without incident for many years (kernel going back to at least 5.1) -- this is the first raid5 issue it has encountered. Please let me know if there is any other helpful information that I might be able to provide. -- Dan #regzbot introduced: 0de40f76d567133b871cd6ad46bb87afbce46983

1 year, 7 months

9
52
0 0

[PATCH] perf/x86/intel/uncore: Fix the bits of the CHA extended umask for SPR

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> The perf stat errors out with UNC_CHA_TOR_INSERTS.IA_HIT_CXL_ACC_LOCAL event. $perf stat -e uncore_cha_55/event=0x35,umask=0x10c0008101/ -a -- ls event syntax error: '..0x35,umask=0x10c0008101/' \___ Bad event or PMU The definition of the CHA umask is config:8-15,32-55, which is 32bit. However, the umask of the event is bigger than 32bit. This is an error in the original uncore spec. Add a new umask_ext5 for the new CHA umask range. Fixes: 949b11381f81 ("perf/x86/intel/uncore: Add Sapphire Rapids server CHA support") Closes: https://lore.kernel.org/linux-perf-users/alpine.LRH.2.20.2401300733310.1135… Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- arch/x86/events/intel/uncore_snbep.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c index a96496bef678..7924f315269a 100644 --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -461,6 +461,7 @@ #define SPR_UBOX_DID 0x3250 /* SPR CHA */ +#define SPR_CHA_EVENT_MASK_EXT 0xffffffff #define SPR_CHA_PMON_CTL_TID_EN (1 << 16) #define SPR_CHA_PMON_EVENT_MASK (SNBEP_PMON_RAW_EVENT_MASK | \ SPR_CHA_PMON_CTL_TID_EN) @@ -477,6 +478,7 @@ DEFINE_UNCORE_FORMAT_ATTR(umask_ext, umask, "config:8-15,32-43,45-55"); DEFINE_UNCORE_FORMAT_ATTR(umask_ext2, umask, "config:8-15,32-57"); DEFINE_UNCORE_FORMAT_ATTR(umask_ext3, umask, "config:8-15,32-39"); DEFINE_UNCORE_FORMAT_ATTR(umask_ext4, umask, "config:8-15,32-55"); +DEFINE_UNCORE_FORMAT_ATTR(umask_ext5, umask, "config:8-15,32-63"); DEFINE_UNCORE_FORMAT_ATTR(qor, qor, "config:16"); DEFINE_UNCORE_FORMAT_ATTR(edge, edge, "config:18"); DEFINE_UNCORE_FORMAT_ATTR(tid_en, tid_en, "config:19"); @@ -5957,7 +5959,7 @@ static struct intel_uncore_ops spr_uncore_chabox_ops = { static struct attribute *spr_uncore_cha_formats_attr[] = { &format_attr_event.attr, - &format_attr_umask_ext4.attr, + &format_attr_umask_ext5.attr, &format_attr_tid_en2.attr, &format_attr_edge.attr, &format_attr_inv.attr, @@ -5993,7 +5995,7 @@ ATTRIBUTE_GROUPS(uncore_alias); static struct intel_uncore_type spr_uncore_chabox = { .name = "cha", .event_mask = SPR_CHA_PMON_EVENT_MASK, - .event_mask_ext = SPR_RAW_EVENT_MASK_EXT, + .event_mask_ext = SPR_CHA_EVENT_MASK_EXT, .num_shared_regs = 1, .constraints = skx_uncore_chabox_constraints, .ops = &spr_uncore_chabox_ops, -- 2.35.1

1 year, 7 months

3
2
0 0

[PATCH AUTOSEL 5.10 1/7] btrfs: add and use helper to check if block group is used

by Sasha Levin

From: Filipe Manana <fdmanana(a)suse.com> [ Upstream commit 1693d5442c458ae8d5b0d58463b873cd879569ed ] Add a helper function to determine if a block group is being used and make use of it at btrfs_delete_unused_bgs(). This helper will also be used in future code changes. Reviewed-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Reviewed-by: Josef Bacik <josef(a)toxicpanda.com> Reviewed-by: Boris Burkov <boris(a)bur.io> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- fs/btrfs/block-group.c | 3 +-- fs/btrfs/block-group.h | 7 +++++++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index c4e3c1a5de059..9a7c7e0f7c233 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -1393,8 +1393,7 @@ void btrfs_delete_unused_bgs(struct btrfs_fs_info *fs_info) } spin_lock(&block_group->lock); - if (block_group->reserved || block_group->pinned || - block_group->used || block_group->ro || + if (btrfs_is_block_group_used(block_group) || block_group->ro || list_is_singular(&block_group->list)) { /* * We want to bail if we made new allocations or have diff --git a/fs/btrfs/block-group.h b/fs/btrfs/block-group.h index 4c7614346f724..0d02b75f9e7e3 100644 --- a/fs/btrfs/block-group.h +++ b/fs/btrfs/block-group.h @@ -196,6 +196,13 @@ static inline u64 btrfs_block_group_end(struct btrfs_block_group *block_group) return (block_group->start + block_group->length); } +static inline bool btrfs_is_block_group_used(const struct btrfs_block_group *bg) +{ + lockdep_assert_held(&bg->lock); + + return (bg->used > 0 || bg->reserved > 0 || bg->pinned > 0); +} + static inline bool btrfs_is_block_group_data_only( struct btrfs_block_group *block_group) { -- 2.43.0

1 year, 7 months

3
9
0 0

[PATCH AUTOSEL 6.7 01/26] media: Revert "media: rkisp1: Drop IRQF_SHARED"

by Sasha Levin

From: Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com> [ Upstream commit a107d643b2a3382e0a2d2c4ef08bf8c6bff4561d ] This reverts commit 85d2a31fe4d9be1555f621ead7a520d8791e0f74. The rkisp1 does share interrupt lines on some platforms, after all. Thus we need to revert this, and implement a fix for the rkisp1 shared irq handling in a follow-up patch. Closes: https://lore.kernel.org/all/87o7eo8vym.fsf@gmail.com/ Link: https://lore.kernel.org/r/20231218-rkisp-shirq-fix-v1-1-173007628248@ideaso… Reported-by: Mikhail Rudenko <mike.rudenko(a)gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c index f96f821a7b50d..acc559652d6eb 100644 --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c @@ -559,7 +559,7 @@ static int rkisp1_probe(struct platform_device *pdev) rkisp1->irqs[il] = irq; } - ret = devm_request_irq(dev, irq, info->isrs[i].isr, 0, + ret = devm_request_irq(dev, irq, info->isrs[i].isr, IRQF_SHARED, dev_driver_string(dev), dev); if (ret) { dev_err(dev, "request irq failed: %d\n", ret); -- 2.43.0

1 year, 7 months

3
28
0 0

[PATCH AUTOSEL 6.1 01/12] soc: microchip: Fix POLARFIRE_SOC_SYS_CTRL input prompt

by Sasha Levin

From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 6dd9a236042e305d7b69ee92db7347bf5943e7d3 ] The symbol's prompt should be a one-line description, instead of just duplicating the symbol name. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/soc/microchip/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/microchip/Kconfig b/drivers/soc/microchip/Kconfig index eb656b33156ba..f19e74d342aa2 100644 --- a/drivers/soc/microchip/Kconfig +++ b/drivers/soc/microchip/Kconfig @@ -1,5 +1,5 @@ config POLARFIRE_SOC_SYS_CTRL - tristate "POLARFIRE_SOC_SYS_CTRL" + tristate "Microchip PolarFire SoC (MPFS) system controller support" depends on POLARFIRE_SOC_MAILBOX help This driver adds support for the PolarFire SoC (MPFS) system controller. -- 2.43.0

1 year, 7 months

4
18
0 0

[PATCH AUTOSEL 4.19 1/4] x86/mm: Move is_vsyscall_vaddr() into asm/vsyscall.h

by Sasha Levin

From: Hou Tao <houtao1(a)huawei.com> [ Upstream commit ee0e39a63b78849f8abbef268b13e4838569f646 ] Move is_vsyscall_vaddr() into asm/vsyscall.h to make it available for copy_from_kernel_nofault_allowed() in arch/x86/mm/maccess.c. Reviewed-by: Sohil Mehta <sohil.mehta(a)intel.com> Signed-off-by: Hou Tao <houtao1(a)huawei.com> Link: https://lore.kernel.org/r/20240202103935.3154011-2-houtao@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/include/asm/vsyscall.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h index b986b2ca688a0..8154b25cb975a 100644 --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -4,6 +4,7 @@ #include <linux/seqlock.h> #include <uapi/asm/vsyscall.h> +#include <asm/page_types.h> #ifdef CONFIG_X86_VSYSCALL_EMULATION extern void map_vsyscall(void); @@ -22,4 +23,13 @@ static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) } #endif +/* + * The (legacy) vsyscall page is the long page in the kernel portion + * of the address space that has user-accessible permissions. + */ +static inline bool is_vsyscall_vaddr(unsigned long vaddr) +{ + return unlikely((vaddr & PAGE_MASK) == VSYSCALL_ADDR); +} + #endif /* _ASM_X86_VSYSCALL_H */ -- 2.43.0

1 year, 7 months

2
5
0 0

[PATCH v4] soc: qcom: mdt_loader: Add Upperbounds check for program header access

by Auditya Bhattaram

hash_index is evaluated by looping phdrs till QCOM_MDT_TYPE_HASH is found. Add an upperbound check to phdrs to access within elf size. Fixes: 64fb5eb87d58 ("soc: qcom: mdt_loader: Allow hash to reside in any segment") Cc: <stable(a)vger.kernel.org> Signed-off-by: Auditya Bhattaram <quic_audityab(a)quicinc.com> Acked-by: Mukesh Ojha <quic_mojha(a)quicinc.com> --- Changes in v4: - Added additional prints incase of Invalid access. Link to v3 https://lore.kernel.org/stable/1c91c653-cebe-4407-bdd6-cfc73b64c0fb@quicinc… Link to v2 https://lore.kernel.org/linux-arm-msm/9773d189-c896-d5c5-804c-e086c24987b4@… Link to v1 https://lore.kernel.org/linux-arm-msm/5d7a3b97-d840-4863-91a0-32c1d8e7532f@… --- drivers/soc/qcom/mdt_loader.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c index 6f177e46fa0f..1a79a7bba468 100644 --- a/drivers/soc/qcom/mdt_loader.c +++ b/drivers/soc/qcom/mdt_loader.c @@ -145,6 +143,13 @@ void *qcom_mdt_read_metadata(const struct firmware *fw, size_t *data_len, if (phdrs[0].p_type == PT_LOAD) return ERR_PTR(-EINVAL); + if (((size_t)(phdrs + ehdr->e_phnum)) > ((size_t)ehdr + fw->size)) { + dev_err(dev, + "Invalid phdrs access for fw: %s, e_phnum: %u, fw->size: %zu\n", + fw_name, ehdr->e_phnum, fw->size); + return ERR_PTR(-EINVAL); + } + for (i = 1; i < ehdr->e_phnum; i++) { if ((phdrs[i].p_flags & QCOM_MDT_TYPE_MASK) == QCOM_MDT_TYPE_HASH) { hash_segment = i; -- 2.17.1

1 year, 7 months

2
4
0 0

I/O errors while writing to external Transcend XS-2000 4TB SSD

by Martin Steigerwald

Hi! This is not exactly a regression, as I am not aware of a prior working state, but kernel documentation advises me to CC regressions list anyway¹. I am trying to put data on an external Kingston XS-2000 4 TB SSD using self-compiled Linux 6.7.4 kernel and encrypted BCacheFS. I do not think BCacheFS has any part in the errors I see, but if you disagree feel free to CC the BCacheFS mailing list as you reply. I am using a ThinkPad T14 AMD Gen 1 with AMD Ryzen 7 PRO 4750U and 32 GiB of RAM. I connected the SSD onto USB-C port directly with the ThinkPad. lsusb lists it as: Bus 007 Device 004: ID 0951:176b Kingston Technology XS2000 The SSD is detected as follows: [20303.913644] usb 7-1: new SuperSpeed Plus Gen 2x1 USB device number 9 using xhci_hcd [20303.926616] usb 7-1: New USB device found, idVendor=0951, idProduct=176b, bcdDevice= 1.00 [20303.926633] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [20303.926641] usb 7-1: Product: XS2000 [20303.926647] usb 7-1: Manufacturer: Kingston [20303.926652] usb 7-1: SerialNumber: […] [20303.929078] scsi host0: uas [20303.983859] scsi 0:0:0:0: Direct-Access Kingston XS2000 1000 PQ: 0 ANSI: 6 [20303.984426] sd 0:0:0:0: Attached scsi generic sg0 type 0 [20303.985197] sd 0:0:0:0: [sda] 8001573552 512-byte logical blocks: (4.10 TB/3.73 TiB) [20303.985331] sd 0:0:0:0: [sda] Write Protect is off [20303.985341] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [20303.985579] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [20303.989516] sda: sda1 [20303.989611] sd 0:0:0:0: [sda] Attached SCSI disk BCacheFS is mounted as follows – but I suspect BCacheFS is not involved in those errors anyway: [20310.437864] bcachefs (sda1): mounting version 1.3: rebalance_work opts=metadata_checksum=xxhash,data_checksum=xxhash,compression=lz4 [20310.437895] bcachefs (sda1): recovering from clean shutdown, journal seq 5094 [20310.450813] bcachefs (sda1): alloc_read... done [20310.450851] bcachefs (sda1): stripes_read... done [20310.450855] bcachefs (sda1): snapshots_read... done [20310.470815] bcachefs (sda1): journal_replay... done [20310.470824] bcachefs (sda1): resume_logged_ops... done [20310.470835] bcachefs (sda1): going read-write During rsync'ing about 1,4 TB of data after eventually a hour I got things like this: [33963.462694] sd 0:0:0:0: [sda] tag#10 uas_zap_pending 0 uas-tag 1 inflight: CMD [33963.462708] sd 0:0:0:0: [sda] tag#10 CDB: Write(16) 8a 00 00 00 00 00 82 c1 bc 00 00 00 04 00 00 00 [33963.462718] sd 0:0:0:0: [sda] tag#11 uas_zap_pending 0 uas-tag 2 inflight: CMD [33963.462725] sd 0:0:0:0: [sda] tag#11 CDB: Write(16) 8a 00 00 00 00 00 82 c1 c8 00 00 00 04 00 00 00 [33963.462733] sd 0:0:0:0: [sda] tag#15 uas_zap_pending 0 uas-tag 3 inflight: CMD [33963.462740] sd 0:0:0:0: [sda] tag#15 CDB: Write(16) 8a 00 00 00 00 00 82 c1 d2 4c 00 00 01 2f 00 00 [33963.462748] sd 0:0:0:0: [sda] tag#12 uas_zap_pending 0 uas-tag 4 inflight: CMD [33963.462754] sd 0:0:0:0: [sda] tag#12 CDB: Write(16) 8a 00 00 00 00 00 82 c1 d0 00 00 00 02 4c 00 00 [33963.462762] sd 0:0:0:0: [sda] tag#13 uas_zap_pending 0 uas-tag 5 inflight: CMD [33963.462769] sd 0:0:0:0: [sda] tag#13 CDB: Write(16) 8a 00 00 00 00 00 82 c1 d4 00 00 00 00 ff 00 00 [33963.462777] sd 0:0:0:0: [sda] tag#14 uas_zap_pending 0 uas-tag 6 inflight: CMD [33963.462783] sd 0:0:0:0: [sda] tag#14 CDB: Write(16) 8a 00 00 00 00 00 82 c1 ce 00 00 00 00 cc 00 00 [33963.576991] usb 7-1: reset SuperSpeed Plus Gen 2x1 USB device number 9 using xhci_hcd [33963.590793] scsi host0: uas_eh_device_reset_handler success [33963.592857] sd 0:0:0:0: [sda] tag#10 timing out command, waited 180s [33963.592872] sd 0:0:0:0: [sda] tag#10 FAILED Result: hostbyte=DID_RESET driverbyte=DRIVER_OK cmd_age=182s [33963.592881] sd 0:0:0:0: [sda] tag#10 CDB: Write(16) 8a 00 00 00 00 00 82 c1 bc 00 00 00 04 00 00 00 [33963.592886] I/O error, dev sda, sector 2193734656 op 0x1:(WRITE) flags 0x104000 phys_seg 773 prio class 2 [33963.592898] bcachefs (sda1 inum 1073761281 offset 265216): data write error: I/O [33963.592925] bcachefs (sda1 inum 1073761281 offset 467456): data write error: I/O [33963.592933] bcachefs (sda1 inum 1073761281 offset 470016): data write error: I/O [33963.592939] bcachefs (sda1 inum 1073761281 offset 471552): data write error: I/O [33963.592949] bcachefs (sda1 inum 1073761281 offset 514560): data write error: I/O [33963.592956] bcachefs (sda1 inum 1073761281 offset 517120): data write error: I/O [33963.592963] bcachefs (sda1 inum 1073761281 offset 519168): data write error: I/O [33963.592969] bcachefs (sda1 inum 1073761281 offset 521728): data write error: I/O [33963.592976] bcachefs (sda1 inum 1073761281 offset 523776): data write error: I/O [33963.592983] bcachefs (sda1 inum 1073761281 offset 526336): data write error: I/O The rsync completed but I did not trust the result, even tough "bcachefs fsck" told me the filesystem structure is okay. Thus I reran rsync with option "-c" for checksumming. After a long time with data that did match, it started to transfer a file again which should not happen if data would have been identical. As it ran into I/O errors again, I stopped the rsync process. I looked for that UAS error message and according to the article² I found I disabled UAS as follows: % cat /etc/modprobe.d/disable-uas.conf # Does not work with external SSD Transcend XS2000 4TB options usb-storage quirks=0951:176b:u The quirk was applied as I reconnected the devices after unloading both usb-storage and uas modules: [ 55.871301] usb 7-1: UAS is ignored for this device, using usb-storage instead [ 55.871310] usb-storage 7-1:1.0: USB Mass Storage device detected [ 55.871559] usb-storage 7-1:1.0: Quirks match for vid 0951 pid 176b: 800000 I recreated the BCacheFS filesystem and tried again. This time it did not take more than 10 minutes for the first I/O error to appear. Unless with UAS it made rsync stop with an I/O error immediately. Before that there were several USB resets. Here is the excerpt from dmesg: [ 795.768306] usb 7-1: reset SuperSpeed Plus Gen 2x1 USB device number 4 using xhci_hcd [ 932.976677] usb 7-1: reset SuperSpeed Plus Gen 2x1 USB device number 4 using xhci_hcd [ 963.189438] usb 7-1: reset SuperSpeed Plus Gen 2x1 USB device number 4 using xhci_hcd [ 1000.057333] usb 7-1: reset SuperSpeed Plus Gen 2x1 USB device number 4 using xhci_hcd [ 1036.917137] usb 7-1: reset SuperSpeed Plus Gen 2x1 USB device number 4 using xhci_hcd [ 1073.782876] usb 7-1: reset SuperSpeed Plus Gen 2x1 USB device number 4 using xhci_hcd [ 1110.647786] usb 7-1: reset SuperSpeed Plus Gen 2x1 USB device number 4 using xhci_hcd [ 1117.163693] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=214s [ 1117.163718] sd 0:0:0:0: [sda] tag#0 CDB: Write(16) 8a 00 00 00 00 00 02 72 20 00 00 00 08 00 00 00 [ 1117.163725] I/O error, dev sda, sector 41033728 op 0x1:(WRITE) flags 0x104000 phys_seg 1551 prio class 2 [ 1117.163739] bcachefs (sda1 inum 1879048481 offset 2572800): data write error: I/O [ 1117.163763] bcachefs (sda1 inum 1879048481 offset 2576384): data write error: I/O [ 1117.163771] bcachefs (sda1 inum 1879048481 offset 2578432): data write error: I/O [ 1117.163779] bcachefs (sda1 inum 1879048481 offset 2580480): data write error: I/O [ 1117.163786] bcachefs (sda1 inum 1879048481 offset 2582528): data write error: I/O [ 1117.163794] bcachefs (sda1 inum 1879048481 offset 2584576): data write error: I/O [ 1117.163803] bcachefs (sda1 inum 1879048481 offset 2586624): data write error: I/O [ 1117.163811] bcachefs (sda1 inum 1879048481 offset 2588672): data write error: I/O [ 1117.163818] bcachefs (sda1 inum 1879048481 offset 2590720): data write error: I/O [ 1117.163824] bcachefs (sda1 inum 1879048481 offset 2592768): data write error: I/O So even without UAS the device does not seem to like to write data on Linux. Next steps may involve looking for a firmware update for the external SSD as well as trying to obtain its SMART status. So far I did not succeed in finding the right options for smartctl. In case there is enough evidence that the device is defective I'd try to RMA it. I will keep a copy of kernel log and I could do some further tests as time permits. So let me know whether you need anything else, but for now the mail is long enough as it is. [1] https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html [2] How to disable USB Attached Storage (UAS) Last edited on 4 December 2022, at 14:00 https://leo.leung.xyz/wiki/How_to_disable_USB_Attached_Storage_(UAS) Ciao, -- Martin

1 year, 7 months

4
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2024