Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

66 participants
123762 discussions

[PATCH 1/2] writeback: fix 100% CPU usage when dirtytime_expire_interval is 0

by Laveesh Bansal

When vm.dirtytime_expire_seconds is set to 0, wakeup_dirtytime_writeback() schedules delayed work with a delay of 0, causing immediate execution. The function then reschedules itself with 0 delay again, creating an infinite busy loop that causes 100% kworker CPU usage. Fix by: - Only scheduling delayed work in wakeup_dirtytime_writeback() when dirtytime_expire_interval is non-zero - Cancelling the delayed work in dirtytime_interval_handler() when the interval is set to 0 - Adding a guard in start_dirtytime_writeback() for defensive coding Tested by booting kernel in QEMU with virtme-ng: - Before fix: kworker CPU spikes to ~73% - After fix: CPU remains at normal levels - Setting interval back to non-zero correctly resumes writeback Fixes: a2f4870697a5 ("fs: make sure the timestamps for lazytime inodes eventually get written") Cc: stable(a)vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220227 Signed-off-by: Laveesh Bansal <laveeshb(a)laveeshbansal.com> --- fs/fs-writeback.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 6800886c4d10..cd21c74cd0e5 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -2492,7 +2492,8 @@ static void wakeup_dirtytime_writeback(struct work_struct *w) wb_wakeup(wb); } rcu_read_unlock(); - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); } static int dirtytime_interval_handler(const struct ctl_table *table, int write, @@ -2501,8 +2502,12 @@ static int dirtytime_interval_handler(const struct ctl_table *table, int write, int ret; ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos); - if (ret == 0 && write) - mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + if (ret == 0 && write) { + if (dirtytime_expire_interval) + mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + else + cancel_delayed_work_sync(&dirtytime_work); + } return ret; } @@ -2519,7 +2524,8 @@ static const struct ctl_table vm_fs_writeback_table[] = { static int __init start_dirtytime_writeback(void) { - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); register_sysctl_init("vm", vm_fs_writeback_table); return 0; } -- 2.43.0

19 hours, 32 minutes

[PATCH 1/2] writeback: fix 100% CPU usage when dirtytime_expire_interval is 0

by Laveesh Bansal

From: Laveesh Bansal <laveeshbansal(a)gmail.com> When vm.dirtytime_expire_seconds is set to 0, wakeup_dirtytime_writeback() schedules delayed work with a delay of 0, causing immediate execution. The function then reschedules itself with 0 delay again, creating an infinite busy loop that causes 100% kworker CPU usage. Fix by: - Only scheduling delayed work in wakeup_dirtytime_writeback() when dirtytime_expire_interval is non-zero - Cancelling the delayed work in dirtytime_interval_handler() when the interval is set to 0 - Adding a guard in start_dirtytime_writeback() for defensive coding Tested by booting kernel in QEMU with virtme-ng: - Before fix: kworker CPU spikes to ~73% - After fix: CPU remains at normal levels - Setting interval back to non-zero correctly resumes writeback Fixes: a2f4870697a5 ("fs: make sure the timestamps for lazytime inodes eventually get written") Cc: stable(a)vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220227 Signed-off-by: Laveesh Bansal <laveeshbansal(a)gmail.com> --- fs/fs-writeback.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 6800886c4d10..cd21c74cd0e5 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -2492,7 +2492,8 @@ static void wakeup_dirtytime_writeback(struct work_struct *w) wb_wakeup(wb); } rcu_read_unlock(); - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); } static int dirtytime_interval_handler(const struct ctl_table *table, int write, @@ -2501,8 +2502,12 @@ static int dirtytime_interval_handler(const struct ctl_table *table, int write, int ret; ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos); - if (ret == 0 && write) - mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + if (ret == 0 && write) { + if (dirtytime_expire_interval) + mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + else + cancel_delayed_work_sync(&dirtytime_work); + } return ret; } @@ -2519,7 +2524,8 @@ static const struct ctl_table vm_fs_writeback_table[] = { static int __init start_dirtytime_writeback(void) { - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); register_sysctl_init("vm", vm_fs_writeback_table); return 0; } -- 2.43.0

19 hours, 46 minutes

Re: NRF 2026 Retail's Big Show more information

by Amy Giles

Hi, I wanted to see if you had time to review the email I sent earlier. Should you need any other details, don't hesitate to reach out. Best Amy Giles Please reply with REMOVE if you don't wish to receive further emails -----Original Message----- Hi, Hope you're having a great day! Are you looking for leads from NRF 2026 Retail's Big Show? Attendees count: 30,000 Leads Data Fields: Company Name, Web URL, Contact Name, Title, Direct Email, Phone Number, Mailing Address, Industry, Employee Size, Annual Sales. If you're interested in these leads, I'd be glad to share the pricing. Let me know! Thanks for the quick reply. I'm excited to get your thoughts. Best Amy Giles Demand Generation Manager Zoom Connect, Inc Please reply with REMOVE if you don't wish to receive further emails

19 hours, 56 minutes

[PATCH] cacheinfo: Remove of_node_put() for fw_token

by Petr Malat

fw_token is used for DT/ACPI systems to identify CPUs sharing caches. For DT based systems, fw_token is set to a pointer to a DT node. Commit 22def0b492e6 ("arch_topology: Build cacheinfo from primary CPU") removed clearing of per_cpu_cacheinfo(cpu), which leads to reference underrun in cache_shared_cpu_map_remove() during repeated cpu offline/online as the reference is no longer incremented, because allocate_cache_info() is now skipped in the online path. The same problem existed on upstream but had a different root cause, see 2613cc29c572 ("cacheinfo: Remove of_node_put() for fw_token"). Fixes the following splat: OF: ERROR: Bad of_node_put() on /cpus/l2-cache0 CPU: 3 PID: 29 Comm: cpuhp/3 Tainted: G O 6.1.159-arm64 #1 Hardware name: AXM56xx Victoria (DT) Call trace: dump_backtrace+0xd8/0x12c show_stack+0x1c/0x34 dump_stack_lvl+0x70/0x88 dump_stack+0x14/0x2c of_node_release+0x134/0x138 kobject_put+0xa8/0x21c of_node_put+0x1c/0x28 cache_shared_cpu_map_remove+0x19c/0x220 cacheinfo_cpu_pre_down+0x60/0xa0 cpuhp_invoke_callback+0x140/0x570 cpuhp_thread_fun+0xc8/0x19c smpboot_thread_fn+0x218/0x23c kthread+0x108/0x118 ret_from_fork+0x10/0x20 Fixes: 22def0b492e6 ("arch_topology: Build cacheinfo from primary CPU") Signed-off-by: Petr Malat <oss(a)malat.biz> --- drivers/base/cacheinfo.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c index 9e11d42b0d64..b57f64725f25 100644 --- a/drivers/base/cacheinfo.c +++ b/drivers/base/cacheinfo.c @@ -404,8 +404,6 @@ static void cache_shared_cpu_map_remove(unsigned int cpu) } } } - if (of_have_populated_dt()) - of_node_put(this_leaf->fw_token); } /* cpu is no longer populated in the shared map */ -- 2.39.5

20 hours, 12 minutes

[PATCH v2] arm64: kernel: initialize missing kexec_buf->random field

by Yeoreum Yun

Commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") introduced the kexec_buf->random field to enable random placement of kexec_buf. However, this field was never properly initialized for kexec images that do not need to be placed randomly, leading to the following UBSAN warning: [ +0.364528] ------------[ cut here ]------------ [ +0.000019] UBSAN: invalid-load in ./include/linux/kexec.h:210:12 [ +0.000131] load of value 2 is not a valid value for type 'bool' (aka '_Bool') [ +0.000003] CPU: 4 UID: 0 PID: 927 Comm: kexec Not tainted 6.18.0-rc7+ #3 PREEMPT(full) [ +0.000002] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 [ +0.000000] Call trace: [ +0.000001] show_stack+0x24/0x40 (C) [ +0.000006] __dump_stack+0x28/0x48 [ +0.000002] dump_stack_lvl+0x7c/0xb0 [ +0.000002] dump_stack+0x18/0x34 [ +0.000001] ubsan_epilogue+0x10/0x50 [ +0.000002] __ubsan_handle_load_invalid_value+0xc8/0xd0 [ +0.000003] locate_mem_hole_callback+0x28c/0x2a0 [ +0.000003] kexec_locate_mem_hole+0xf4/0x2f0 [ +0.000001] kexec_add_buffer+0xa8/0x178 [ +0.000002] image_load+0xf0/0x258 [ +0.000001] __arm64_sys_kexec_file_load+0x510/0x718 [ +0.000002] invoke_syscall+0x68/0xe8 [ +0.000001] el0_svc_common+0xb0/0xf8 [ +0.000002] do_el0_svc+0x28/0x48 [ +0.000001] el0_svc+0x40/0xe8 [ +0.000002] el0t_64_sync_handler+0x84/0x140 [ +0.000002] el0t_64_sync+0x1bc/0x1c0 To address this, initialise kexec_buf->random field properly. Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Suggested-by: Breno Leitao <leitao(a)debian.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> --- arch/arm64/kernel/kexec_image.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c index 532d72ea42ee..b70f4df15a1a 100644 --- a/arch/arm64/kernel/kexec_image.c +++ b/arch/arm64/kernel/kexec_image.c @@ -41,7 +41,7 @@ static void *image_load(struct kimage *image, struct arm64_image_header *h; u64 flags, value; bool be_image, be_kernel; - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; unsigned long text_offset, kernel_segment_number; struct kexec_segment *kernel_segment; int ret; -- LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

20 hours, 43 minutes

[PATCH] iommu/arm-smmu-v3: Maintain valid access attributes for non-coherent SMMU

by Dawei Li

According to SMMUv3 architecture specification, IO-coherent access for SMMU is supported for: - Translation table walks. - Fetches of L1STD, STE, L1CD and CD. - Command queue, Event queue and PRI queue access. - GERROR, CMD_SYNC, Event queue and PRI queue MSIs, if supported In other words, if a SMMU implementation doesn't support IO coherent access(SMMUIDR0.COHACC==0), all fields above accessed by SMMU is expected to be non-coherent and S/W is supposed to maintain proper access attributes to achieve expected behavior. Unfortunately, for non-coherent SMMU implementation, current codebase only takes care of translation table walking. Fix it by providing right attributes(cacheability, shareablility, cache allocation hints, e.g) to other fields. Fixes: 4f41845b3407 ("iommu/io-pgtable: Replace IO_PGTABLE_QUIRK_NO_DMA with specific flag") Fixes: 9e6ea59f3ff3 ("iommu/io-pgtable: Support non-coherent page tables") Cc: stable(a)vger.kernel.org Signed-off-by: Dawei Li <dawei.li(a)linux.dev> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 73 +++++++++++++++------ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 + 2 files changed, 54 insertions(+), 20 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index d16d35c78c06..4f00bf53d26c 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -265,8 +265,14 @@ static int queue_remove_raw(struct arm_smmu_queue *q, u64 *ent) return 0; } +static __always_inline bool smmu_coherent(struct arm_smmu_device *smmu) +{ + return !!(smmu->features & ARM_SMMU_FEAT_COHERENCY); +} + /* High-level queue accessors */ -static int arm_smmu_cmdq_build_cmd(u64 *cmd, struct arm_smmu_cmdq_ent *ent) +static int arm_smmu_cmdq_build_cmd(u64 *cmd, struct arm_smmu_cmdq_ent *ent, + struct arm_smmu_device *smmu) { memset(cmd, 0, 1 << CMDQ_ENT_SZ_SHIFT); cmd[0] |= FIELD_PREP(CMDQ_0_OP, ent->opcode); @@ -358,8 +364,13 @@ static int arm_smmu_cmdq_build_cmd(u64 *cmd, struct arm_smmu_cmdq_ent *ent) } else { cmd[0] |= FIELD_PREP(CMDQ_SYNC_0_CS, CMDQ_SYNC_0_CS_SEV); } - cmd[0] |= FIELD_PREP(CMDQ_SYNC_0_MSH, ARM_SMMU_SH_ISH); - cmd[0] |= FIELD_PREP(CMDQ_SYNC_0_MSIATTR, ARM_SMMU_MEMATTR_OIWB); + if (smmu_coherent(smmu)) { + cmd[0] |= FIELD_PREP(CMDQ_SYNC_0_MSH, ARM_SMMU_SH_ISH); + cmd[0] |= FIELD_PREP(CMDQ_SYNC_0_MSIATTR, ARM_SMMU_MEMATTR_OIWB); + } else { + cmd[0] |= FIELD_PREP(CMDQ_SYNC_0_MSH, ARM_SMMU_SH_OSH); + cmd[0] |= FIELD_PREP(CMDQ_SYNC_0_MSIATTR, ARM_SMMU_MEMATTR_OINC); + } break; default: return -ENOENT; @@ -405,7 +416,7 @@ static void arm_smmu_cmdq_build_sync_cmd(u64 *cmd, struct arm_smmu_device *smmu, q->ent_dwords * 8; } - arm_smmu_cmdq_build_cmd(cmd, &ent); + arm_smmu_cmdq_build_cmd(cmd, &ent, smmu); if (arm_smmu_cmdq_needs_busy_polling(smmu, cmdq)) u64p_replace_bits(cmd, CMDQ_SYNC_0_CS_NONE, CMDQ_SYNC_0_CS); } @@ -461,7 +472,7 @@ void __arm_smmu_cmdq_skip_err(struct arm_smmu_device *smmu, dev_err(smmu->dev, "\t0x%016llx\n", (unsigned long long)cmd[i]); /* Convert the erroneous command into a CMD_SYNC */ - arm_smmu_cmdq_build_cmd(cmd, &cmd_sync); + arm_smmu_cmdq_build_cmd(cmd, &cmd_sync, smmu); if (arm_smmu_cmdq_needs_busy_polling(smmu, cmdq)) u64p_replace_bits(cmd, CMDQ_SYNC_0_CS_NONE, CMDQ_SYNC_0_CS); @@ -913,7 +924,7 @@ static int __arm_smmu_cmdq_issue_cmd(struct arm_smmu_device *smmu, { u64 cmd[CMDQ_ENT_DWORDS]; - if (unlikely(arm_smmu_cmdq_build_cmd(cmd, ent))) { + if (unlikely(arm_smmu_cmdq_build_cmd(cmd, ent, smmu))) { dev_warn(smmu->dev, "ignoring unknown CMDQ opcode 0x%x\n", ent->opcode); return -EINVAL; @@ -965,7 +976,7 @@ static void arm_smmu_cmdq_batch_add(struct arm_smmu_device *smmu, } index = cmds->num * CMDQ_ENT_DWORDS; - if (unlikely(arm_smmu_cmdq_build_cmd(&cmds->cmds[index], cmd))) { + if (unlikely(arm_smmu_cmdq_build_cmd(&cmds->cmds[index], cmd, smmu))) { dev_warn(smmu->dev, "ignoring unknown CMDQ opcode 0x%x\n", cmd->opcode); return; @@ -1603,6 +1614,7 @@ void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target, { struct arm_smmu_ctx_desc_cfg *cd_table = &master->cd_table; struct arm_smmu_device *smmu = master->smmu; + u64 val; memset(target, 0, sizeof(*target)); target->data[0] = cpu_to_le64( @@ -1612,11 +1624,18 @@ void arm_smmu_make_cdtable_ste(struct arm_smmu_ste *target, (cd_table->cdtab_dma & STRTAB_STE_0_S1CTXPTR_MASK) | FIELD_PREP(STRTAB_STE_0_S1CDMAX, cd_table->s1cdmax)); + if (smmu_coherent(smmu)) { + val = FIELD_PREP(STRTAB_STE_1_S1CIR, STRTAB_STE_1_S1C_CACHE_WBRA) | + FIELD_PREP(STRTAB_STE_1_S1COR, STRTAB_STE_1_S1C_CACHE_WBRA) | + FIELD_PREP(STRTAB_STE_1_S1CSH, ARM_SMMU_SH_ISH); + } else { + val = FIELD_PREP(STRTAB_STE_1_S1CIR, STRTAB_STE_1_S1C_CACHE_NC) | + FIELD_PREP(STRTAB_STE_1_S1COR, STRTAB_STE_1_S1C_CACHE_NC) | + FIELD_PREP(STRTAB_STE_1_S1CSH, ARM_SMMU_SH_OSH); + } + target->data[1] = cpu_to_le64( - FIELD_PREP(STRTAB_STE_1_S1DSS, s1dss) | - FIELD_PREP(STRTAB_STE_1_S1CIR, STRTAB_STE_1_S1C_CACHE_WBRA) | - FIELD_PREP(STRTAB_STE_1_S1COR, STRTAB_STE_1_S1C_CACHE_WBRA) | - FIELD_PREP(STRTAB_STE_1_S1CSH, ARM_SMMU_SH_ISH) | + FIELD_PREP(STRTAB_STE_1_S1DSS, s1dss) | val | ((smmu->features & ARM_SMMU_FEAT_STALLS && !master->stall_enabled) ? STRTAB_STE_1_S1STALLD : @@ -3746,7 +3765,7 @@ int arm_smmu_init_one_queue(struct arm_smmu_device *smmu, q->cons_reg = page + cons_off; q->ent_dwords = dwords; - q->q_base = Q_BASE_RWA; + q->q_base = smmu_coherent(smmu) ? Q_BASE_RWA : 0; q->q_base |= q->base_dma & Q_BASE_ADDR_MASK; q->q_base |= FIELD_PREP(Q_BASE_LOG2SIZE, q->llq.max_n_shift); @@ -4093,6 +4112,7 @@ static void arm_smmu_write_strtab(struct arm_smmu_device *smmu) struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg; dma_addr_t dma; u32 reg; + u64 val; if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) { reg = FIELD_PREP(STRTAB_BASE_CFG_FMT, @@ -4107,8 +4127,12 @@ static void arm_smmu_write_strtab(struct arm_smmu_device *smmu) FIELD_PREP(STRTAB_BASE_CFG_LOG2SIZE, smmu->sid_bits); dma = cfg->linear.ste_dma; } - writeq_relaxed((dma & STRTAB_BASE_ADDR_MASK) | STRTAB_BASE_RA, - smmu->base + ARM_SMMU_STRTAB_BASE); + + val = dma & STRTAB_BASE_ADDR_MASK; + if (smmu_coherent(smmu)) + val |= STRTAB_BASE_RA; + + writeq_relaxed(val, smmu->base + ARM_SMMU_STRTAB_BASE); writel_relaxed(reg, smmu->base + ARM_SMMU_STRTAB_BASE_CFG); } @@ -4130,12 +4154,21 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu) return ret; /* CR1 (table and queue memory attributes) */ - reg = FIELD_PREP(CR1_TABLE_SH, ARM_SMMU_SH_ISH) | - FIELD_PREP(CR1_TABLE_OC, CR1_CACHE_WB) | - FIELD_PREP(CR1_TABLE_IC, CR1_CACHE_WB) | - FIELD_PREP(CR1_QUEUE_SH, ARM_SMMU_SH_ISH) | - FIELD_PREP(CR1_QUEUE_OC, CR1_CACHE_WB) | - FIELD_PREP(CR1_QUEUE_IC, CR1_CACHE_WB); + if (smmu_coherent(smmu)) { + reg = FIELD_PREP(CR1_TABLE_SH, ARM_SMMU_SH_ISH) | + FIELD_PREP(CR1_TABLE_OC, CR1_CACHE_WB) | + FIELD_PREP(CR1_TABLE_IC, CR1_CACHE_WB) | + FIELD_PREP(CR1_QUEUE_SH, ARM_SMMU_SH_ISH) | + FIELD_PREP(CR1_QUEUE_OC, CR1_CACHE_WB) | + FIELD_PREP(CR1_QUEUE_IC, CR1_CACHE_WB); + } else { + reg = FIELD_PREP(CR1_TABLE_SH, ARM_SMMU_SH_OSH) | + FIELD_PREP(CR1_TABLE_OC, CR1_CACHE_NC) | + FIELD_PREP(CR1_TABLE_IC, CR1_CACHE_NC) | + FIELD_PREP(CR1_QUEUE_SH, ARM_SMMU_SH_OSH) | + FIELD_PREP(CR1_QUEUE_OC, CR1_CACHE_NC) | + FIELD_PREP(CR1_QUEUE_IC, CR1_CACHE_NC); + } writel_relaxed(reg, smmu->base + ARM_SMMU_CR1); /* CR2 (random crap) */ diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h index ae23aacc3840..7a5f76e165dc 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -183,6 +183,7 @@ struct arm_vsmmu; #define ARM_SMMU_SH_ISH 3 #define ARM_SMMU_MEMATTR_DEVICE_nGnRE 0x1 #define ARM_SMMU_MEMATTR_OIWB 0xf +#define ARM_SMMU_MEMATTR_OINC 0x5 #define Q_IDX(llq, p) ((p) & ((1 << (llq)->max_n_shift) - 1)) #define Q_WRP(llq, p) ((p) & (1 << (llq)->max_n_shift)) -- 2.25.1

21 hours, 6 minutes

[PATCH v2 0/1] fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()

by Joanne Koong

This patch reverts fuse back to its original behavior of sync being a no-op. This fixes the userspace regression reported by Athul and J. upstream in [1][2] where if there is a bug in a fuse server that causes the server to never complete writeback, it will make wait_sb_inodes() wait forever. Thanks, Joanne [1] https://lore.kernel.org/regressions/CAJnrk1ZjQ8W8NzojsvJPRXiv9TuYPNdj8Ye7=C… [2] https://lore.kernel.org/linux-fsdevel/aT7JRqhUvZvfUQlV@eldamar.lan/ Changelog: v1: https://lore.kernel.org/linux-mm/20251120184211.2379439-1-joannelkoong@gmai… * Change AS_WRITEBACK_MAY_HANG to AS_NO_DATA_INTEGRITY and keep AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM as is. Joanne Koong (1): fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes() fs/fs-writeback.c | 3 ++- fs/fuse/file.c | 4 +++- include/linux/pagemap.h | 11 +++++++++++ 3 files changed, 16 insertions(+), 2 deletions(-) -- 2.47.3

22 hours, 5 minutes

RE: CES 2026: Audience Breakdown & Leads

by Jessica Garcia

Hi , Just touching base to see if you're available to discuss this further. If you have any uncertainties, I'm happy to help. Regards Jessica Marketing Manager Campaign Data Leads., Please reply with REMOVE if you don't wish to receive further emails -----Original Message----- From: Jessica Garcia Subject: CES 2026: Audience Breakdown & Leads Hi , Trust you're in good spirits. Is the idea of buying the CES 2026 attendees' details for your marketing efforts something you'd like to explore? Expo Name: Consumer Electronics Show 2026 Total Number of records: 40,000 records List includes: Company Name, Contact Name, Job Title, Mailing Address, Phone, Emails, etc. Best chance to connect with participants Feel free to contact me if you are interested in acquiring this list so that I can share pricing information with you Hoping for your prompt feedback. Regards Jessica Marketing Manager Campaign Data Leads., Please reply with REMOVE if you don't wish to receive further emails

22 hours, 19 minutes

[PATCH 2/5] ARM: dts: microchip: sama7d65: fix size-cells property for i2c3

by nicolas.ferre＠microchip.com

From: Nicolas Ferre <nicolas.ferre(a)microchip.com> Fix the #size-cells property for i2c3 node and remove the dtbs_check error telling that "#size-cells: 0 was expected" from schema atmel,at91sam-i2c.yaml and i2c-controller.yaml. Fixes: b51e4aea3ecf ("ARM: dts: microchip: sama7d65: Add FLEXCOMs to sama7d65 SoC") Cc: <stable(a)vger.kernel.org> # 6.16+ Signed-off-by: Nicolas Ferre <nicolas.ferre(a)microchip.com> --- arch/arm/boot/dts/microchip/sama7d65.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi index 5f3a7b178aa7..868045c650a7 100644 --- a/arch/arm/boot/dts/microchip/sama7d65.dtsi +++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi @@ -527,7 +527,7 @@ i2c3: i2c@600 { interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; clocks = <&pmc PMC_TYPE_PERIPHERAL 37>; #address-cells = <1>; - #size-cells = <1>; + #size-cells = <0>; dmas = <&dma0 AT91_XDMAC_DT_PERID(12)>, <&dma0 AT91_XDMAC_DT_PERID(11)>; dma-names = "tx", "rx"; -- 2.43.0

22 hours, 46 minutes

[PATCH 1/5] ARM: dts: microchip: sama7d65: fix the ranges property for flx9

by nicolas.ferre＠microchip.com

From: Hari Prasath Gujulan Elango <hari.prasathge(a)microchip.com> Update the ranges property for the flexcom9 as per the datasheet and align with the reg property. Fixes: b51e4aea3ecf ("ARM: dts: microchip: sama7d65: Add FLEXCOMs to sama7d65 SoC") Cc: <stable(a)vger.kernel.org> # 6.16+ Signed-off-by: Hari Prasath Gujulan Elango <hari.prasathge(a)microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre(a)microchip.com> --- Note: Hari's email address will bounce. Change to whichever suits you. arch/arm/boot/dts/microchip/sama7d65.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi index cd2cf9a6f40b..5f3a7b178aa7 100644 --- a/arch/arm/boot/dts/microchip/sama7d65.dtsi +++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi @@ -676,7 +676,7 @@ i2c8: i2c@600 { flx9: flexcom@e2820000 { compatible = "microchip,sama7d65-flexcom", "atmel,sama5d2-flexcom"; reg = <0xe2820000 0x200>; - ranges = <0x0 0xe281c000 0x800>; + ranges = <0x0 0xe2820000 0x800>; clocks = <&pmc PMC_TYPE_PERIPHERAL 43>; #address-cells = <1>; #size-cells = <1>; -- 2.43.0

22 hours, 46 minutes

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror