June 2024 - Linux-stable-mirror

[PATCH v2] PCI: use local_pci_probe when best selected cpu is offline

by Hongchen Zhang

When the best selected CPU is offline, work_on_cpu() will stuck forever. This can be happen if a node is online while all its CPUs are offline (we can use "maxcpus=1" without "nr_cpus=1" to reproduce it), Therefore, in this case, we should call local_pci_probe() instead of work_on_cpu(). Cc: <stable(a)vger.kernel.org> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> Signed-off-by: Hongchen Zhang <zhanghongchen(a)loongson.cn> --- v1 -> v2 Added the method to reproduce this issue --- drivers/pci/pci-driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index af2996d0d17f..32a99828e6a3 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -386,7 +386,7 @@ static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev, free_cpumask_var(wq_domain_mask); } - if (cpu < nr_cpu_ids) + if ((cpu < nr_cpu_ids) && cpu_online(cpu)) error = work_on_cpu(cpu, local_pci_probe, &ddi); else error = local_pci_probe(&ddi); -- 2.33.0

3 months, 3 weeks

1
0
0 0

New opportunity for your establishment

by Srisawad Corp. PCL

Attention, I am writing from Srisawad Corp. PCL. We would like to invest in your project, we have the capacity to fund your project and we are open to discuss on any of these three types of investment plans. We can invest either as a debt/loan finance, equity venture or a combination of debt/loan and equity venture, likewise known as convertible note depending on the investment plan most suitable for your project. We are majorly interested in projects with high profit value. Projects that fall within our interest can be funded completely with very considerable and workable terms. Should you be interested please get back to me through the below email for more information. Email: doungchai(a)sawadscorpsocl.com Kindly let us know what your ideas are. Doungchai Kaewbootta Executive Director/Managing Director Srisawad Corp. PCL 99/392 Srisawad Building, 4th, 6th floor, Soi Chaengwattana 10 Intersection 3 (Benjamitr) Chaengwattana Road, Thung Song Hong Subdistrict Lak Si District, Bangkok 10210

3 months, 3 weeks

1
0
0 0

[PATCH] PCI: use local_pci_probe when best selected cpu is offline

by Hongchen Zhang

When the best selected cpu is offline, work_on_cpu will stuck forever. Therefore, in this case, we should call local_pci_probe instead of work_on_cpu. Cc: <stable(a)vger.kernel.org> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> Signed-off-by: Hongchen Zhang <zhanghongchen(a)loongson.cn> --- drivers/pci/pci-driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index af2996d0d17f..32a99828e6a3 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -386,7 +386,7 @@ static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev, free_cpumask_var(wq_domain_mask); } - if (cpu < nr_cpu_ids) + if ((cpu < nr_cpu_ids) && cpu_online(cpu)) error = work_on_cpu(cpu, local_pci_probe, &ddi); else error = local_pci_probe(&ddi); -- 2.33.0

3 months, 3 weeks

2
2
0 0

[PATCH v4 7/9] 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 660599823050..322b8ff67cde 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c @@ -682,12 +682,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, @@ -701,43 +706,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

3 months, 3 weeks

1
0
0 0

[PATCH v2] KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()

by Breno Leitao

Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000 Fixes: 217ece6129f2 ("KVM: use yield_to instead of sleep in kvm_vcpu_on_spin") Cc: stable(a)vger.kernel.org Signed-off-by: Breno Leitao <leitao(a)debian.org> --- Changelog: v2: * Reworded the git commit as suggested by Sean * Dropped the me->kvm->last_boosted_vcpu in favor of kvm->last_boosted_vcpu as suggested by Sean v1: * https://lore.kernel.org/all/20240509090146.146153-1-leitao@debian.org/ --- virt/kvm/kvm_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index ff0a20565f90..d9ce063c76f9 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -4066,12 +4066,13 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) { struct kvm *kvm = me->kvm; struct kvm_vcpu *vcpu; - int last_boosted_vcpu = me->kvm->last_boosted_vcpu; + int last_boosted_vcpu; unsigned long i; int yielded = 0; int try = 3; int pass; + last_boosted_vcpu = READ_ONCE(kvm->last_boosted_vcpu); kvm_vcpu_set_in_spin_loop(me, true); /* * We boost the priority of a VCPU that is runnable but not @@ -4109,7 +4110,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode) yielded = kvm_vcpu_yield_to(vcpu); if (yielded > 0) { - kvm->last_boosted_vcpu = i; + WRITE_ONCE(kvm->last_boosted_vcpu, i); break; } else if (yielded < 0) { try--; -- 2.43.0

3 months, 3 weeks

2
1
0 0

+ nilfs2-fix-nilfs_empty_dir-misjudgment-and-long-loop-on-i-o-errors.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors has been added to the -mm mm-hotfixes-unstable branch. Its filename is nilfs2-fix-nilfs_empty_dir-misjudgment-and-long-loop-on-i-o-errors.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 nilfs_empty_dir() misjudgment and long loop on I/O errors Date: Tue, 4 Jun 2024 22:42:55 +0900 The error handling in nilfs_empty_dir() when a directory folio/page read fails is incorrect, as in the old ext2 implementation, and if the folio/page cannot be read or nilfs_check_folio() fails, it will falsely determine the directory as empty and corrupt the file system. In addition, since nilfs_empty_dir() does not immediately return on a failed folio/page read, but continues to loop, this can cause a long loop with I/O if i_size of the directory's inode is also corrupted, causing the log writer thread to wait and hang, as reported by syzbot. Fix these issues by making nilfs_empty_dir() immediately return a false value (0) if it fails to get a directory folio/page. Link: https://lkml.kernel.org/r/20240604134255.7165-1-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Reported-by: syzbot+c8166c541d3971bf6c87(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c8166c541d3971bf6c87 Fixes: 2ba466d74ed7 ("nilfs2: directory entry operations") 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/dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/nilfs2/dir.c~nilfs2-fix-nilfs_empty_dir-misjudgment-and-long-loop-on-i-o-errors +++ a/fs/nilfs2/dir.c @@ -607,7 +607,7 @@ int nilfs_empty_dir(struct inode *inode) kaddr = nilfs_get_folio(inode, i, &folio); if (IS_ERR(kaddr)) - continue; + return 0; de = (struct nilfs_dir_entry *)kaddr; kaddr += nilfs_last_byte(inode, i) - NILFS_DIR_REC_LEN(1); _ 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 nilfs2-fix-nilfs_empty_dir-misjudgment-and-long-loop-on-i-o-errors.patch

3 months, 3 weeks

1
0
0 0

Please queue up f4dca95fc0f6 for 6.9 et.al.

by Holger Hoffstätte

Just ${Subject} since it's a fix for a potential security footgun/DOS, whereever commit 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") has been queued up. Thanks! Holger

3 months, 3 weeks

3
6
0 0

[PATCH] crypto: ccp - Fix null pointer dereference in __sev_snp_shutdown_locked

by Kim Phillips

Another DEBUG_TEST_DRIVER_REMOVE induced splat found, this time in __sev_snp_shutdown_locked(). [ 38.625613] ccp 0000:55:00.5: enabling device (0000 -> 0002) [ 38.633022] ccp 0000:55:00.5: sev enabled [ 38.637498] ccp 0000:55:00.5: psp enabled [ 38.642011] BUG: kernel NULL pointer dereference, address: 00000000000000f0 [ 38.645963] #PF: supervisor read access in kernel mode [ 38.645963] #PF: error_code(0x0000) - not-present page [ 38.645963] PGD 0 P4D 0 [ 38.645963] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI [ 38.645963] CPU: 262 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1+ #29 [ 38.645963] RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150 [ 38.645963] Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 <4c> 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83 [ 38.645963] RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286 [ 38.645963] RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000 [ 38.645963] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2ea4014b808 [ 38.645963] RBP: ffffb2ea4014b7e8 R08: 0000000000000106 R09: 000000000003d9c0 [ 38.645963] R10: 0000000000000001 R11: ffffffffa39ff070 R12: ffff9e49d40590c8 [ 38.645963] R13: 0000000000000000 R14: ffffb2ea4014b808 R15: 0000000000000000 [ 38.645963] FS: 0000000000000000(0000) GS:ffff9e58b1e00000(0000) knlGS:0000000000000000 [ 38.645963] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 38.645963] CR2: 00000000000000f0 CR3: 0000000418a3e001 CR4: 0000000000770ef0 [ 38.645963] PKRU: 55555554 [ 38.645963] Call Trace: [ 38.645963] <TASK> [ 38.645963] ? __die_body+0x6f/0xb0 [ 38.645963] ? __die+0xcc/0xf0 [ 38.645963] ? page_fault_oops+0x330/0x3a0 [ 38.645963] ? save_trace+0x2a5/0x360 [ 38.645963] ? do_user_addr_fault+0x583/0x630 [ 38.645963] ? exc_page_fault+0x81/0x120 [ 38.645963] ? asm_exc_page_fault+0x2b/0x30 [ 38.645963] ? __sev_snp_shutdown_locked+0x2e/0x150 [ 38.645963] __sev_firmware_shutdown+0x349/0x5b0 [ 38.645963] ? pm_runtime_barrier+0x66/0xe0 [ 38.645963] sev_dev_destroy+0x34/0xb0 [ 38.645963] psp_dev_destroy+0x27/0x60 [ 38.645963] sp_destroy+0x39/0x90 [ 38.645963] sp_pci_remove+0x22/0x60 [ 38.645963] pci_device_remove+0x4e/0x110 [ 38.645963] really_probe+0x271/0x4e0 [ 38.645963] __driver_probe_device+0x8f/0x160 [ 38.645963] driver_probe_device+0x24/0x120 [ 38.645963] __driver_attach+0xc7/0x280 [ 38.645963] ? driver_attach+0x30/0x30 [ 38.645963] bus_for_each_dev+0x10d/0x130 [ 38.645963] driver_attach+0x22/0x30 [ 38.645963] bus_add_driver+0x171/0x2b0 [ 38.645963] ? unaccepted_memory_init_kdump+0x20/0x20 [ 38.645963] driver_register+0x67/0x100 [ 38.645963] __pci_register_driver+0x83/0x90 [ 38.645963] sp_pci_init+0x22/0x30 [ 38.645963] sp_mod_init+0x13/0x30 [ 38.645963] do_one_initcall+0xb8/0x290 [ 38.645963] ? sched_clock_noinstr+0xd/0x10 [ 38.645963] ? local_clock_noinstr+0x3e/0x100 [ 38.645963] ? stack_depot_save_flags+0x21e/0x6a0 [ 38.645963] ? local_clock+0x1c/0x60 [ 38.645963] ? stack_depot_save_flags+0x21e/0x6a0 [ 38.645963] ? sched_clock_noinstr+0xd/0x10 [ 38.645963] ? local_clock_noinstr+0x3e/0x100 [ 38.645963] ? __lock_acquire+0xd90/0xe30 [ 38.645963] ? sched_clock_noinstr+0xd/0x10 [ 38.645963] ? local_clock_noinstr+0x3e/0x100 [ 38.645963] ? __create_object+0x66/0x100 [ 38.645963] ? local_clock+0x1c/0x60 [ 38.645963] ? __create_object+0x66/0x100 [ 38.645963] ? parameq+0x1b/0x90 [ 38.645963] ? parse_one+0x6d/0x1d0 [ 38.645963] ? parse_args+0xd7/0x1f0 [ 38.645963] ? do_initcall_level+0x180/0x180 [ 38.645963] do_initcall_level+0xb0/0x180 [ 38.645963] do_initcalls+0x60/0xa0 [ 38.645963] ? kernel_init+0x1f/0x1d0 [ 38.645963] do_basic_setup+0x41/0x50 [ 38.645963] kernel_init_freeable+0x1ac/0x230 [ 38.645963] ? rest_init+0x1f0/0x1f0 [ 38.645963] kernel_init+0x1f/0x1d0 [ 38.645963] ? rest_init+0x1f0/0x1f0 [ 38.645963] ret_from_fork+0x3d/0x50 [ 38.645963] ? rest_init+0x1f0/0x1f0 [ 38.645963] ret_from_fork_asm+0x11/0x20 [ 38.645963] </TASK> [ 38.645963] Modules linked in: [ 38.645963] CR2: 00000000000000f0 [ 38.645963] ---[ end trace 0000000000000000 ]--- [ 38.645963] RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150 [ 38.645963] Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 <4c> 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83 [ 38.645963] RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286 [ 38.645963] RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000 [ 38.645963] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2ea4014b808 [ 38.645963] RBP: ffffb2ea4014b7e8 R08: 0000000000000106 R09: 000000000003d9c0 [ 38.645963] R10: 0000000000000001 R11: ffffffffa39ff070 R12: ffff9e49d40590c8 [ 38.645963] R13: 0000000000000000 R14: ffffb2ea4014b808 R15: 0000000000000000 [ 38.645963] FS: 0000000000000000(0000) GS:ffff9e58b1e00000(0000) knlGS:0000000000000000 [ 38.645963] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 38.645963] CR2: 00000000000000f0 CR3: 0000000418a3e001 CR4: 0000000000770ef0 [ 38.645963] PKRU: 55555554 [ 38.645963] Kernel panic - not syncing: Fatal exception [ 38.645963] Kernel Offset: 0x1fc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Fixes: ccb88e9549e7 ("crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked") Cc: stable(a)vger.kernel.org Signed-off-by: Kim Phillips <kim.phillips(a)amd.com> --- drivers/crypto/ccp/sev-dev.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index 2102377f727b..1912bee22dd4 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -1642,10 +1642,16 @@ static int sev_update_firmware(struct device *dev) static int __sev_snp_shutdown_locked(int *error, bool panic) { - struct sev_device *sev = psp_master->sev_data; + struct psp_device *psp = psp_master; + struct sev_device *sev; struct sev_data_snp_shutdown_ex data; int ret; + if (!psp || !psp->sev_data) + return 0; + + sev = psp->sev_data; + if (!sev->snp_initialized) return 0; -- 2.34.1

3 months, 3 weeks

5
4
0 0

[PATCH v7 00/10] Fix Kselftest's vfork() side effects

by Mickaël Salaün

Hi, This seven series fix an issue reported by kernel test robot [3]. Shuah, I (as well as Kees and Sean [4]) think this should be in -next really soon to make sure everything works fine for the v6.9 release, which is not currently the case. I cannot test against all kselftests though. I would prefer to let you handle this, but I guess you're not able to do so and I'll push it on my branch without reply from you. Even if I push it on my branch, please push it on yours too as soon as you see this and I'll remove it from mine. Mark, Jakub, could you please test this series? As reported by Kernel Test Robot [1] and Sean Christopherson [2], some tests fail since v6.9-rc1 . This is due to the use of vfork() which introduced some side effects. Similarly, while making it more generic, a previous commit made some Landlock file system tests flaky, and subject to the host's file system mount configuration. This series fixes all these side effects by replacing vfork() with clone3() and CLONE_VFORK, which is cleaner (no arbitrary shared memory) and makes the Kselftest framework more robust. I tried different approaches and I found this one to be the cleaner and less invasive for current test cases. I successfully ran the following tests (using TEST_F and fork/clone/clone3, and KVM_ONE_VCPU_TEST) with this series: - kvm:fix_hypercall_test - kvm:sync_regs_test - kvm:userspace_msr_exit_test - kvm:vmx_pmu_caps_test - landlock:fs_test - landlock:net_test - landlock:ptrace_test - move_mount_set_group:move_mount_set_group_test - net/af_unix:scm_pidfd - perf_events:remove_on_exec - pidfd:pidfd_getfd_test - pidfd:pidfd_setns_test - seccomp:seccomp_bpf - user_events:abi_test [1] https://lore.kernel.org/oe-lkp/202403291015.1fcfa957-oliver.sang@intel.com [2] https://lore.kernel.org/r/ZjPelW6-AbtYvslu@google.com [3] https://lore.kernel.org/r/202405100339.vfBe0t9C-lkp@intel.com [4] https://lore.kernel.org/r/202405061002.01D399877A@keescook Previous versions: v1: https://lore.kernel.org/r/20240426172252.1862930-1-mic@digikod.net v2: https://lore.kernel.org/r/20240429130931.2394118-1-mic@digikod.net v3: https://lore.kernel.org/r/20240429191911.2552580-1-mic@digikod.net v4: https://lore.kernel.org/r/20240502210926.145539-1-mic@digikod.net v5: https://lore.kernel.org/r/20240503105820.300927-1-mic@digikod.net v6: https://lore.kernel.org/r/20240506165518.474504-1-mic@digikod.net Regards, Mickaël Salaün (10): selftests/pidfd: Fix config for pidfd_setns_test selftests/landlock: Fix FS tests when run on a private mount point selftests/harness: Fix fixture teardown selftests/harness: Fix interleaved scheduling leading to race conditions selftests/landlock: Do not allocate memory in fixture data selftests/harness: Constify fixture variants selftests/pidfd: Fix wrong expectation selftests/harness: Share _metadata between forked processes selftests/harness: Fix vfork() side effects selftests/harness: Handle TEST_F()'s explicit exit codes tools/testing/selftests/kselftest_harness.h | 127 +++++++++++++----- tools/testing/selftests/landlock/fs_test.c | 83 +++++++----- tools/testing/selftests/pidfd/config | 2 + .../selftests/pidfd/pidfd_setns_test.c | 2 +- 4 files changed, 147 insertions(+), 67 deletions(-) base-commit: e67572cd2204894179d89bd7b984072f19313b03 -- 2.45.0

3 months, 3 weeks

3
16
0 0

[PATCH 0/2] arm64: dts: qcom: switch RB1 and RB2 platforms to i2c2-gpio

by Dmitry Baryshkov

On the Qualcomm RB1 and RB2 platforms the I2C bus connected to the LT9611UXC bridge under some circumstances can go into a state when all transfers timeout. This causes both issues with fetching of EDID and with updating of the bridge's firmware. While we are debugging the issue, switch corresponding I2C bus to use i2c-gpio driver. While using i2c-gpio no communication issues are observed. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- Dmitry Baryshkov (2): arm64: dts: qcom: qrb2210-rb1: switch I2C2 to i2c-gpio arm64: dts: qcom: qrb4210-rb2: switch I2C2 to i2c-gpio arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 13 ++++++++++++- arch/arm64/boot/dts/qcom/qrb4210-rb2.dts | 13 ++++++++++++- 2 files changed, 24 insertions(+), 2 deletions(-) --- base-commit: 0e1980c40b6edfa68b6acf926bab22448a6e40c9 change-id: 20240604-rb12-i2c2g-pio-f6035fa8e022 Best regards, -- Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>

3 months, 3 weeks

2
3
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024