May 2024 - Linux-stable-mirror

[PATCH v3 7/8] drm/amdgpu: fix locking scope when flushing tlb

by Yunxiang Li

Which method is used to flush tlb does not depend on whether a reset is in progress or not. We should skip flush altogether if the GPU will get reset. So put both path under reset_domain read lock. Signed-off-by: Yunxiang Li <Yunxiang.Li(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> CC: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 66 +++++++++++++------------ 1 file changed, 34 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c index 603c0738fd03..4edd10b10a92 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c @@ -684,12 +684,17 @@ int amdgpu_gmc_flush_gpu_tlb_pasid(struct amdgpu_device *adev, uint16_t pasid, struct amdgpu_ring *ring = &adev->gfx.kiq[inst].ring; struct amdgpu_kiq *kiq = &adev->gfx.kiq[inst]; unsigned int ndw; - signed long r; + int r; uint32_t seq; - if (!adev->gmc.flush_pasid_uses_kiq || !ring->sched.ready || - !down_read_trylock(&adev->reset_domain->sem)) { + /* + * A GPU reset should flush all TLBs anyway, so no need to do + * this while one is ongoing. + */ + if (!down_read_trylock(&adev->reset_domain->sem)) + return 0; + if (!adev->gmc.flush_pasid_uses_kiq || !ring->sched.ready) { if (adev->gmc.flush_tlb_needs_extra_type_2) adev->gmc.gmc_funcs->flush_gpu_tlb_pasid(adev, pasid, 2, all_hub, @@ -703,43 +708,40 @@ int amdgpu_gmc_flush_gpu_tlb_pasid(struct amdgpu_device *adev, uint16_t pasid, adev->gmc.gmc_funcs->flush_gpu_tlb_pasid(adev, pasid, flush_type, all_hub, inst); - return 0; - } + r = 0; + } else { + /* 2 dwords flush + 8 dwords fence */ + ndw = kiq->pmf->invalidate_tlbs_size + 8; - /* 2 dwords flush + 8 dwords fence */ - ndw = kiq->pmf->invalidate_tlbs_size + 8; + if (adev->gmc.flush_tlb_needs_extra_type_2) + ndw += kiq->pmf->invalidate_tlbs_size; - if (adev->gmc.flush_tlb_needs_extra_type_2) - ndw += kiq->pmf->invalidate_tlbs_size; + if (adev->gmc.flush_tlb_needs_extra_type_0) + ndw += kiq->pmf->invalidate_tlbs_size; - if (adev->gmc.flush_tlb_needs_extra_type_0) - ndw += kiq->pmf->invalidate_tlbs_size; + spin_lock(&adev->gfx.kiq[inst].ring_lock); + amdgpu_ring_alloc(ring, ndw); + if (adev->gmc.flush_tlb_needs_extra_type_2) + kiq->pmf->kiq_invalidate_tlbs(ring, pasid, 2, all_hub); - spin_lock(&adev->gfx.kiq[inst].ring_lock); - amdgpu_ring_alloc(ring, ndw); - if (adev->gmc.flush_tlb_needs_extra_type_2) - kiq->pmf->kiq_invalidate_tlbs(ring, pasid, 2, all_hub); + if (flush_type == 2 && adev->gmc.flush_tlb_needs_extra_type_0) + kiq->pmf->kiq_invalidate_tlbs(ring, pasid, 0, all_hub); - if (flush_type == 2 && adev->gmc.flush_tlb_needs_extra_type_0) - kiq->pmf->kiq_invalidate_tlbs(ring, pasid, 0, all_hub); + kiq->pmf->kiq_invalidate_tlbs(ring, pasid, flush_type, all_hub); + r = amdgpu_fence_emit_polling(ring, &seq, MAX_KIQ_REG_WAIT); + if (r) { + amdgpu_ring_undo(ring); + spin_unlock(&adev->gfx.kiq[inst].ring_lock); + goto error_unlock_reset; + } - kiq->pmf->kiq_invalidate_tlbs(ring, pasid, flush_type, all_hub); - r = amdgpu_fence_emit_polling(ring, &seq, MAX_KIQ_REG_WAIT); - if (r) { - amdgpu_ring_undo(ring); + amdgpu_ring_commit(ring); spin_unlock(&adev->gfx.kiq[inst].ring_lock); - goto error_unlock_reset; - } - - amdgpu_ring_commit(ring); - spin_unlock(&adev->gfx.kiq[inst].ring_lock); - r = amdgpu_fence_wait_polling(ring, seq, usec_timeout); - if (r < 1) { - dev_err(adev->dev, "wait for kiq fence error: %ld.\n", r); - r = -ETIME; - goto error_unlock_reset; + if (amdgpu_fence_wait_polling(ring, seq, usec_timeout) < 1) { + dev_err(adev->dev, "timeout waiting for kiq fence\n"); + r = -ETIME; + } } - r = 0; error_unlock_reset: up_read(&adev->reset_domain->sem); -- 2.34.1

4 months, 2 weeks

1
0
0 0

[PATCH] riscv: enable HAVE_ARCH_HUGE_VMAP for XIP kernel

by Nam Cao

HAVE_ARCH_HUGE_VMAP also works on XIP kernel, so remove its dependency on !XIP_KERNEL. This also fixes a boot problem for XIP kernel introduced by the commit in "Fixes:". This commit used huge page mapping for vmemmap, but huge page vmap was not enabled for XIP kernel. Fixes: ff172d4818ad ("riscv: Use hugepage mappings for vmemmap") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Cc: <stable(a)vger.kernel.org> --- This patch replaces: https://patchwork.kernel.org/project/linux-riscv/patch/20240508173116.28661… arch/riscv/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index b94176e25be1..0525ee2d63c7 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -106,7 +106,7 @@ config RISCV select HAS_IOPORT if MMU select HAVE_ARCH_AUDITSYSCALL select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP - select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT && !XIP_KERNEL + select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL select HAVE_ARCH_KASAN if MMU && 64BIT -- 2.39.2

4 months, 2 weeks

3
2
0 0

[PATCH] drm/xe: Fix NULL ptr dereference in devcoredump

by Matthew Brost

Kernel VM do not have an Xe file. Include a check for Xe file in the VM before trying to get pid from VM's Xe file when taking a devcoredump. Fixes: b10d0c5e9df7 ("drm/xe: Add process name to devcoredump") Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: José Roberto de Souza <jose.souza(a)intel.com> Cc: stable(a)vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> --- drivers/gpu/drm/xe/xe_devcoredump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c index 1643d44f8bc4..6f63b8e4e3b9 100644 --- a/drivers/gpu/drm/xe/xe_devcoredump.c +++ b/drivers/gpu/drm/xe/xe_devcoredump.c @@ -176,7 +176,7 @@ static void devcoredump_snapshot(struct xe_devcoredump *coredump, ss->snapshot_time = ktime_get_real(); ss->boot_time = ktime_get_boottime(); - if (q->vm) { + if (q->vm && q->vm->xef) { task = get_pid_task(q->vm->xef->drm->pid, PIDTYPE_PID); if (task) process_name = task->comm; -- 2.34.1

4 months, 2 weeks

2
1
0 0

+ ocfs2-fix-null-pointer-dereference-in-ocfs2_abort_trigger.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: ocfs2: fix NULL pointer dereference in ocfs2_abort_trigger() has been added to the -mm mm-hotfixes-unstable branch. Its filename is ocfs2-fix-null-pointer-dereference-in-ocfs2_abort_trigger.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Joseph Qi <joseph.qi(a)linux.alibaba.com> Subject: ocfs2: fix NULL pointer dereference in ocfs2_abort_trigger() Date: Thu, 30 May 2024 19:06:30 +0800 bdev->bd_super has been removed and commit 8887b94d9322 change the usage from bdev->bd_super to b_assoc_map->host->i_sb. Since ocfs2 hasn't set bh->b_assoc_map, it will trigger NULL pointer dereference when calling into ocfs2_abort_trigger(). Actually this was pointed out in history, see commit 74e364ad1b13. But I've made a mistake when reviewing commit 8887b94d9322 and then reintroduce this regression. Since we cannot revive bdev in buffer head, we can get super block from ocfs2_caching_info first and then associate it with ocfs2_triggers to fix this issue. Link: https://lkml.kernel.org/r/20240530110630.3933832-2-joseph.qi@linux.alibaba.… Fixes: 8887b94d9322 ("ocfs2: stop using bdev->bd_super for journal error logging") Signed-off-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> [6.6+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/journal.c | 179 ++++++++++++++++++++++++++----------------- 1 file changed, 111 insertions(+), 68 deletions(-) --- a/fs/ocfs2/journal.c~ocfs2-fix-null-pointer-dereference-in-ocfs2_abort_trigger +++ a/fs/ocfs2/journal.c @@ -483,8 +483,24 @@ bail: struct ocfs2_triggers { struct jbd2_buffer_trigger_type ot_triggers; int ot_offset; + struct super_block *sb; }; +enum ocfs2_journal_trigger_type { + OCFS2_JTR_DI, + OCFS2_JTR_EB, + OCFS2_JTR_RB, + OCFS2_JTR_GD, + OCFS2_JTR_DB, + OCFS2_JTR_XB, + OCFS2_JTR_DQ, + OCFS2_JTR_DR, + OCFS2_JTR_DL, + OCFS2_JTR_NONE /* This must be the last entry */ +}; + +#define OCFS2_JOURNAL_TRIGGER_COUNT OCFS2_JTR_NONE + static inline struct ocfs2_triggers *to_ocfs2_trigger(struct jbd2_buffer_trigger_type *triggers) { return container_of(triggers, struct ocfs2_triggers, ot_triggers); @@ -548,85 +564,67 @@ static void ocfs2_db_frozen_trigger(stru static void ocfs2_abort_trigger(struct jbd2_buffer_trigger_type *triggers, struct buffer_head *bh) { + struct ocfs2_triggers *ot = to_ocfs2_trigger(triggers); + mlog(ML_ERROR, "ocfs2_abort_trigger called by JBD2. bh = 0x%lx, " "bh->b_blocknr = %llu\n", (unsigned long)bh, (unsigned long long)bh->b_blocknr); - ocfs2_error(bh->b_assoc_map->host->i_sb, + ocfs2_error(ot->sb, "JBD2 has aborted our journal, ocfs2 cannot continue\n"); } -static struct ocfs2_triggers di_triggers = { - .ot_triggers = { - .t_frozen = ocfs2_frozen_trigger, - .t_abort = ocfs2_abort_trigger, - }, - .ot_offset = offsetof(struct ocfs2_dinode, i_check), -}; - -static struct ocfs2_triggers eb_triggers = { - .ot_triggers = { - .t_frozen = ocfs2_frozen_trigger, - .t_abort = ocfs2_abort_trigger, - }, - .ot_offset = offsetof(struct ocfs2_extent_block, h_check), -}; - -static struct ocfs2_triggers rb_triggers = { - .ot_triggers = { - .t_frozen = ocfs2_frozen_trigger, - .t_abort = ocfs2_abort_trigger, - }, - .ot_offset = offsetof(struct ocfs2_refcount_block, rf_check), -}; - -static struct ocfs2_triggers gd_triggers = { - .ot_triggers = { - .t_frozen = ocfs2_frozen_trigger, - .t_abort = ocfs2_abort_trigger, - }, - .ot_offset = offsetof(struct ocfs2_group_desc, bg_check), -}; - -static struct ocfs2_triggers db_triggers = { - .ot_triggers = { - .t_frozen = ocfs2_db_frozen_trigger, - .t_abort = ocfs2_abort_trigger, - }, -}; - -static struct ocfs2_triggers xb_triggers = { - .ot_triggers = { - .t_frozen = ocfs2_frozen_trigger, - .t_abort = ocfs2_abort_trigger, - }, - .ot_offset = offsetof(struct ocfs2_xattr_block, xb_check), -}; - -static struct ocfs2_triggers dq_triggers = { - .ot_triggers = { - .t_frozen = ocfs2_dq_frozen_trigger, - .t_abort = ocfs2_abort_trigger, - }, -}; +static void ocfs2_setup_csum_triggers(struct super_block *sb, + enum ocfs2_journal_trigger_type type, + struct ocfs2_triggers *ot) +{ + BUG_ON(type >= OCFS2_JOURNAL_TRIGGER_COUNT); -static struct ocfs2_triggers dr_triggers = { - .ot_triggers = { - .t_frozen = ocfs2_frozen_trigger, - .t_abort = ocfs2_abort_trigger, - }, - .ot_offset = offsetof(struct ocfs2_dx_root_block, dr_check), -}; + switch (type) { + case OCFS2_JTR_DI: + ot->ot_triggers.t_frozen = ocfs2_frozen_trigger; + ot->ot_offset = offsetof(struct ocfs2_dinode, i_check); + break; + case OCFS2_JTR_EB: + ot->ot_triggers.t_frozen = ocfs2_frozen_trigger; + ot->ot_offset = offsetof(struct ocfs2_extent_block, h_check); + break; + case OCFS2_JTR_RB: + ot->ot_triggers.t_frozen = ocfs2_frozen_trigger; + ot->ot_offset = offsetof(struct ocfs2_refcount_block, rf_check); + break; + case OCFS2_JTR_GD: + ot->ot_triggers.t_frozen = ocfs2_frozen_trigger; + ot->ot_offset = offsetof(struct ocfs2_group_desc, bg_check); + break; + case OCFS2_JTR_DB: + ot->ot_triggers.t_frozen = ocfs2_db_frozen_trigger; + break; + case OCFS2_JTR_XB: + ot->ot_triggers.t_frozen = ocfs2_frozen_trigger; + ot->ot_offset = offsetof(struct ocfs2_xattr_block, xb_check); + break; + case OCFS2_JTR_DQ: + ot->ot_triggers.t_frozen = ocfs2_dq_frozen_trigger; + break; + case OCFS2_JTR_DR: + ot->ot_triggers.t_frozen = ocfs2_frozen_trigger; + ot->ot_offset = offsetof(struct ocfs2_dx_root_block, dr_check); + break; + case OCFS2_JTR_DL: + ot->ot_triggers.t_frozen = ocfs2_frozen_trigger; + ot->ot_offset = offsetof(struct ocfs2_dx_leaf, dl_check); + break; + case OCFS2_JTR_NONE: + /* To make compiler happy... */ + return; + } -static struct ocfs2_triggers dl_triggers = { - .ot_triggers = { - .t_frozen = ocfs2_frozen_trigger, - .t_abort = ocfs2_abort_trigger, - }, - .ot_offset = offsetof(struct ocfs2_dx_leaf, dl_check), -}; + ot->ot_triggers.t_abort = ocfs2_abort_trigger; + ot->sb = sb; +} static int __ocfs2_journal_access(handle_t *handle, struct ocfs2_caching_info *ci, @@ -708,18 +706,33 @@ static int __ocfs2_journal_access(handle int ocfs2_journal_access_di(handle_t *handle, struct ocfs2_caching_info *ci, struct buffer_head *bh, int type) { + struct ocfs2_triggers di_triggers; + + ocfs2_setup_csum_triggers(ocfs2_metadata_cache_get_super(ci), + OCFS2_JTR_DI, &di_triggers); + return __ocfs2_journal_access(handle, ci, bh, &di_triggers, type); } int ocfs2_journal_access_eb(handle_t *handle, struct ocfs2_caching_info *ci, struct buffer_head *bh, int type) { + struct ocfs2_triggers eb_triggers; + + ocfs2_setup_csum_triggers(ocfs2_metadata_cache_get_super(ci), + OCFS2_JTR_EB, &eb_triggers); + return __ocfs2_journal_access(handle, ci, bh, &eb_triggers, type); } int ocfs2_journal_access_rb(handle_t *handle, struct ocfs2_caching_info *ci, struct buffer_head *bh, int type) { + struct ocfs2_triggers rb_triggers; + + ocfs2_setup_csum_triggers(ocfs2_metadata_cache_get_super(ci), + OCFS2_JTR_RB, &rb_triggers); + return __ocfs2_journal_access(handle, ci, bh, &rb_triggers, type); } @@ -727,36 +740,66 @@ int ocfs2_journal_access_rb(handle_t *ha int ocfs2_journal_access_gd(handle_t *handle, struct ocfs2_caching_info *ci, struct buffer_head *bh, int type) { + struct ocfs2_triggers gd_triggers; + + ocfs2_setup_csum_triggers(ocfs2_metadata_cache_get_super(ci), + OCFS2_JTR_GD, &gd_triggers); + return __ocfs2_journal_access(handle, ci, bh, &gd_triggers, type); } int ocfs2_journal_access_db(handle_t *handle, struct ocfs2_caching_info *ci, struct buffer_head *bh, int type) { + struct ocfs2_triggers db_triggers; + + ocfs2_setup_csum_triggers(ocfs2_metadata_cache_get_super(ci), + OCFS2_JTR_DB, &db_triggers); + return __ocfs2_journal_access(handle, ci, bh, &db_triggers, type); } int ocfs2_journal_access_xb(handle_t *handle, struct ocfs2_caching_info *ci, struct buffer_head *bh, int type) { + struct ocfs2_triggers xb_triggers; + + ocfs2_setup_csum_triggers(ocfs2_metadata_cache_get_super(ci), + OCFS2_JTR_XB, &xb_triggers); + return __ocfs2_journal_access(handle, ci, bh, &xb_triggers, type); } int ocfs2_journal_access_dq(handle_t *handle, struct ocfs2_caching_info *ci, struct buffer_head *bh, int type) { + struct ocfs2_triggers dq_triggers; + + ocfs2_setup_csum_triggers(ocfs2_metadata_cache_get_super(ci), + OCFS2_JTR_DQ, &dq_triggers); + return __ocfs2_journal_access(handle, ci, bh, &dq_triggers, type); } int ocfs2_journal_access_dr(handle_t *handle, struct ocfs2_caching_info *ci, struct buffer_head *bh, int type) { + struct ocfs2_triggers dr_triggers; + + ocfs2_setup_csum_triggers(ocfs2_metadata_cache_get_super(ci), + OCFS2_JTR_DR, &dr_triggers); + return __ocfs2_journal_access(handle, ci, bh, &dr_triggers, type); } int ocfs2_journal_access_dl(handle_t *handle, struct ocfs2_caching_info *ci, struct buffer_head *bh, int type) { + struct ocfs2_triggers dl_triggers; + + ocfs2_setup_csum_triggers(ocfs2_metadata_cache_get_super(ci), + OCFS2_JTR_DL, &dl_triggers); + return __ocfs2_journal_access(handle, ci, bh, &dl_triggers, type); } _ Patches currently in -mm which might be from joseph.qi(a)linux.alibaba.com are ocfs2-fix-null-pointer-dereference-in-ocfs2_journal_dirty.patch ocfs2-fix-null-pointer-dereference-in-ocfs2_abort_trigger.patch

4 months, 2 weeks

1
0
0 0

+ ocfs2-fix-null-pointer-dereference-in-ocfs2_journal_dirty.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: ocfs2: fix NULL pointer dereference in ocfs2_journal_dirty() has been added to the -mm mm-hotfixes-unstable branch. Its filename is ocfs2-fix-null-pointer-dereference-in-ocfs2_journal_dirty.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Joseph Qi <joseph.qi(a)linux.alibaba.com> Subject: ocfs2: fix NULL pointer dereference in ocfs2_journal_dirty() Date: Thu, 30 May 2024 19:06:29 +0800 bdev->bd_super has been removed and commit 8887b94d9322 change the usage from bdev->bd_super to b_assoc_map->host->i_sb. This introduces the following NULL pointer dereference in ocfs2_journal_dirty() since b_assoc_map is still not initialized. This can be easily reproduced by running xfstests generic/186, which simulate no more credits. [ 134.351592] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 134.355341] RIP: 0010:ocfs2_journal_dirty+0x14f/0x160 [ocfs2] ... [ 134.365071] Call Trace: [ 134.365312] <TASK> [ 134.365524] ? __die_body+0x1e/0x60 [ 134.365868] ? page_fault_oops+0x13d/0x4f0 [ 134.366265] ? __pfx_bit_wait_io+0x10/0x10 [ 134.366659] ? schedule+0x27/0xb0 [ 134.366981] ? exc_page_fault+0x6a/0x140 [ 134.367356] ? asm_exc_page_fault+0x26/0x30 [ 134.367762] ? ocfs2_journal_dirty+0x14f/0x160 [ocfs2] [ 134.368305] ? ocfs2_journal_dirty+0x13d/0x160 [ocfs2] [ 134.368837] ocfs2_create_new_meta_bhs.isra.51+0x139/0x2e0 [ocfs2] [ 134.369454] ocfs2_grow_tree+0x688/0x8a0 [ocfs2] [ 134.369927] ocfs2_split_and_insert.isra.67+0x35c/0x4a0 [ocfs2] [ 134.370521] ocfs2_split_extent+0x314/0x4d0 [ocfs2] [ 134.371019] ocfs2_change_extent_flag+0x174/0x410 [ocfs2] [ 134.371566] ocfs2_add_refcount_flag+0x3fa/0x630 [ocfs2] [ 134.372117] ocfs2_reflink_remap_extent+0x21b/0x4c0 [ocfs2] [ 134.372994] ? inode_update_timestamps+0x4a/0x120 [ 134.373692] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2] [ 134.374545] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2] [ 134.375393] ocfs2_reflink_remap_blocks+0xe4/0x4e0 [ocfs2] [ 134.376197] ocfs2_remap_file_range+0x1de/0x390 [ocfs2] [ 134.376971] ? security_file_permission+0x29/0x50 [ 134.377644] vfs_clone_file_range+0xfe/0x320 [ 134.378268] ioctl_file_clone+0x45/0xa0 [ 134.378853] do_vfs_ioctl+0x457/0x990 [ 134.379422] __x64_sys_ioctl+0x6e/0xd0 [ 134.379987] do_syscall_64+0x5d/0x170 [ 134.380550] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 134.381231] RIP: 0033:0x7fa4926397cb [ 134.381786] Code: 73 01 c3 48 8b 0d bd 56 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8d 56 38 00 f7 d8 64 89 01 48 [ 134.383930] RSP: 002b:00007ffc2b39f7b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 134.384854] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fa4926397cb [ 134.385734] RDX: 00007ffc2b39f7f0 RSI: 000000004020940d RDI: 0000000000000003 [ 134.386606] RBP: 0000000000000000 R08: 00111a82a4f015bb R09: 00007fa494221000 [ 134.387476] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 134.388342] R13: 0000000000f10000 R14: 0000558e844e2ac8 R15: 0000000000f10000 [ 134.389207] </TASK> Fix it by only aborting transaction and journal in ocfs2_journal_dirty() now, and leave ocfs2_abort() later when detecting an aborted handle, e.g. start next transaction. Also log the handle details in this case. Link: https://lkml.kernel.org/r/20240530110630.3933832-1-joseph.qi@linux.alibaba.… Fixes: 8887b94d9322 ("ocfs2: stop using bdev->bd_super for journal error logging") Signed-off-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> [6.6+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/journal.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/fs/ocfs2/journal.c~ocfs2-fix-null-pointer-dereference-in-ocfs2_journal_dirty +++ a/fs/ocfs2/journal.c @@ -778,13 +778,15 @@ void ocfs2_journal_dirty(handle_t *handl if (!is_handle_aborted(handle)) { journal_t *journal = handle->h_transaction->t_journal; - mlog(ML_ERROR, "jbd2_journal_dirty_metadata failed. " - "Aborting transaction and journal.\n"); + mlog(ML_ERROR, "jbd2_journal_dirty_metadata failed: " + "handle type %u started at line %u, credits %u/%u " + "errcode %d. Aborting transaction and journal.\n", + handle->h_type, handle->h_line_no, + handle->h_requested_credits, + jbd2_handle_buffer_credits(handle), status); handle->h_err = status; jbd2_journal_abort_handle(handle); jbd2_journal_abort(journal, status); - ocfs2_abort(bh->b_assoc_map->host->i_sb, - "Journal already aborted.\n"); } } } _ Patches currently in -mm which might be from joseph.qi(a)linux.alibaba.com are ocfs2-fix-null-pointer-dereference-in-ocfs2_journal_dirty.patch ocfs2-fix-null-pointer-dereference-in-ocfs2_abort_trigger.patch

4 months, 2 weeks

1
0
0 0

AM5 big performance reduction with CSM boot mode and Wi-Fi disabled.

by Mohammad Hosain

Hello There is a big performance bug (only affecting games performance) on Linux (not reproducible on Windows) with AM5 boards (at least for my MSI MAG b650 Tomahawk) if these BIOS settings are used: CSM -> Enabled Wi-Fi -> Disabled (or set to Bluetooth only) This does not happen even on Win 7... (I've only tested DX12 games) and does not happen if UEFI mode is chosen. I've tested with many different BIOS versions all showing the same result. I have tried troubleshooting with MSI with some benchmarks posted (https://forum-en.msi.com/index.php?threads/b650-tomahawk-bios-bug-disabling…) and after a week we realized this only happens on Linux (tested on Arch/Fedora/Ubuntu with 6.8 and 6.9 kernels for the first two). Please investigate. Thank you

4 months, 2 weeks

2
3
0 0

+ nilfs2-fix-potential-kernel-bug-due-to-lack-of-writeback-flag-waiting.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: nilfs2: fix potential kernel bug due to lack of writeback flag waiting has been added to the -mm mm-hotfixes-unstable branch. Its filename is nilfs2-fix-potential-kernel-bug-due-to-lack-of-writeback-flag-waiting.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Subject: nilfs2: fix potential kernel bug due to lack of writeback flag waiting Date: Thu, 30 May 2024 23:15:56 +0900 Destructive writes to a block device on which nilfs2 is mounted can cause a kernel bug in the folio/page writeback start routine or writeback end routine (__folio_start_writeback in the log below): kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: <TASK> nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> This is because when the log writer starts a writeback for segment summary blocks or a super root block that use the backing device's page cache, it does not wait for the ongoing folio/page writeback, resulting in an inconsistent writeback state. Fix this issue by waiting for ongoing writebacks when putting folios/pages on the backing device into writeback state. Link: https://lkml.kernel.org/r/20240530141556.4411-1-konishi.ryusuke@gmail.com Fixes: 9ff05123e3bf ("nilfs2: segment constructor") Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/nilfs2/segment.c | 3 +++ 1 file changed, 3 insertions(+) --- a/fs/nilfs2/segment.c~nilfs2-fix-potential-kernel-bug-due-to-lack-of-writeback-flag-waiting +++ a/fs/nilfs2/segment.c @@ -1652,6 +1652,7 @@ static void nilfs_segctor_prepare_write( if (bh->b_folio != bd_folio) { if (bd_folio) { folio_lock(bd_folio); + folio_wait_writeback(bd_folio); folio_clear_dirty_for_io(bd_folio); folio_start_writeback(bd_folio); folio_unlock(bd_folio); @@ -1665,6 +1666,7 @@ static void nilfs_segctor_prepare_write( if (bh == segbuf->sb_super_root) { if (bh->b_folio != bd_folio) { folio_lock(bd_folio); + folio_wait_writeback(bd_folio); folio_clear_dirty_for_io(bd_folio); folio_start_writeback(bd_folio); folio_unlock(bd_folio); @@ -1681,6 +1683,7 @@ static void nilfs_segctor_prepare_write( } if (bd_folio) { folio_lock(bd_folio); + folio_wait_writeback(bd_folio); folio_clear_dirty_for_io(bd_folio); folio_start_writeback(bd_folio); folio_unlock(bd_folio); _ Patches currently in -mm which might be from konishi.ryusuke(a)gmail.com are nilfs2-fix-potential-kernel-bug-due-to-lack-of-writeback-flag-waiting.patch

4 months, 2 weeks

1
0
0 0

Re: [PATCH] afs: Don't cross .backup mountpoint from backup volume

by Jeffrey E Altman

On 5/24/2024 12:17 PM, David Howells wrote: > Hi Christian, > > Can you pick this up, please? > > Thanks, > David > --- > From: Marc Dionne<marc.dionne(a)auristor.com> > > afs: Don't cross .backup mountpoint from backup volume > > Don't cross a mountpoint that explicitly specifies a backup volume > (target is <vol>.backup) when starting from a backup volume. > > It it not uncommon to mount a volume's backup directly in the volume > itself. This can cause tools that are not paying attention to get > into a loop mounting the volume onto itself as they attempt to > traverse the tree, leading to a variety of problems. > > This doesn't prevent the general case of loops in a sequence of > mountpoints, but addresses a common special case in the same way > as other afs clients. > > Reported-by: Jan Henrik Sylvester<jan.henrik.sylvester(a)uni-hamburg.de> > Link:http://lists.infradead.org/pipermail/linux-afs/2024-May/008454.html > Reported-by: Markus Suvanto<markus.suvanto(a)gmail.com> > Link:http://lists.infradead.org/pipermail/linux-afs/2024-February/008074.ht… > Signed-off-by: Marc Dionne<marc.dionne(a)auristor.com> > Signed-off-by: David Howells<dhowells(a)redhat.com> > Reviewed-by: Jeffrey Altman<jaltman(a)auristor.com> > cc:linux-afs@lists.infradead.org > --- > fs/afs/mntpt.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/fs/afs/mntpt.c b/fs/afs/mntpt.c > index 97f50e9fd9eb..297487ee8323 100644 > --- a/fs/afs/mntpt.c > +++ b/fs/afs/mntpt.c > @@ -140,6 +140,11 @@ static int afs_mntpt_set_params(struct fs_context *fc, struct dentry *mntpt) > put_page(page); > if (ret < 0) > return ret; > + > + /* Don't cross a backup volume mountpoint from a backup volume */ > + if (src_as->volume && src_as->volume->type == AFSVL_BACKVOL && > + ctx->type == AFSVL_BACKVOL) > + return -ENODEV; > } > > return 0; Please add cc: stable(a)vger.kernel.org when it is applied to vfs-fixes. Thank you. Jeffrey Altman

4 months, 2 weeks

1
0
0 0

Re: [PATCH] afs: Don't cross .backup mountpoint from backup volume

by Jeffrey E Altman

On 5/24/2024 12:17 PM, David Howells wrote: > Hi Christian, > > Can you pick this up, please? > > Thanks, > David > --- > From: Marc Dionne<marc.dionne(a)auristor.com> > > afs: Don't cross .backup mountpoint from backup volume > > Don't cross a mountpoint that explicitly specifies a backup volume > (target is <vol>.backup) when starting from a backup volume. > > It it not uncommon to mount a volume's backup directly in the volume > itself. This can cause tools that are not paying attention to get > into a loop mounting the volume onto itself as they attempt to > traverse the tree, leading to a variety of problems. > > This doesn't prevent the general case of loops in a sequence of > mountpoints, but addresses a common special case in the same way > as other afs clients. > > Reported-by: Jan Henrik Sylvester<jan.henrik.sylvester(a)uni-hamburg.de> > Link:http://lists.infradead.org/pipermail/linux-afs/2024-May/008454.html > Reported-by: Markus Suvanto<markus.suvanto(a)gmail.com> > Link:http://lists.infradead.org/pipermail/linux-afs/2024-February/008074.ht… > Signed-off-by: Marc Dionne<marc.dionne(a)auristor.com> > Signed-off-by: David Howells<dhowells(a)redhat.com> > Reviewed-by: Jeffrey Altman<jaltman(a)auristor.com> > cc:linux-afs@lists.infradead.org > --- > fs/afs/mntpt.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/fs/afs/mntpt.c b/fs/afs/mntpt.c > index 97f50e9fd9eb..297487ee8323 100644 > --- a/fs/afs/mntpt.c > +++ b/fs/afs/mntpt.c > @@ -140,6 +140,11 @@ static int afs_mntpt_set_params(struct fs_context *fc, struct dentry *mntpt) > put_page(page); > if (ret < 0) > return ret; > + > + /* Don't cross a backup volume mountpoint from a backup volume */ > + if (src_as->volume && src_as->volume->type == AFSVL_BACKVOL && > + ctx->type == AFSVL_BACKVOL) > + return -ENODEV; > } > > return 0; Please add cc: stable(a)vger.kernel.org when it is applied to vfs-fixes. Thank you. Jeffrey Altman

4 months, 2 weeks

1
0
0 0

[tip: x86/urgent] x86/cpu: Provide default cache line size if not enumerated

by tip-bot2 for Dave Hansen

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 2a38e4ca302280fdcce370ba2bee79bac16c4587 Gitweb: https://git.kernel.org/tip/2a38e4ca302280fdcce370ba2bee79bac16c4587 Author: Dave Hansen <dave.hansen(a)linux.intel.com> AuthorDate: Fri, 17 May 2024 13:05:34 -07:00 Committer: Dave Hansen <dave.hansen(a)linux.intel.com> CommitterDate: Thu, 30 May 2024 08:29:45 -07:00 x86/cpu: Provide default cache line size if not enumerated tl;dr: CPUs with CPUID.80000008H but without CPUID.01H:EDX[CLFSH] will end up reporting cache_line_size()==0 and bad things happen. Fill in a default on those to avoid the problem. Long Story: The kernel dies a horrible death if c->x86_cache_alignment (aka. cache_line_size() is 0. Normally, this value is populated from c->x86_clflush_size. Right now the code is set up to get c->x86_clflush_size from two places. First, modern CPUs get it from CPUID. Old CPUs that don't have leaf 0x80000008 (or CPUID at all) just get some sane defaults from the kernel in get_cpu_address_sizes(). The vast majority of CPUs that have leaf 0x80000008 also get ->x86_clflush_size from CPUID. But there are oddballs. Intel Quark CPUs[1] and others[2] have leaf 0x80000008 but don't set CPUID.01H:EDX[CLFSH], so they skip over filling in ->x86_clflush_size: cpuid(0x00000001, &tfms, &misc, &junk, &cap0); if (cap0 & (1<<19)) c->x86_clflush_size = ((misc >> 8) & 0xff) * 8; So they: land in get_cpu_address_sizes() and see that CPUID has level 0x80000008 and jump into the side of the if() that does not fill in c->x86_clflush_size. That assigns a 0 to c->x86_cache_alignment, and hilarity ensues in code like: buffer = kzalloc(ALIGN(sizeof(*buffer), cache_line_size()), GFP_KERNEL); To fix this, always provide a sane value for ->x86_clflush_size. Big thanks to Andy Shevchenko for finding and reporting this and also providing a first pass at a fix. But his fix was only partial and only worked on the Quark CPUs. It would not, for instance, have worked on the QEMU config. 1. https://raw.githubusercontent.com/InstLatx64/InstLatx64/master/GenuineIntel… 2. You can also get this behavior if you use "-cpu 486,+clzero" in QEMU. [ dhansen: remove 'vp_bits_from_cpuid' reference in changelog because bpetkov brutally murdered it recently. ] Fixes: fbf6449f84bf ("x86/sev-es: Set x86_virt_bits to the correct value straight away, instead of a two-phase approach") Reported-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Tested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Tested-by: Jörn Heusipp <osmanx(a)heusipp.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20240516173928.3960193-1-andriy.shevchenko@linu… Link: https://lore.kernel.org/lkml/5e31cad3-ad4d-493e-ab07-724cfbfaba44@heusipp.d… Link: https://lore.kernel.org/all/20240517200534.8EC5F33E%40davehans-spike.ostc.i… --- arch/x86/kernel/cpu/common.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 2b170da..e31293c 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1075,6 +1075,10 @@ void get_cpu_address_sizes(struct cpuinfo_x86 *c) c->x86_virt_bits = (eax >> 8) & 0xff; c->x86_phys_bits = eax & 0xff; + + /* Provide a sane default if not enumerated: */ + if (!c->x86_clflush_size) + c->x86_clflush_size = 32; } c->x86_cache_bits = c->x86_phys_bits;

4 months, 2 weeks

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024