September 2023 - Linux-stable-mirror

[PATCH 1/2] drm/i915: Schedule the HPD poll init work on an unbound workqueue

by Imre Deak

Disabling HPD polling from i915_hpd_poll_init_work() involves probing all display connectors explicitly to account for lost hotplug interrupts. On some platforms (mostly pre-ICL) with HDMI connectors the I2C EDID bit-banging using udelay() triggers in turn the workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND warning. Fix the above by scheduling i915_hpd_poll_init_work() on a WQ_UNBOUND workqueue. It's ok to use a system WQ, since i915_hpd_poll_init_work() is properly flushed in intel_hpd_cancel_work(). The connector probing from drm_mode_config::output_poll_work resulting in the same warning is fixed by the next patch. Cc: Tejun Heo <tj(a)kernel.org> Cc: Heiner Kallweit <hkallweit1(a)gmail.com> CC: stable(a)vger.kernel.org # 6.5 Suggested-by: Tejun Heo <tj(a)kernel.org> Suggested-by: Heiner Kallweit <hkallweit1(a)gmail.com> Reported-by: Heiner Kallweit <hkallweit1(a)gmail.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9245 Link: https://lore.kernel.org/all/f7e21caa-e98d-e5b5-932a-fe12d27fde9b@gmail.com Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/i915/display/intel_hotplug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c b/drivers/gpu/drm/i915/display/intel_hotplug.c index e8562f6f8bb44..accc2fec562a0 100644 --- a/drivers/gpu/drm/i915/display/intel_hotplug.c +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c @@ -774,7 +774,7 @@ void intel_hpd_poll_enable(struct drm_i915_private *dev_priv) * As well, there's no issue if we race here since we always reschedule * this worker anyway */ - queue_work(dev_priv->unordered_wq, + queue_work(system_unbound_wq, &dev_priv->display.hotplug.poll_init_work); } @@ -803,7 +803,7 @@ void intel_hpd_poll_disable(struct drm_i915_private *dev_priv) return; WRITE_ONCE(dev_priv->display.hotplug.poll_enabled, false); - queue_work(dev_priv->unordered_wq, + queue_work(system_unbound_wq, &dev_priv->display.hotplug.poll_init_work); } -- 2.37.2

1 month, 1 week

4
5
0 0

Re: [PATCH 1/2] arm64: efi: Execute runtime services from a dedicated stack

by Lee Jones

On Mon, 05 Dec 2022, Ard Biesheuvel wrote: > With the introduction of PRMT in the ACPI subsystem, the EFI rts > workqueue is no longer the only caller of efi_call_virt_pointer() in the > kernel. This means the EFI runtime services lock is no longer sufficient > to manage concurrent calls into firmware, but also that firmware calls > may occur that are not marshalled via the workqueue mechanism, but > originate directly from the caller context. > > For added robustness, and to ensure that the runtime services have 8 KiB > of stack space available as per the EFI spec, introduce a spinlock > protected EFI runtime stack of 8 KiB, where the spinlock also ensures > serialization between the EFI rts workqueue (which itself serializes EFI > runtime calls) and other callers of efi_call_virt_pointer(). > > While at it, use the stack pivot to avoid reloading the shadow call > stack pointer from the ordinary stack, as doing so could produce a > gadget to defeat it. > > Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> > --- > arch/arm64/include/asm/efi.h | 3 +++ > arch/arm64/kernel/efi-rt-wrapper.S | 13 +++++++++- > arch/arm64/kernel/efi.c | 25 ++++++++++++++++++++ > 3 files changed, 40 insertions(+), 1 deletion(-) Could we have this in Stable please? Upstream commit: ff7a167961d1b ("arm64: efi: Execute runtime services from a dedicated stack") Ard, do we need Patch 2 as well, or can this be applied on its own? > diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h > index 7c12e01c2b312e7b..1c408ec3c8b3a883 100644 > --- a/arch/arm64/include/asm/efi.h > +++ b/arch/arm64/include/asm/efi.h > @@ -25,6 +25,7 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md); > ({ \ > efi_virtmap_load(); \ > __efi_fpsimd_begin(); \ > + spin_lock(&efi_rt_lock); \ > }) > > #undef arch_efi_call_virt > @@ -33,10 +34,12 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md); > > #define arch_efi_call_virt_teardown() \ > ({ \ > + spin_unlock(&efi_rt_lock); \ > __efi_fpsimd_end(); \ > efi_virtmap_unload(); \ > }) > > +extern spinlock_t efi_rt_lock; > efi_status_t __efi_rt_asm_wrapper(void *, const char *, ...); > > #define ARCH_EFI_IRQ_FLAGS_MASK (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT) > diff --git a/arch/arm64/kernel/efi-rt-wrapper.S b/arch/arm64/kernel/efi-rt-wrapper.S > index 75691a2641c1c0f8..b2786b968fee68dd 100644 > --- a/arch/arm64/kernel/efi-rt-wrapper.S > +++ b/arch/arm64/kernel/efi-rt-wrapper.S > @@ -16,6 +16,12 @@ SYM_FUNC_START(__efi_rt_asm_wrapper) > */ > stp x1, x18, [sp, #16] > > + ldr_l x16, efi_rt_stack_top > + mov sp, x16 > +#ifdef CONFIG_SHADOW_CALL_STACK > + str x18, [sp, #-16]! > +#endif > + > /* > * We are lucky enough that no EFI runtime services take more than > * 5 arguments, so all are passed in registers rather than via the > @@ -29,6 +35,7 @@ SYM_FUNC_START(__efi_rt_asm_wrapper) > mov x4, x6 > blr x8 > > + mov sp, x29 > ldp x1, x2, [sp, #16] > cmp x2, x18 > ldp x29, x30, [sp], #32 > @@ -42,6 +49,10 @@ SYM_FUNC_START(__efi_rt_asm_wrapper) > * called with preemption disabled and a separate shadow stack is used > * for interrupts. > */ > - mov x18, x2 > +#ifdef CONFIG_SHADOW_CALL_STACK > + ldr_l x18, efi_rt_stack_top > + ldr x18, [x18, #-16] > +#endif > + > b efi_handle_corrupted_x18 // tail call > SYM_FUNC_END(__efi_rt_asm_wrapper) > diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c > index a908a37f03678b6b..8cb2e005f8aca589 100644 > --- a/arch/arm64/kernel/efi.c > +++ b/arch/arm64/kernel/efi.c > @@ -144,3 +144,28 @@ asmlinkage efi_status_t efi_handle_corrupted_x18(efi_status_t s, const char *f) > pr_err_ratelimited(FW_BUG "register x18 corrupted by EFI %s\n", f); > return s; > } > + > +DEFINE_SPINLOCK(efi_rt_lock); > + > +asmlinkage u64 *efi_rt_stack_top __ro_after_init; > + > +/* required by the EFI spec */ > +static_assert(THREAD_SIZE >= SZ_8K); > + > +int __init arm64_efi_rt_init(void) > +{ > + void *p = __vmalloc_node_range(THREAD_SIZE, THREAD_ALIGN, > + VMALLOC_START, VMALLOC_END, GFP_KERNEL, > + PAGE_KERNEL, 0, NUMA_NO_NODE, > + __builtin_return_address(0)); > + > + if (!p) { > + pr_warn("Failed to allocate EFI runtime stack\n"); > + clear_bit(EFI_RUNTIME_SERVICES, &efi.flags); > + return -ENOMEM; > + } > + > + efi_rt_stack_top = p + THREAD_SIZE; > + return 0; > +} > +core_initcall(arm64_efi_rt_init); > -- > 2.35.1 > > -- Lee Jones [李琼斯]

2 months, 1 week

6
13
0 0

FAILED: patch "[PATCH] s390/dasd: Use correct lock while counting channel queue" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x ccc45cb4e7271c74dbb27776ae8f73d84557f5c6 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023061111-tracing-shakiness-9054@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ccc45cb4e7271c74dbb27776ae8f73d84557f5c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jan=20H=C3=B6ppner?= <hoeppner(a)linux.ibm.com> Date: Fri, 9 Jun 2023 17:37:50 +0200 Subject: [PATCH] s390/dasd: Use correct lock while counting channel queue length MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The lock around counting the channel queue length in the BIODASDINFO ioctl was incorrectly changed to the dasd_block->queue_lock with commit 583d6535cb9d ("dasd: remove dead code"). This can lead to endless list iterations and a subsequent crash. The queue_lock is supposed to be used only for queue lists belonging to dasd_block. For dasd_device related queue lists the ccwdev lock must be used. Fix the mentioned issues by correctly using the ccwdev lock instead of the queue lock. Fixes: 583d6535cb9d ("dasd: remove dead code") Cc: stable(a)vger.kernel.org # v5.0+ Signed-off-by: Jan Höppner <hoeppner(a)linux.ibm.com> Reviewed-by: Stefan Haberland <sth(a)linux.ibm.com> Signed-off-by: Stefan Haberland <sth(a)linux.ibm.com> Link: https://lore.kernel.org/r/20230609153750.1258763-2-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/drivers/s390/block/dasd_ioctl.c b/drivers/s390/block/dasd_ioctl.c index 9327dcdd6e5e..8fca725b3dae 100644 --- a/drivers/s390/block/dasd_ioctl.c +++ b/drivers/s390/block/dasd_ioctl.c @@ -552,10 +552,10 @@ static int __dasd_ioctl_information(struct dasd_block *block, memcpy(dasd_info->type, base->discipline->name, 4); - spin_lock_irqsave(&block->queue_lock, flags); + spin_lock_irqsave(get_ccwdev_lock(base->cdev), flags); list_for_each(l, &base->ccw_queue) dasd_info->chanq_len++; - spin_unlock_irqrestore(&block->queue_lock, flags); + spin_unlock_irqrestore(get_ccwdev_lock(base->cdev), flags); return 0; }

2 months, 4 weeks

4
5
0 0

[PATCH V2 1/3] MIPS: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK

by Huacai Chen

When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.084034] Hardware name: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<98000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9800000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<980000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9800000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9800000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<98000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<98000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<98000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<98000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9800000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]--- Cc: stable(a)vger.kernel.org Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- arch/mips/kernel/proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c index 4184d641f05e..33a02f3814f5 100644 --- a/arch/mips/kernel/proc.c +++ b/arch/mips/kernel/proc.c @@ -172,7 +172,7 @@ static void *c_start(struct seq_file *m, loff_t *pos) { unsigned long i = *pos; - return i < NR_CPUS ? (void *) (i + 1) : NULL; + return i < nr_cpu_ids ? (void *) (i + 1) : NULL; } static void *c_next(struct seq_file *m, void *v, loff_t *pos) -- 2.31.1

5 months, 2 weeks

5
15
0 0

[PATCH 1/1] nvme-pci: add NVME_QUIRK_BOGUS_NID for Samsung PM173X

by Saeed Mirzamohammadi

This adds a quirk to fix the Samsung PM1733a and PM173X reporting bogus eui64 so they are not marked as "non globally unique" duplicates. Cc: <stable(a)vger.kernel.org> Signed-off-by: Saeed Mirzamohammadi <saeed.mirzamohammadi(a)oracle.com> --- drivers/nvme/host/pci.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 5b95c94ee40f2..c0b1caba1c893 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -3359,6 +3359,10 @@ static const struct pci_device_id nvme_id_table[] = { .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY | NVME_QUIRK_DISABLE_WRITE_ZEROES| NVME_QUIRK_IGNORE_DEV_SUBNQN, }, + { PCI_DEVICE(0x144d, 0xa824), /* Samsung PM173X */ + .driver_data = NVME_QUIRK_BOGUS_NID, }, + { PCI_DEVICE(0x144d, 0xa825), /* Samsung PM1733a */ + .driver_data = NVME_QUIRK_BOGUS_NID, }, { PCI_DEVICE(0x1987, 0x5012), /* Phison E12 */ .driver_data = NVME_QUIRK_BOGUS_NID, }, { PCI_DEVICE(0x1987, 0x5016), /* Phison E16 */ -- 2.39.2

8 months, 3 weeks

6
13
0 0

FAILED: patch "[PATCH] KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x b321c31c9b7b309dcde5e8854b741c8e6a9a05f0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023072323-trident-unturned-7999@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: b321c31c9b7b ("KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption") 0c2f9acf6ae7 ("KVM: arm64: PMU: Don't overwrite PMUSERENR with vcpu loaded") 8681f7175901 ("KVM: arm64: PMU: Restore the host's PMUSERENR_EL0") 009d6dc87a56 ("ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM") 711432770f78 ("perf: pmuv3: Abstract PMU version checks") df29ddf4f04b ("arm64: perf: Abstract system register accesses away") 7755cec63ade ("arm64: perf: Move PMUv3 driver to drivers/perf") cc91b9481605 ("arm64/perf: Replace PMU version number '0' with ID_AA64DFR0_EL1_PMUVer_NI") 4151bb636acf ("KVM: arm64: Fix SMPRI_EL1/TPIDR2_EL0 trapping on VHE") bb0cca240a16 ("Merge branch kvm-arm64/single-step-async-exception into kvmarm-master/next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b321c31c9b7b309dcde5e8854b741c8e6a9a05f0 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <maz(a)kernel.org> Date: Thu, 13 Jul 2023 08:06:57 +0100 Subject: [PATCH] KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption Xiang reports that VMs occasionally fail to boot on GICv4.1 systems when running a preemptible kernel, as it is possible that a vCPU is blocked without requesting a doorbell interrupt. The issue is that any preemption that occurs between vgic_v4_put() and schedule() on the block path will mark the vPE as nonresident and *not* request a doorbell irq. This occurs because when the vcpu thread is resumed on its way to block, vcpu_load() will make the vPE resident again. Once the vcpu actually blocks, we don't request a doorbell anymore, and the vcpu won't be woken up on interrupt delivery. Fix it by tracking that we're entering WFI, and key the doorbell request on that flag. This allows us not to make the vPE resident when going through a preempt/schedule cycle, meaning we don't lose any state. Cc: stable(a)vger.kernel.org Fixes: 8e01d9a396e6 ("KVM: arm64: vgic-v4: Move the GICv4 residency flow to be driven by vcpu_load/put") Reported-by: Xiang Chen <chenxiang66(a)hisilicon.com> Suggested-by: Zenghui Yu <yuzenghui(a)huawei.com> Tested-by: Xiang Chen <chenxiang66(a)hisilicon.com> Co-developed-by: Oliver Upton <oliver.upton(a)linux.dev> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Acked-by: Zenghui Yu <yuzenghui(a)huawei.com> Link: https://lore.kernel.org/r/20230713070657.3873244-1-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 8b6096753740..d3dd05bbfe23 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -727,6 +727,8 @@ struct kvm_vcpu_arch { #define DBG_SS_ACTIVE_PENDING __vcpu_single_flag(sflags, BIT(5)) /* PMUSERENR for the guest EL0 is on physical CPU */ #define PMUSERENR_ON_CPU __vcpu_single_flag(sflags, BIT(6)) +/* WFI instruction trapped */ +#define IN_WFI __vcpu_single_flag(sflags, BIT(7)) /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */ diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index a402ea5511f3..72dc53a75d1c 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -718,13 +718,15 @@ void kvm_vcpu_wfi(struct kvm_vcpu *vcpu) */ preempt_disable(); kvm_vgic_vmcr_sync(vcpu); - vgic_v4_put(vcpu, true); + vcpu_set_flag(vcpu, IN_WFI); + vgic_v4_put(vcpu); preempt_enable(); kvm_vcpu_halt(vcpu); vcpu_clear_flag(vcpu, IN_WFIT); preempt_disable(); + vcpu_clear_flag(vcpu, IN_WFI); vgic_v4_load(vcpu); preempt_enable(); } @@ -792,7 +794,7 @@ static int check_vcpu_requests(struct kvm_vcpu *vcpu) if (kvm_check_request(KVM_REQ_RELOAD_GICv4, vcpu)) { /* The distributor enable bits were changed */ preempt_disable(); - vgic_v4_put(vcpu, false); + vgic_v4_put(vcpu); vgic_v4_load(vcpu); preempt_enable(); } diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c index c3b8e132d599..3dfc8b84e03e 100644 --- a/arch/arm64/kvm/vgic/vgic-v3.c +++ b/arch/arm64/kvm/vgic/vgic-v3.c @@ -749,7 +749,7 @@ void vgic_v3_put(struct kvm_vcpu *vcpu) { struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3; - WARN_ON(vgic_v4_put(vcpu, false)); + WARN_ON(vgic_v4_put(vcpu)); vgic_v3_vmcr_sync(vcpu); diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c index c1c28fe680ba..339a55194b2c 100644 --- a/arch/arm64/kvm/vgic/vgic-v4.c +++ b/arch/arm64/kvm/vgic/vgic-v4.c @@ -336,14 +336,14 @@ void vgic_v4_teardown(struct kvm *kvm) its_vm->vpes = NULL; } -int vgic_v4_put(struct kvm_vcpu *vcpu, bool need_db) +int vgic_v4_put(struct kvm_vcpu *vcpu) { struct its_vpe *vpe = &vcpu->arch.vgic_cpu.vgic_v3.its_vpe; if (!vgic_supports_direct_msis(vcpu->kvm) || !vpe->resident) return 0; - return its_make_vpe_non_resident(vpe, need_db); + return its_make_vpe_non_resident(vpe, !!vcpu_get_flag(vcpu, IN_WFI)); } int vgic_v4_load(struct kvm_vcpu *vcpu) @@ -354,6 +354,9 @@ int vgic_v4_load(struct kvm_vcpu *vcpu) if (!vgic_supports_direct_msis(vcpu->kvm) || vpe->resident) return 0; + if (vcpu_get_flag(vcpu, IN_WFI)) + return 0; + /* * Before making the VPE resident, make sure the redistributor * corresponding to our current CPU expects us here. See the diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h index 402b545959af..5b27f94d4fad 100644 --- a/include/kvm/arm_vgic.h +++ b/include/kvm/arm_vgic.h @@ -431,7 +431,7 @@ int kvm_vgic_v4_unset_forwarding(struct kvm *kvm, int irq, int vgic_v4_load(struct kvm_vcpu *vcpu); void vgic_v4_commit(struct kvm_vcpu *vcpu); -int vgic_v4_put(struct kvm_vcpu *vcpu, bool need_db); +int vgic_v4_put(struct kvm_vcpu *vcpu); /* CPU HP callbacks */ void kvm_vgic_cpu_up(void);

10 months, 3 weeks

4
3
0 0

[PATCH 6.1.y v2 0/6] BPF selftests fixes for 6.1 branch

by Eduard Zingerman

Recently Luiz Capitulino reported BPF test failure for kernel version 6.1.36 (see [7]). The following test_verifier test failed: "precise: ST insn causing spi > allocated_stack". After back-port of the following upstream commit: ecdf985d7615 ("bpf: track immediate values written to stack by BPF_ST instruction") Investigation in [8] shows that test failure is not a bug, but a difference in BPF verifier behavior between upstream, where commits [1,2,3] by Andrii Nakryiko are present, and 6.1.36, where these commits are absent. Both Luiz and Greg suggested back-porting [1,2,3] from upstream to avoid divergences. Commits [1,2,3] break test_progs selftest "align/packet variable offset", commit [4] fixes this selftest. I did some additional testing using the following compiler versions: - Kernel compilation - gcc version 11.3.0 - BPF tests compilation - clang version 16.0.6 - clang version 17.0.0 (fa46feb31481) And identified a few more failing BPF selftests: - Tests failing with LLVM 16: - test_verifier: - precise: ST insn causing spi > allocated_stack FAIL (fixed by [1,2,3]) - test_progs: - sk_assign (fixed by [6]) - Tests failing with LLVM 17: - test_verifier: - precise: ST insn causing spi > allocated_stack FAIL (fixed by [1,2,3]) - test_progs: - fexit_bpf2bpf/func_replace_verify (fixed by [5]) - fexit_bpf2bpf/func_replace_return_code (fixed by [5]) - sk_assign (fixed by [6]) Commits [4,5,6] only apply to BPF selftests and don't change verifier behavior. After applying all of the listed commits I have test_verifier, test_progs, test_progs-no_alu32 and test_maps passing on my x86 setup, both for LLVM 16 and LLVM 17. Upstream commits in chronological order: [1] be2ef8161572 ("bpf: allow precision tracking for programs with subprogs") [2] f63181b6ae79 ("bpf: stop setting precise in current state") [3] 7a830b53c17b ("bpf: aggressively forget precise markings during state checkpointing") [4] 4f999b767769 ("selftests/bpf: make test_align selftest more robust") [5] 63d78b7e8ca2 ("selftests/bpf: Workaround verification failure for fexit_bpf2bpf/func_replace_return_code") [6] 7ce878ca81bc ("selftests/bpf: Fix sk_assign on s390x") Links: [7] https://lore.kernel.org/stable/935c4751-d368-df29-33a6-9f4fcae720fa@amazon.… [8] https://lore.kernel.org/stable/c9b10a8a551edafdfec855fbd35757c6238ad258.cam… Changelog: V1 -> V2: added missing signed-off-by tags V1: https://lore.kernel.org/stable/20230722004514.767618-1-eddyz87@gmail.com/ Reported-by: Luiz Capitulino <luizcap(a)amazon.com> Andrii Nakryiko (4): bpf: allow precision tracking for programs with subprogs bpf: stop setting precise in current state bpf: aggressively forget precise markings during state checkpointing selftests/bpf: make test_align selftest more robust Ilya Leoshkevich (1): selftests/bpf: Fix sk_assign on s390x Yonghong Song (1): selftests/bpf: Workaround verification failure for fexit_bpf2bpf/func_replace_return_code kernel/bpf/verifier.c | 202 ++++++++++++++++-- .../testing/selftests/bpf/prog_tests/align.c | 38 ++-- .../selftests/bpf/prog_tests/sk_assign.c | 25 ++- .../selftests/bpf/progs/connect4_prog.c | 2 +- .../selftests/bpf/progs/test_sk_assign.c | 11 + .../bpf/progs/test_sk_assign_libbpf.c | 3 + 6 files changed, 247 insertions(+), 34 deletions(-) create mode 100644 tools/testing/selftests/bpf/progs/test_sk_assign_libbpf.c -- 2.41.0

10 months, 3 weeks

4
9
0 0

FAILED: patch "[PATCH] KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x b321c31c9b7b309dcde5e8854b741c8e6a9a05f0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023072324-aviation-delirious-b27d@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: b321c31c9b7b ("KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption") 0c2f9acf6ae7 ("KVM: arm64: PMU: Don't overwrite PMUSERENR with vcpu loaded") 8681f7175901 ("KVM: arm64: PMU: Restore the host's PMUSERENR_EL0") 009d6dc87a56 ("ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM") 711432770f78 ("perf: pmuv3: Abstract PMU version checks") df29ddf4f04b ("arm64: perf: Abstract system register accesses away") 7755cec63ade ("arm64: perf: Move PMUv3 driver to drivers/perf") cc91b9481605 ("arm64/perf: Replace PMU version number '0' with ID_AA64DFR0_EL1_PMUVer_NI") 4151bb636acf ("KVM: arm64: Fix SMPRI_EL1/TPIDR2_EL0 trapping on VHE") bb0cca240a16 ("Merge branch kvm-arm64/single-step-async-exception into kvmarm-master/next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b321c31c9b7b309dcde5e8854b741c8e6a9a05f0 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <maz(a)kernel.org> Date: Thu, 13 Jul 2023 08:06:57 +0100 Subject: [PATCH] KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption Xiang reports that VMs occasionally fail to boot on GICv4.1 systems when running a preemptible kernel, as it is possible that a vCPU is blocked without requesting a doorbell interrupt. The issue is that any preemption that occurs between vgic_v4_put() and schedule() on the block path will mark the vPE as nonresident and *not* request a doorbell irq. This occurs because when the vcpu thread is resumed on its way to block, vcpu_load() will make the vPE resident again. Once the vcpu actually blocks, we don't request a doorbell anymore, and the vcpu won't be woken up on interrupt delivery. Fix it by tracking that we're entering WFI, and key the doorbell request on that flag. This allows us not to make the vPE resident when going through a preempt/schedule cycle, meaning we don't lose any state. Cc: stable(a)vger.kernel.org Fixes: 8e01d9a396e6 ("KVM: arm64: vgic-v4: Move the GICv4 residency flow to be driven by vcpu_load/put") Reported-by: Xiang Chen <chenxiang66(a)hisilicon.com> Suggested-by: Zenghui Yu <yuzenghui(a)huawei.com> Tested-by: Xiang Chen <chenxiang66(a)hisilicon.com> Co-developed-by: Oliver Upton <oliver.upton(a)linux.dev> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Acked-by: Zenghui Yu <yuzenghui(a)huawei.com> Link: https://lore.kernel.org/r/20230713070657.3873244-1-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 8b6096753740..d3dd05bbfe23 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -727,6 +727,8 @@ struct kvm_vcpu_arch { #define DBG_SS_ACTIVE_PENDING __vcpu_single_flag(sflags, BIT(5)) /* PMUSERENR for the guest EL0 is on physical CPU */ #define PMUSERENR_ON_CPU __vcpu_single_flag(sflags, BIT(6)) +/* WFI instruction trapped */ +#define IN_WFI __vcpu_single_flag(sflags, BIT(7)) /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */ diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index a402ea5511f3..72dc53a75d1c 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -718,13 +718,15 @@ void kvm_vcpu_wfi(struct kvm_vcpu *vcpu) */ preempt_disable(); kvm_vgic_vmcr_sync(vcpu); - vgic_v4_put(vcpu, true); + vcpu_set_flag(vcpu, IN_WFI); + vgic_v4_put(vcpu); preempt_enable(); kvm_vcpu_halt(vcpu); vcpu_clear_flag(vcpu, IN_WFIT); preempt_disable(); + vcpu_clear_flag(vcpu, IN_WFI); vgic_v4_load(vcpu); preempt_enable(); } @@ -792,7 +794,7 @@ static int check_vcpu_requests(struct kvm_vcpu *vcpu) if (kvm_check_request(KVM_REQ_RELOAD_GICv4, vcpu)) { /* The distributor enable bits were changed */ preempt_disable(); - vgic_v4_put(vcpu, false); + vgic_v4_put(vcpu); vgic_v4_load(vcpu); preempt_enable(); } diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c index c3b8e132d599..3dfc8b84e03e 100644 --- a/arch/arm64/kvm/vgic/vgic-v3.c +++ b/arch/arm64/kvm/vgic/vgic-v3.c @@ -749,7 +749,7 @@ void vgic_v3_put(struct kvm_vcpu *vcpu) { struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3; - WARN_ON(vgic_v4_put(vcpu, false)); + WARN_ON(vgic_v4_put(vcpu)); vgic_v3_vmcr_sync(vcpu); diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c index c1c28fe680ba..339a55194b2c 100644 --- a/arch/arm64/kvm/vgic/vgic-v4.c +++ b/arch/arm64/kvm/vgic/vgic-v4.c @@ -336,14 +336,14 @@ void vgic_v4_teardown(struct kvm *kvm) its_vm->vpes = NULL; } -int vgic_v4_put(struct kvm_vcpu *vcpu, bool need_db) +int vgic_v4_put(struct kvm_vcpu *vcpu) { struct its_vpe *vpe = &vcpu->arch.vgic_cpu.vgic_v3.its_vpe; if (!vgic_supports_direct_msis(vcpu->kvm) || !vpe->resident) return 0; - return its_make_vpe_non_resident(vpe, need_db); + return its_make_vpe_non_resident(vpe, !!vcpu_get_flag(vcpu, IN_WFI)); } int vgic_v4_load(struct kvm_vcpu *vcpu) @@ -354,6 +354,9 @@ int vgic_v4_load(struct kvm_vcpu *vcpu) if (!vgic_supports_direct_msis(vcpu->kvm) || vpe->resident) return 0; + if (vcpu_get_flag(vcpu, IN_WFI)) + return 0; + /* * Before making the VPE resident, make sure the redistributor * corresponding to our current CPU expects us here. See the diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h index 402b545959af..5b27f94d4fad 100644 --- a/include/kvm/arm_vgic.h +++ b/include/kvm/arm_vgic.h @@ -431,7 +431,7 @@ int kvm_vgic_v4_unset_forwarding(struct kvm *kvm, int irq, int vgic_v4_load(struct kvm_vcpu *vcpu); void vgic_v4_commit(struct kvm_vcpu *vcpu); -int vgic_v4_put(struct kvm_vcpu *vcpu, bool need_db); +int vgic_v4_put(struct kvm_vcpu *vcpu); /* CPU HP callbacks */ void kvm_vgic_cpu_up(void);

10 months, 3 weeks

4
4
0 0

[PATCH MANUALSEL 4.19 1/2] KVM: x86: Handle SRCU initialization failure during page track init

by Sasha Levin

From: Haimin Zhang <tcs_kernel(a)tencent.com> [ Upstream commit eb7511bf9182292ef1df1082d23039e856d1ddfb ] Check the return of init_srcu_struct(), which can fail due to OOM, when initializing the page track mechanism. Lack of checking leads to a NULL pointer deref found by a modified syzkaller. Reported-by: TCS Robot <tcs_robot(a)tencent.com> Signed-off-by: Haimin Zhang <tcs_kernel(a)tencent.com> Message-Id: <1630636626-12262-1-git-send-email-tcs_kernel(a)tencent.com> [Move the call towards the beginning of kvm_arch_init_vm. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/include/asm/kvm_page_track.h | 2 +- arch/x86/kvm/page_track.c | 4 ++-- arch/x86/kvm/x86.c | 7 ++++++- 3 files changed, 9 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/kvm_page_track.h b/arch/x86/include/asm/kvm_page_track.h index 172f9749dbb2..5986bd4aacd6 100644 --- a/arch/x86/include/asm/kvm_page_track.h +++ b/arch/x86/include/asm/kvm_page_track.h @@ -46,7 +46,7 @@ struct kvm_page_track_notifier_node { struct kvm_page_track_notifier_node *node); }; -void kvm_page_track_init(struct kvm *kvm); +int kvm_page_track_init(struct kvm *kvm); void kvm_page_track_cleanup(struct kvm *kvm); void kvm_page_track_free_memslot(struct kvm_memory_slot *free, diff --git a/arch/x86/kvm/page_track.c b/arch/x86/kvm/page_track.c index 3052a59a3065..1f6b0d9b0c85 100644 --- a/arch/x86/kvm/page_track.c +++ b/arch/x86/kvm/page_track.c @@ -169,13 +169,13 @@ void kvm_page_track_cleanup(struct kvm *kvm) cleanup_srcu_struct(&head->track_srcu); } -void kvm_page_track_init(struct kvm *kvm) +int kvm_page_track_init(struct kvm *kvm) { struct kvm_page_track_notifier_head *head; head = &kvm->arch.track_notifier_head; - init_srcu_struct(&head->track_srcu); INIT_HLIST_HEAD(&head->track_notifier_list); + return init_srcu_struct(&head->track_srcu); } /* diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 417abc9ba1ad..70cb18f89029 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -9039,9 +9039,15 @@ void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) int kvm_arch_init_vm(struct kvm *kvm, unsigned long type) { + int ret; + if (type) return -EINVAL; + ret = kvm_page_track_init(kvm); + if (ret) + return ret; + INIT_HLIST_HEAD(&kvm->arch.mask_notifier_list); INIT_LIST_HEAD(&kvm->arch.active_mmu_pages); INIT_LIST_HEAD(&kvm->arch.zapped_obsolete_pages); @@ -9068,7 +9074,6 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type) INIT_DELAYED_WORK(&kvm->arch.kvmclock_sync_work, kvmclock_sync_fn); kvm_hv_init_vm(kvm); - kvm_page_track_init(kvm); kvm_mmu_init_vm(kvm); if (kvm_x86_ops->vm_init) -- 2.33.0

11 months, 1 week

4
4
0 0

FAILED: patch "[PATCH] KVM: x86: Clear "has_error_code", not "error_code", for RM" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 6c41468c7c12d74843bb414fc00307ea8a6318c3 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023041135-yippee-shabby-b9ad@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 6c41468c7c12 ("KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection") d4963e319f1f ("KVM: x86: Make kvm_queued_exception a properly named, visible struct") 6ad75c5c99f7 ("KVM: x86: Rename kvm_x86_ops.queue_exception to inject_exception") 5623f751bd9c ("KVM: x86: Treat #DBs from the emulator as fault-like (code and DR7.GD=1)") 8d178f460772 ("KVM: nVMX: Treat General Detect #DB (DR7.GD=1) as fault-like") eba9799b5a6e ("KVM: VMX: Drop bits 31:16 when shoving exception error code into VMCS") a61d7c5432ac ("KVM: x86: Trace re-injected exceptions") 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction") 3741aec4c38f ("KVM: SVM: Stuff next_rip on emulated INT3 injection if NRIPS is supported") cd9e6da8048c ("KVM: SVM: Unwind "speculative" RIP advancement if INTn injection "fails"") 00f08d99dd7d ("KVM: nSVM: Sync next_rip field from vmcb12 to vmcb02") 9bd1f0efa859 ("KVM: nVMX: Clear IDT vectoring on nested VM-Exit for double/triple fault") c3634d25fbee ("KVM: nVMX: Leave most VM-Exit info fields unmodified on failed VM-Entry") 1d5a1b5860ed ("KVM: x86: nSVM: correctly virtualize LBR msrs when L2 is running") db663af4a001 ("kvm: x86: SVM: use vmcb* instead of svm->vmcb where it makes sense") b9f3973ab3a8 ("KVM: x86: nSVM: implement nested VMLOAD/VMSAVE") 23e5092b6e2a ("KVM: SVM: Rename hook implementations to conform to kvm_x86_ops' names") e27bc0440ebd ("KVM: x86: Rename kvm_x86_ops pointers to align w/ preferred vendor names") 068f7ea61895 ("KVM: SVM: improve split between svm_prepare_guest_switch and sev_es_prepare_guest_switch") e1779c2714c3 ("KVM: x86: nSVM: fix potential NULL derefernce on nested migration") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6c41468c7c12d74843bb414fc00307ea8a6318c3 Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Wed, 22 Mar 2023 07:32:59 -0700 Subject: [PATCH] KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection When injecting an exception into a vCPU in Real Mode, suppress the error code by clearing the flag that tracks whether the error code is valid, not by clearing the error code itself. The "typo" was introduced by recent fix for SVM's funky Paged Real Mode. Opportunistically hoist the logic above the tracepoint so that the trace is coherent with respect to what is actually injected (this was also the behavior prior to the buggy commit). Fixes: b97f07458373 ("KVM: x86: determine if an exception has an error code only when injecting it.") Cc: stable(a)vger.kernel.org Cc: Maxim Levitsky <mlevitsk(a)redhat.com> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20230322143300.2209476-2-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 45017576ad5e..7d6f98b7635f 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -9908,13 +9908,20 @@ int kvm_check_nested_events(struct kvm_vcpu *vcpu) static void kvm_inject_exception(struct kvm_vcpu *vcpu) { + /* + * Suppress the error code if the vCPU is in Real Mode, as Real Mode + * exceptions don't report error codes. The presence of an error code + * is carried with the exception and only stripped when the exception + * is injected as intercepted #PF VM-Exits for AMD's Paged Real Mode do + * report an error code despite the CPU being in Real Mode. + */ + vcpu->arch.exception.has_error_code &= is_protmode(vcpu); + trace_kvm_inj_exception(vcpu->arch.exception.vector, vcpu->arch.exception.has_error_code, vcpu->arch.exception.error_code, vcpu->arch.exception.injected); - if (vcpu->arch.exception.error_code && !is_protmode(vcpu)) - vcpu->arch.exception.error_code = false; static_call(kvm_x86_inject_exception)(vcpu); }

12 months

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2023