May 2024 - Linux-stable-mirror

Re: Patch "arm64: fpsimd: Drop unneeded 'busy' flag" has been added to the 6.6-stable tree

by Ard Biesheuvel

On Thu, 30 May 2024 at 21:11, Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > arm64: fpsimd: Drop unneeded 'busy' flag > > to the 6.6-stable tree Why? > which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > arm64-fpsimd-drop-unneeded-busy-flag.patch > and it can be found in the queue-6.6 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 37f2773a1ef05374538d5e4ed26cbacebe363241 > Author: Ard Biesheuvel <ardb(a)kernel.org> > Date: Fri Dec 8 12:32:20 2023 +0100 > > arm64: fpsimd: Drop unneeded 'busy' flag > > [ Upstream commit 9b19700e623f96222c69ecb2adecb1a3e3664cc0 ] > > Kernel mode NEON will preserve the user mode FPSIMD state by saving it > into the task struct before clobbering the registers. In order to avoid > the need for preserving kernel mode state too, we disallow nested use of > kernel mode NEON, i..e, use in softirq context while the interrupted > task context was using kernel mode NEON too. > > Originally, this policy was implemented using a per-CPU flag which was > exposed via may_use_simd(), requiring the users of the kernel mode NEON > to deal with the possibility that it might return false, and having NEON > and non-NEON code paths. This policy was changed by commit > 13150149aa6ded1 ("arm64: fpsimd: run kernel mode NEON with softirqs > disabled"), and now, softirq processing is disabled entirely instead, > and so may_use_simd() can never fail when called from task or softirq > context. > > This means we can drop the fpsimd_context_busy flag entirely, and > instead, ensure that we disable softirq processing in places where we > formerly relied on the flag for preventing races in the FPSIMD preserve > routines. > > Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> > Reviewed-by: Mark Brown <broonie(a)kernel.org> > Tested-by: Geert Uytterhoeven <geert+renesas(a)glider.be> > Link: https://lore.kernel.org/r/20231208113218.3001940-7-ardb@google.com > [will: Folded in fix from CAMj1kXFhzbJRyWHELCivQW1yJaF=p07LLtbuyXYX3G1WtsdyQg(a)mail.gmail.com] > Signed-off-by: Will Deacon <will(a)kernel.org> > Stable-dep-of: b8995a184170 ("Revert "arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD"") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/arch/arm64/include/asm/simd.h b/arch/arm64/include/asm/simd.h > index 6a75d7ecdcaa2..8e86c9e70e483 100644 > --- a/arch/arm64/include/asm/simd.h > +++ b/arch/arm64/include/asm/simd.h > @@ -12,8 +12,6 @@ > #include <linux/preempt.h> > #include <linux/types.h> > > -DECLARE_PER_CPU(bool, fpsimd_context_busy); > - > #ifdef CONFIG_KERNEL_MODE_NEON > > /* > @@ -28,17 +26,10 @@ static __must_check inline bool may_use_simd(void) > /* > * We must make sure that the SVE has been initialized properly > * before using the SIMD in kernel. > - * fpsimd_context_busy is only set while preemption is disabled, > - * and is clear whenever preemption is enabled. Since > - * this_cpu_read() is atomic w.r.t. preemption, fpsimd_context_busy > - * cannot change under our feet -- if it's set we cannot be > - * migrated, and if it's clear we cannot be migrated to a CPU > - * where it is set. > */ > return !WARN_ON(!system_capabilities_finalized()) && > system_supports_fpsimd() && > - !in_hardirq() && !irqs_disabled() && !in_nmi() && > - !this_cpu_read(fpsimd_context_busy); > + !in_hardirq() && !irqs_disabled() && !in_nmi(); > } > > #else /* ! CONFIG_KERNEL_MODE_NEON */ > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > index 5cdfcc9e3e54b..b805bdab284c4 100644 > --- a/arch/arm64/kernel/fpsimd.c > +++ b/arch/arm64/kernel/fpsimd.c > @@ -85,13 +85,13 @@ > * softirq kicks in. Upon vcpu_put(), KVM will save the vcpu FP state and > * flag the register state as invalid. > * > - * In order to allow softirq handlers to use FPSIMD, kernel_neon_begin() may > - * save the task's FPSIMD context back to task_struct from softirq context. > - * To prevent this from racing with the manipulation of the task's FPSIMD state > - * from task context and thereby corrupting the state, it is necessary to > - * protect any manipulation of a task's fpsimd_state or TIF_FOREIGN_FPSTATE > - * flag with {, __}get_cpu_fpsimd_context(). This will still allow softirqs to > - * run but prevent them to use FPSIMD. > + * In order to allow softirq handlers to use FPSIMD, kernel_neon_begin() may be > + * called from softirq context, which will save the task's FPSIMD context back > + * to task_struct. To prevent this from racing with the manipulation of the > + * task's FPSIMD state from task context and thereby corrupting the state, it > + * is necessary to protect any manipulation of a task's fpsimd_state or > + * TIF_FOREIGN_FPSTATE flag with get_cpu_fpsimd_context(), which will suspend > + * softirq servicing entirely until put_cpu_fpsimd_context() is called. > * > * For a certain task, the sequence may look something like this: > * - the task gets scheduled in; if both the task's fpsimd_cpu field > @@ -209,27 +209,14 @@ static inline void sme_free(struct task_struct *t) { } > > #endif > > -DEFINE_PER_CPU(bool, fpsimd_context_busy); > -EXPORT_PER_CPU_SYMBOL(fpsimd_context_busy); > - > static void fpsimd_bind_task_to_cpu(void); > > -static void __get_cpu_fpsimd_context(void) > -{ > - bool busy = __this_cpu_xchg(fpsimd_context_busy, true); > - > - WARN_ON(busy); > -} > - > /* > * Claim ownership of the CPU FPSIMD context for use by the calling context. > * > * The caller may freely manipulate the FPSIMD context metadata until > * put_cpu_fpsimd_context() is called. > * > - * The double-underscore version must only be called if you know the task > - * can't be preempted. > - * > * On RT kernels local_bh_disable() is not sufficient because it only > * serializes soft interrupt related sections via a local lock, but stays > * preemptible. Disabling preemption is the right choice here as bottom > @@ -242,14 +229,6 @@ static void get_cpu_fpsimd_context(void) > local_bh_disable(); > else > preempt_disable(); > - __get_cpu_fpsimd_context(); > -} > - > -static void __put_cpu_fpsimd_context(void) > -{ > - bool busy = __this_cpu_xchg(fpsimd_context_busy, false); > - > - WARN_ON(!busy); /* No matching get_cpu_fpsimd_context()? */ > } > > /* > @@ -261,18 +240,12 @@ static void __put_cpu_fpsimd_context(void) > */ > static void put_cpu_fpsimd_context(void) > { > - __put_cpu_fpsimd_context(); > if (!IS_ENABLED(CONFIG_PREEMPT_RT)) > local_bh_enable(); > else > preempt_enable(); > } > > -static bool have_cpu_fpsimd_context(void) > -{ > - return !preemptible() && __this_cpu_read(fpsimd_context_busy); > -} > - > unsigned int task_get_vl(const struct task_struct *task, enum vec_type type) > { > return task->thread.vl[type]; > @@ -383,7 +356,7 @@ static void task_fpsimd_load(void) > bool restore_ffr; > > WARN_ON(!system_supports_fpsimd()); > - WARN_ON(!have_cpu_fpsimd_context()); > + WARN_ON(preemptible()); > > if (system_supports_sve() || system_supports_sme()) { > switch (current->thread.fp_type) { > @@ -467,7 +440,7 @@ static void fpsimd_save(void) > unsigned int vl; > > WARN_ON(!system_supports_fpsimd()); > - WARN_ON(!have_cpu_fpsimd_context()); > + WARN_ON(preemptible()); > > if (test_thread_flag(TIF_FOREIGN_FPSTATE)) > return; > @@ -1583,7 +1556,7 @@ void fpsimd_thread_switch(struct task_struct *next) > if (!system_supports_fpsimd()) > return; > > - __get_cpu_fpsimd_context(); > + WARN_ON_ONCE(!irqs_disabled()); > > /* Save unsaved fpsimd state, if any: */ > fpsimd_save(); > @@ -1599,8 +1572,6 @@ void fpsimd_thread_switch(struct task_struct *next) > > update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE, > wrong_task || wrong_cpu); > - > - __put_cpu_fpsimd_context(); > } > > static void fpsimd_flush_thread_vl(enum vec_type type) > @@ -1892,13 +1863,15 @@ static void fpsimd_flush_cpu_state(void) > */ > void fpsimd_save_and_flush_cpu_state(void) > { > + unsigned long flags; > + > if (!system_supports_fpsimd()) > return; > WARN_ON(preemptible()); > - __get_cpu_fpsimd_context(); > + local_irq_save(flags); > fpsimd_save(); > fpsimd_flush_cpu_state(); > - __put_cpu_fpsimd_context(); > + local_irq_restore(flags); > } > > #ifdef CONFIG_KERNEL_MODE_NEON

1 year, 1 month

2
3
0 0

[PATCH 6.8.y-and-older] ALSA: timer: Set lower bound of start tick time

by Takashi Iwai

commit 4a63bd179fa8d3fcc44a0d9d71d941ddd62f0c4e upstream. Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer. This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow. [ backport note: the error handling is changed, as the original commit is based on the recent cleanup with guard() in commit beb45974dd49 -- tiwai ] Reported-by: syzbot+43120c2af6ca2938cc38(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/000000000000fa00a1061740ab6d@google.com Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20240514182745.4015-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- Greg, this is an alternative fix to the original cherry-pick; apply to 6.8.y and older stable kernels. Thanks! sound/core/timer.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sound/core/timer.c b/sound/core/timer.c index e6e551d4a29e..a0b515981ee9 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -553,6 +553,16 @@ static int snd_timer_start1(struct snd_timer_instance *timeri, goto unlock; } + /* check the actual time for the start tick; + * bail out as error if it's way too low (< 100us) + */ + if (start) { + if ((u64)snd_timer_hw_resolution(timer) * ticks < 100000) { + result = -EINVAL; + goto unlock; + } + } + if (start) timeri->ticks = timeri->cticks = ticks; else if (!timeri->cticks) -- 2.43.0

1 year, 1 month

2
1
0 0

[PATCH v4] perf/core: Fix missing wakeup when waiting for context reference

by Haifeng Xu

In our production environment, we found many hung tasks which are blocked for more than 18 hours. Their call traces are like this: [346278.191038] __schedule+0x2d8/0x890 [346278.191046] schedule+0x4e/0xb0 [346278.191049] perf_event_free_task+0x220/0x270 [346278.191056] ? init_wait_var_entry+0x50/0x50 [346278.191060] copy_process+0x663/0x18d0 [346278.191068] kernel_clone+0x9d/0x3d0 [346278.191072] __do_sys_clone+0x5d/0x80 [346278.191076] __x64_sys_clone+0x25/0x30 [346278.191079] do_syscall_64+0x5c/0xc0 [346278.191083] ? syscall_exit_to_user_mode+0x27/0x50 [346278.191086] ? do_syscall_64+0x69/0xc0 [346278.191088] ? irqentry_exit_to_user_mode+0x9/0x20 [346278.191092] ? irqentry_exit+0x19/0x30 [346278.191095] ? exc_page_fault+0x89/0x160 [346278.191097] ? asm_exc_page_fault+0x8/0x30 [346278.191102] entry_SYSCALL_64_after_hwframe+0x44/0xae The task was waiting for the refcount become to 1, but from the vmcore, we found the refcount has already been 1. It seems that the task didn't get woken up by perf_event_release_kernel() and got stuck forever. The below scenario may cause the problem. Thread A Thread B ... ... perf_event_free_task perf_event_release_kernel ... acquire event->child_mutex ... get_ctx ... release event->child_mutex acquire ctx->mutex ... perf_free_event (acquire/release event->child_mutex) ... release ctx->mutex wait_var_event acquire ctx->mutex acquire event->child_mutex # move existing events to free_list release event->child_mutex release ctx->mutex put_ctx ... ... In this case, all events of the ctx have been freed, so we couldn't find the ctx in free_list and Thread A will miss the wakeup. It's thus necessary to add a wakeup after dropping the reference. Fixes: 1cf8dfe8a661 ("perf/core: Fix race between close() and fork()") Cc: stable(a)vger.kernel.org Signed-off-by: Haifeng Xu <haifeng.xu(a)shopee.com> Reviewed-by: Frederic Weisbecker <frederic(a)kernel.org> Acked-by: Mark Rutland <mark.rutland(a)arm.com> --- Changes since v1: - Add the fixed tag. - Simplify v1's patch. (Frederic) Changes since v2: - Use Reviewed-by tag instead of Signed-off-by tag. Changes since v3: - Add Acked-by tag. - Cc stable(a)vger.kernel.org. (Mark) --- kernel/events/core.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/kernel/events/core.c b/kernel/events/core.c index 4f0c45ab8d7d..15c35070db6a 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -5340,6 +5340,7 @@ int perf_event_release_kernel(struct perf_event *event) again: mutex_lock(&event->child_mutex); list_for_each_entry(child, &event->child_list, child_list) { + void *var = NULL; /* * Cannot change, child events are not migrated, see the @@ -5380,11 +5381,23 @@ int perf_event_release_kernel(struct perf_event *event) * this can't be the last reference. */ put_event(event); + } else { + var = &ctx->refcount; } mutex_unlock(&event->child_mutex); mutex_unlock(&ctx->mutex); put_ctx(ctx); + + if (var) { + /* + * If perf_event_free_task() has deleted all events from the + * ctx while the child_mutex got released above, make sure to + * notify about the preceding put_ctx(). + */ + smp_mb(); /* pairs with wait_var_event() */ + wake_up_var(var); + } goto again; } mutex_unlock(&event->child_mutex); -- 2.25.1

1 year, 1 month

4
3
0 0

[PATCH] locking/atomic: fix trivial typo in comment

by Carlos Llamas

For atomic_sub_and_test() the @i parameter is the value to subtract, not add. Fix the kerneldoc comment accordingly. Fixes: ad8110706f38 ("locking/atomic: scripts: generate kerneldoc comments") Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: stable(a)vger.kernel.org Signed-off-by: Carlos Llamas <cmllamas(a)google.com> --- include/linux/atomic/atomic-instrumented.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/atomic/atomic-instrumented.h b/include/linux/atomic/atomic-instrumented.h index debd487fe971..12b558c05384 100644 --- a/include/linux/atomic/atomic-instrumented.h +++ b/include/linux/atomic/atomic-instrumented.h @@ -1349,7 +1349,7 @@ atomic_try_cmpxchg_relaxed(atomic_t *v, int *old, int new) /** * atomic_sub_and_test() - atomic subtract and test if zero with full ordering - * @i: int value to add + * @i: int value to subtract * @v: pointer to atomic_t * * Atomically updates @v to (@v - @i) with full ordering. -- 2.45.0.rc1.225.g2a3ae87e7f-goog

1 year, 1 month

6
10
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

1 year, 1 month

2
2
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

1 year, 1 month

2
1
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

1 year, 1 month

3
16
0 0

[PATCH 1/2] mmc: sdhci-pci: Convert PCIBIOS_* return codes to errnos

by Ilpo Järvinen

jmicron_pmos() and sdhci_pci_probe() use pci_{read,write}_config_byte() that return PCIBIOS_* codes. The return code is then returned as is by jmicron_probe() and sdhci_pci_probe(). Similarly, the return code is also returned as is from jmicron_resume(). Both probe and resume functions should return normal errnos. Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning them the fix these issues. Fixes: 7582041ff3d4 ("mmc: sdhci-pci: fix simple_return.cocci warnings") Fixes: 45211e215984 ("sdhci: toggle JMicron PMOS setting") Cc: stable(a)vger.kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> --- drivers/mmc/host/sdhci-pci-core.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c index ef89ec382bfe..23e6ba70144c 100644 --- a/drivers/mmc/host/sdhci-pci-core.c +++ b/drivers/mmc/host/sdhci-pci-core.c @@ -1326,7 +1326,7 @@ static int jmicron_pmos(struct sdhci_pci_chip *chip, int on) ret = pci_read_config_byte(chip->pdev, 0xAE, &scratch); if (ret) - return ret; + goto fail; /* * Turn PMOS on [bit 0], set over current detection to 2.4 V @@ -1337,7 +1337,10 @@ static int jmicron_pmos(struct sdhci_pci_chip *chip, int on) else scratch &= ~0x47; - return pci_write_config_byte(chip->pdev, 0xAE, scratch); + ret = pci_write_config_byte(chip->pdev, 0xAE, scratch); + +fail: + return pcibios_err_to_errno(ret); } static int jmicron_probe(struct sdhci_pci_chip *chip) @@ -2202,7 +2205,7 @@ static int sdhci_pci_probe(struct pci_dev *pdev, ret = pci_read_config_byte(pdev, PCI_SLOT_INFO, &slots); if (ret) - return ret; + return pcibios_err_to_errno(ret); slots = PCI_SLOT_INFO_SLOTS(slots) + 1; dev_dbg(&pdev->dev, "found %d slot(s)\n", slots); @@ -2211,7 +2214,7 @@ static int sdhci_pci_probe(struct pci_dev *pdev, ret = pci_read_config_byte(pdev, PCI_SLOT_INFO, &first_bar); if (ret) - return ret; + return pcibios_err_to_errno(ret); first_bar &= PCI_SLOT_INFO_FIRST_BAR_MASK; -- 2.39.2

1 year, 1 month

3
5
0 0

[PATCH 1/2] EDAC/amd64: Convert PCIBIOS_* return codes to errnos

by Ilpo Järvinen

gpu_get_node_map() uses pci_read_config_dword() that returns PCIBIOS_* codes. The return code is then returned all the way into the module init function amd64_edac_init() that returns it as is. The module init functions, however, should return normal errnos. Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it from gpu_get_node_map(). For consistency, convert also the other similar cases which return PCIBIOS_* codes even if they do not have any bugs at the moment. Fixes: 4251566ebc1c ("EDAC/amd64: Cache and use GPU node map") Cc: stable(a)vger.kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> --- drivers/edac/amd64_edac.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c index 1f3520d76861..a17f3c0cdfa6 100644 --- a/drivers/edac/amd64_edac.c +++ b/drivers/edac/amd64_edac.c @@ -81,7 +81,7 @@ int __amd64_read_pci_cfg_dword(struct pci_dev *pdev, int offset, amd64_warn("%s: error reading F%dx%03x.\n", func, PCI_FUNC(pdev->devfn), offset); - return err; + return pcibios_err_to_errno(err); } int __amd64_write_pci_cfg_dword(struct pci_dev *pdev, int offset, @@ -94,7 +94,7 @@ int __amd64_write_pci_cfg_dword(struct pci_dev *pdev, int offset, amd64_warn("%s: error writing to F%dx%03x.\n", func, PCI_FUNC(pdev->devfn), offset); - return err; + return pcibios_err_to_errno(err); } /* @@ -1025,8 +1025,10 @@ static int gpu_get_node_map(struct amd64_pvt *pvt) } ret = pci_read_config_dword(pdev, REG_LOCAL_NODE_TYPE_MAP, &tmp); - if (ret) + if (ret) { + ret = pcibios_err_to_errno(ret); goto out; + } gpu_node_map.node_count = FIELD_GET(LNTM_NODE_COUNT, tmp); gpu_node_map.base_node_id = FIELD_GET(LNTM_BASE_NODE_ID, tmp); -- 2.39.2

1 year, 1 month

3
3
0 0

Re: Patch "ALSA: timer: Set lower bound of start tick time" has been added to the 6.8-stable tree

by Takashi Iwai

On Thu, 30 May 2024 21:02:36 +0200, Sasha Levin wrote: > > This is a note to let you know that I've just added the patch titled > > ALSA: timer: Set lower bound of start tick time > > to the 6.8-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > alsa-timer-set-lower-bound-of-start-tick-time.patch > and it can be found in the queue-6.8 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. Please drop this one for 6.8 and older (you posted for 6.6 too). As already explained in another mail, this commit needs a prerequisite use of guard(). An alternative patch has been already submitted. Take it instead: https://lore.kernel.org/all/20240527062431.18709-1-tiwai@suse.de/ thanks, Takashi > > > > commit d717dbdb94145bee1e9cf9eca387d973564203c4 > Author: Takashi Iwai <tiwai(a)suse.de> > Date: Tue May 14 20:27:36 2024 +0200 > > ALSA: timer: Set lower bound of start tick time > > [ Upstream commit 4a63bd179fa8d3fcc44a0d9d71d941ddd62f0c4e ] > > Currently ALSA timer doesn't have the lower limit of the start tick > time, and it allows a very small size, e.g. 1 tick with 1ns resolution > for hrtimer. Such a situation may lead to an unexpected RCU stall, > where the callback repeatedly queuing the expire update, as reported > by fuzzer. > > This patch introduces a sanity check of the timer start tick time, so > that the system returns an error when a too small start size is set. > As of this patch, the lower limit is hard-coded to 100us, which is > small enough but can still work somehow. > > Reported-by: syzbot+43120c2af6ca2938cc38(a)syzkaller.appspotmail.com > Closes: https://lore.kernel.org/r/000000000000fa00a1061740ab6d@google.com > Cc: <stable(a)vger.kernel.org> > Link: https://lore.kernel.org/r/20240514182745.4015-1-tiwai@suse.de > Signed-off-by: Takashi Iwai <tiwai(a)suse.de> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/sound/core/timer.c b/sound/core/timer.c > index e6e551d4a29e0..42c4c2b029526 100644 > --- a/sound/core/timer.c > +++ b/sound/core/timer.c > @@ -553,6 +553,14 @@ static int snd_timer_start1(struct snd_timer_instance *timeri, > goto unlock; > } > > + /* check the actual time for the start tick; > + * bail out as error if it's way too low (< 100us) > + */ > + if (start) { > + if ((u64)snd_timer_hw_resolution(timer) * ticks < 100000) > + return -EINVAL; > + } > + > if (start) > timeri->ticks = timeri->cticks = ticks; > else if (!timeri->cticks)

1 year, 1 month

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024