June 2024 - Linux-stable-mirror

Re: Patch "KVM: arm64: nv: Add sanitising to VNCR-backed sysregs" has been added to the 6.8-stable tree

by Marc Zyngier

On Mon, 03 Jun 2024 12:52:54 +0100, Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > KVM: arm64: nv: Add sanitising to VNCR-backed sysregs > > 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: > kvm-arm64-nv-add-sanitising-to-vncr-backed-sysregs.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. > > > > commit fbb2bcdc458dd7db3860f85a06e98cc25904d20d > Author: Marc Zyngier <maz(a)kernel.org> > Date: Wed Feb 14 13:18:04 2024 +0000 > > KVM: arm64: nv: Add sanitising to VNCR-backed sysregs > > [ Upstream commit 888f0880702293096619b300150cd7e59fcd9743 ] > > VNCR-backed "registers" are actually only memory. Which means that > there is zero control over what the guest can write, and that it > is the hypervisor's job to actually sanitise the content of the > backing store. Yeah, this is fun. > > In order to preserve some form of sanity, add a repainting mechanism > that makes use of a per-VM set of RES0/RES1 masks, one pair per VNCR > register. These masks get applied on access to the backing store via > __vcpu_sys_reg(), ensuring that the state that is consumed by KVM is > correct. > > So far, nothing populates these masks, but stay tuned. > > Signed-off-by: Marc Zyngier <maz(a)kernel.org> > Reviewed-by: Joey Gouly <joey.gouly(a)arm.com> > Link: https://lore.kernel.org/r/20240214131827.2856277-4-maz@kernel.org > Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> > Stable-dep-of: ce5d2448eb8f ("KVM: arm64: Destroy mpidr_data for 'late' vCPU creation") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> Please drop this. It serves no purpose on 6.8 aside from wasting memory. If backporting ce5d2448eb8f is hard due to some conflicts, we'll tackle it ourselves. Thanks, M. -- Without deviation from the norm, progress is not possible.

1 year

1
0
0 0

[tip: irq/urgent] irqchip/sifive-plic: Chain to parent IRQ after handlers are ready

by tip-bot2 for Samuel Holland

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: e306a894bd511804ba9db7c00ca9cc05b55df1f2 Gitweb: https://git.kernel.org/tip/e306a894bd511804ba9db7c00ca9cc05b55df1f2 Author: Samuel Holland <samuel.holland(a)sifive.com> AuthorDate: Wed, 29 May 2024 14:54:56 -07:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Mon, 03 Jun 2024 13:53:12 +02:00 irqchip/sifive-plic: Chain to parent IRQ after handlers are ready Now that the PLIC uses a platform driver, the driver is probed later in the boot process, where interrupts from peripherals might already be pending. As a result, plic_handle_irq() may be called as early as the call to irq_set_chained_handler() completes. But this call happens before the per-context handler is completely set up, so there is a window where plic_handle_irq() can see incomplete per-context state and crash. Avoid this by delaying the call to irq_set_chained_handler() until all handlers from all PLICs are initialized. Fixes: 8ec99b033147 ("irqchip/sifive-plic: Convert PLIC driver into a platform driver") Reported-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Samuel Holland <samuel.holland(a)sifive.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Reviewed-by: Anup Patel <anup(a)brainfault.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240529215458.937817-1-samuel.holland@sifive.com Closes: https://lore.kernel.org/r/CAMuHMdVYFFR7K5SbHBLY-JHhb7YpgGMS_hnRWm8H0KD-wBo+… --- drivers/irqchip/irq-sifive-plic.c | 34 +++++++++++++++--------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c index 8fb183c..9e22f7e 100644 --- a/drivers/irqchip/irq-sifive-plic.c +++ b/drivers/irqchip/irq-sifive-plic.c @@ -85,7 +85,7 @@ struct plic_handler { struct plic_priv *priv; }; static int plic_parent_irq __ro_after_init; -static bool plic_cpuhp_setup_done __ro_after_init; +static bool plic_global_setup_done __ro_after_init; static DEFINE_PER_CPU(struct plic_handler, plic_handlers); static int plic_irq_set_type(struct irq_data *d, unsigned int type); @@ -487,10 +487,8 @@ static int plic_probe(struct platform_device *pdev) unsigned long plic_quirks = 0; struct plic_handler *handler; u32 nr_irqs, parent_hwirq; - struct irq_domain *domain; struct plic_priv *priv; irq_hw_number_t hwirq; - bool cpuhp_setup; if (is_of_node(dev->fwnode)) { const struct of_device_id *id; @@ -549,14 +547,6 @@ static int plic_probe(struct platform_device *pdev) continue; } - /* Find parent domain and register chained handler */ - domain = irq_find_matching_fwnode(riscv_get_intc_hwnode(), DOMAIN_BUS_ANY); - if (!plic_parent_irq && domain) { - plic_parent_irq = irq_create_mapping(domain, RV_IRQ_EXT); - if (plic_parent_irq) - irq_set_chained_handler(plic_parent_irq, plic_handle_irq); - } - /* * When running in M-mode we need to ignore the S-mode handler. * Here we assume it always comes later, but that might be a @@ -597,25 +587,35 @@ done: goto fail_cleanup_contexts; /* - * We can have multiple PLIC instances so setup cpuhp state + * We can have multiple PLIC instances so setup global state * and register syscore operations only once after context * handlers of all online CPUs are initialized. */ - if (!plic_cpuhp_setup_done) { - cpuhp_setup = true; + if (!plic_global_setup_done) { + struct irq_domain *domain; + bool global_setup = true; + for_each_online_cpu(cpu) { handler = per_cpu_ptr(&plic_handlers, cpu); if (!handler->present) { - cpuhp_setup = false; + global_setup = false; break; } } - if (cpuhp_setup) { + + if (global_setup) { + /* Find parent domain and register chained handler */ + domain = irq_find_matching_fwnode(riscv_get_intc_hwnode(), DOMAIN_BUS_ANY); + if (domain) + plic_parent_irq = irq_create_mapping(domain, RV_IRQ_EXT); + if (plic_parent_irq) + irq_set_chained_handler(plic_parent_irq, plic_handle_irq); + cpuhp_setup_state(CPUHP_AP_IRQ_SIFIVE_PLIC_STARTING, "irqchip/sifive/plic:starting", plic_starting_cpu, plic_dying_cpu); register_syscore_ops(&plic_irq_syscore_ops); - plic_cpuhp_setup_done = true; + plic_global_setup_done = true; } }

1 year

1
0
0 0

[PATCH] exfat: fix potential deadlock on __exfat_get_dentry_set

by Sungjong Seo

When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array is allocated in __exfat_get_entry_set. The problem is that the bh-array is allocated with GFP_KERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur. CPU0 CPU1 ---- ---- kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... evict exfat_evict_inode lock(&sbi->s_lock) To fix this, let's allocate bh-array with GFP_NOFS. Fixes: a3ff29a95fde ("exfat: support dynamic allocate bh for exfat_entry_set_cache") Cc: stable(a)vger.kernel.org # v6.2+ Reported-by: syzbot+412a392a2cd4a65e71db(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/000000000000fef47e0618c0327f@google.com Signed-off-by: Sungjong Seo <sj1557.seo(a)samsung.com> --- fs/exfat/dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index 84572e11cc05..7446bf09a04a 100644 --- a/fs/exfat/dir.c +++ b/fs/exfat/dir.c @@ -813,7 +813,7 @@ static int __exfat_get_dentry_set(struct exfat_entry_set_cache *es, num_bh = EXFAT_B_TO_BLK_ROUND_UP(off + num_entries * DENTRY_SIZE, sb); if (num_bh > ARRAY_SIZE(es->__bh)) { - es->bh = kmalloc_array(num_bh, sizeof(*es->bh), GFP_KERNEL); + es->bh = kmalloc_array(num_bh, sizeof(*es->bh), GFP_NOFS); if (!es->bh) { brelse(bh); return -ENOMEM; -- 2.25.1

1 year

2
1
0 0

[PATCH v3] drivers: soc: xilinx: check return status of get_api_version()

by Jay Buddhabhatti

Currently return status is not getting checked for get_api_version and because of that for x86 arch we are getting below smatch error. CC drivers/soc/xilinx/zynqmp_power.o drivers/soc/xilinx/zynqmp_power.c: In function 'zynqmp_pm_probe': drivers/soc/xilinx/zynqmp_power.c:295:12: warning: 'pm_api_version' is used uninitialized [-Wuninitialized] 295 | if (pm_api_version < ZYNQMP_PM_VERSION) | ^ CHECK drivers/soc/xilinx/zynqmp_power.c drivers/soc/xilinx/zynqmp_power.c:295 zynqmp_pm_probe() error: uninitialized symbol 'pm_api_version'. So, check return status of pm_get_api_version and return error in case of failure to avoid checking uninitialized pm_api_version variable. Fixes: b9b3a8be28b3 ("firmware: xilinx: Remove eemi ops for get_api_version") Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti(a)amd.com> Cc: stable(a)vger.kernel.org --- V1: https://lore.kernel.org/lkml/20240424063118.23200-1-jay.buddhabhatti@amd.co… V2: https://lore.kernel.org/lkml/20240509045616.22338-1-jay.buddhabhatti@amd.co… V2->V3: Added stable tree email in cc V1->V2: Removed AMD copyright --- drivers/soc/xilinx/zynqmp_power.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/soc/xilinx/zynqmp_power.c b/drivers/soc/xilinx/zynqmp_power.c index 965b1143936a..b82c01373f53 100644 --- a/drivers/soc/xilinx/zynqmp_power.c +++ b/drivers/soc/xilinx/zynqmp_power.c @@ -190,7 +190,9 @@ static int zynqmp_pm_probe(struct platform_device *pdev) u32 pm_api_version; struct mbox_client *client; - zynqmp_pm_get_api_version(&pm_api_version); + ret = zynqmp_pm_get_api_version(&pm_api_version); + if (ret) + return ret; /* Check PM API version number */ if (pm_api_version < ZYNQMP_PM_VERSION) -- 2.17.1

1 year

2
1
0 0

[tip: irq/urgent] irqchip/riscv-intc: Prevent memory leak when riscv_intc_init_common() fails

by tip-bot2 for Sunil V L

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: 0110c4b110477bb1f19b0d02361846be7ab08300 Gitweb: https://git.kernel.org/tip/0110c4b110477bb1f19b0d02361846be7ab08300 Author: Sunil V L <sunilvl(a)ventanamicro.com> AuthorDate: Mon, 27 May 2024 13:41:13 +05:30 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Mon, 03 Jun 2024 12:29:35 +02:00 irqchip/riscv-intc: Prevent memory leak when riscv_intc_init_common() fails When riscv_intc_init_common() fails, the firmware node allocated is not freed. Add the missing free(). Fixes: 7023b9d83f03 ("irqchip/riscv-intc: Add ACPI support") Signed-off-by: Sunil V L <sunilvl(a)ventanamicro.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Anup Patel <anup(a)brainfault.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240527081113.616189-1-sunilvl@ventanamicro.com --- drivers/irqchip/irq-riscv-intc.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c index 9e71c44..4f3a123 100644 --- a/drivers/irqchip/irq-riscv-intc.c +++ b/drivers/irqchip/irq-riscv-intc.c @@ -253,8 +253,9 @@ IRQCHIP_DECLARE(andes, "andestech,cpu-intc", riscv_intc_init); static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header, const unsigned long end) { - struct fwnode_handle *fn; struct acpi_madt_rintc *rintc; + struct fwnode_handle *fn; + int rc; rintc = (struct acpi_madt_rintc *)header; @@ -273,7 +274,11 @@ static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header, return -ENOMEM; } - return riscv_intc_init_common(fn, &riscv_intc_chip); + rc = riscv_intc_init_common(fn, &riscv_intc_chip); + if (rc) + irq_domain_free_fwnode(fn); + + return rc; } IRQCHIP_ACPI_DECLARE(riscv_intc, ACPI_MADT_TYPE_RINTC, NULL,

1 year

1
0
0 0

[PATCH v1 RESEND] arch/powerpc/kvm: Fix doorbell emulation by adding DPDES support

by Gautam Menghani

Doorbell emulation is broken for KVM on PowerVM guests as support for DPDES was not added in the initial patch series. Due to this, a KVM on PowerVM guest cannot be booted with the XICS interrupt controller as doorbells are to be setup in the initial probe path when using XICS (pSeries_smp_probe()). Add DPDES support in the host KVM code to fix doorbell emulation. Fixes: 6ccbbc33f06a ("KVM: PPC: Add helper library for Guest State Buffers") Cc: stable(a)vger.kernel.org Signed-off-by: Gautam Menghani <gautam(a)linux.ibm.com> --- v1 -> v1 resend: 1. Add the stable tag Documentation/arch/powerpc/kvm-nested.rst | 4 +++- arch/powerpc/include/asm/guest-state-buffer.h | 3 ++- arch/powerpc/include/asm/kvm_book3s.h | 1 + arch/powerpc/kvm/book3s_hv.c | 14 +++++++++++++- arch/powerpc/kvm/book3s_hv_nestedv2.c | 7 +++++++ arch/powerpc/kvm/test-guest-state-buffer.c | 2 +- 6 files changed, 27 insertions(+), 4 deletions(-) diff --git a/Documentation/arch/powerpc/kvm-nested.rst b/Documentation/arch/powerpc/kvm-nested.rst index 630602a8aa00..5defd13cc6c1 100644 --- a/Documentation/arch/powerpc/kvm-nested.rst +++ b/Documentation/arch/powerpc/kvm-nested.rst @@ -546,7 +546,9 @@ table information. +--------+-------+----+--------+----------------------------------+ | 0x1052 | 0x08 | RW | T | CTRL | +--------+-------+----+--------+----------------------------------+ -| 0x1053-| | | | Reserved | +| 0x1053 | 0x08 | RW | T | DPDES | ++--------+-------+----+--------+----------------------------------+ +| 0x1054-| | | | Reserved | | 0x1FFF | | | | | +--------+-------+----+--------+----------------------------------+ | 0x2000 | 0x04 | RW | T | CR | diff --git a/arch/powerpc/include/asm/guest-state-buffer.h b/arch/powerpc/include/asm/guest-state-buffer.h index 808149f31576..d107abe1468f 100644 --- a/arch/powerpc/include/asm/guest-state-buffer.h +++ b/arch/powerpc/include/asm/guest-state-buffer.h @@ -81,6 +81,7 @@ #define KVMPPC_GSID_HASHKEYR 0x1050 #define KVMPPC_GSID_HASHPKEYR 0x1051 #define KVMPPC_GSID_CTRL 0x1052 +#define KVMPPC_GSID_DPDES 0x1053 #define KVMPPC_GSID_CR 0x2000 #define KVMPPC_GSID_PIDR 0x2001 @@ -110,7 +111,7 @@ #define KVMPPC_GSE_META_COUNT (KVMPPC_GSE_META_END - KVMPPC_GSE_META_START + 1) #define KVMPPC_GSE_DW_REGS_START KVMPPC_GSID_GPR(0) -#define KVMPPC_GSE_DW_REGS_END KVMPPC_GSID_CTRL +#define KVMPPC_GSE_DW_REGS_END KVMPPC_GSID_DPDES #define KVMPPC_GSE_DW_REGS_COUNT \ (KVMPPC_GSE_DW_REGS_END - KVMPPC_GSE_DW_REGS_START + 1) diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h index 3e1e2a698c9e..10618622d7ef 100644 --- a/arch/powerpc/include/asm/kvm_book3s.h +++ b/arch/powerpc/include/asm/kvm_book3s.h @@ -594,6 +594,7 @@ static inline u##size kvmppc_get_##reg(struct kvm_vcpu *vcpu) \ KVMPPC_BOOK3S_VCORE_ACCESSOR(vtb, 64, KVMPPC_GSID_VTB) +KVMPPC_BOOK3S_VCORE_ACCESSOR(dpdes, 64, KVMPPC_GSID_DPDES) KVMPPC_BOOK3S_VCORE_ACCESSOR_GET(arch_compat, 32, KVMPPC_GSID_LOGICAL_PVR) KVMPPC_BOOK3S_VCORE_ACCESSOR_GET(lpcr, 64, KVMPPC_GSID_LPCR) KVMPPC_BOOK3S_VCORE_ACCESSOR_SET(tb_offset, 64, KVMPPC_GSID_TB_OFFSET) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index 35cb014a0c51..cf285e5153ba 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -4116,6 +4116,11 @@ static int kvmhv_vcpu_entry_nestedv2(struct kvm_vcpu *vcpu, u64 time_limit, int trap; long rc; + if (vcpu->arch.doorbell_request) { + vcpu->arch.doorbell_request = 0; + kvmppc_set_dpdes(vcpu, 1); + } + io = &vcpu->arch.nestedv2_io; msr = mfmsr(); @@ -4278,9 +4283,16 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit, if (kvmhv_on_pseries()) { if (kvmhv_is_nestedv1()) trap = kvmhv_vcpu_entry_p9_nested(vcpu, time_limit, lpcr, tb); - else + else { trap = kvmhv_vcpu_entry_nestedv2(vcpu, time_limit, lpcr, tb); + /* Remember doorbell if it is pending */ + if (kvmppc_get_dpdes(vcpu)) { + vcpu->arch.doorbell_request = 1; + kvmppc_set_dpdes(vcpu, 0); + } + } + /* H_CEDE has to be handled now, not later */ if (trap == BOOK3S_INTERRUPT_SYSCALL && !nested && kvmppc_get_gpr(vcpu, 3) == H_CEDE) { diff --git a/arch/powerpc/kvm/book3s_hv_nestedv2.c b/arch/powerpc/kvm/book3s_hv_nestedv2.c index 8e6f5355f08b..36863fff2a99 100644 --- a/arch/powerpc/kvm/book3s_hv_nestedv2.c +++ b/arch/powerpc/kvm/book3s_hv_nestedv2.c @@ -311,6 +311,10 @@ static int gs_msg_ops_vcpu_fill_info(struct kvmppc_gs_buff *gsb, rc = kvmppc_gse_put_u64(gsb, iden, vcpu->arch.vcore->vtb); break; + case KVMPPC_GSID_DPDES: + rc = kvmppc_gse_put_u64(gsb, iden, + vcpu->arch.vcore->dpdes); + break; case KVMPPC_GSID_LPCR: rc = kvmppc_gse_put_u64(gsb, iden, vcpu->arch.vcore->lpcr); @@ -543,6 +547,9 @@ static int gs_msg_ops_vcpu_refresh_info(struct kvmppc_gs_msg *gsm, case KVMPPC_GSID_VTB: vcpu->arch.vcore->vtb = kvmppc_gse_get_u64(gse); break; + case KVMPPC_GSID_DPDES: + vcpu->arch.vcore->dpdes = kvmppc_gse_get_u64(gse); + break; case KVMPPC_GSID_LPCR: vcpu->arch.vcore->lpcr = kvmppc_gse_get_u64(gse); break; diff --git a/arch/powerpc/kvm/test-guest-state-buffer.c b/arch/powerpc/kvm/test-guest-state-buffer.c index 4720b8dc8837..91ae660cfe21 100644 --- a/arch/powerpc/kvm/test-guest-state-buffer.c +++ b/arch/powerpc/kvm/test-guest-state-buffer.c @@ -151,7 +151,7 @@ static void test_gs_bitmap(struct kunit *test) i++; } - for (u16 iden = KVMPPC_GSID_GPR(0); iden <= KVMPPC_GSID_CTRL; iden++) { + for (u16 iden = KVMPPC_GSID_GPR(0); iden <= KVMPPC_GSID_DPDES; iden++) { kvmppc_gsbm_set(&gsbm, iden); kvmppc_gsbm_set(&gsbm1, iden); KUNIT_EXPECT_TRUE(test, kvmppc_gsbm_test(&gsbm, iden)); -- 2.45.0

1 year

2
3
0 0

[PATCH] arm64: dts: rockchip: Fix the DCDC_REG2 minimum voltage on Quartz64 Model B

by Dragan Simic

Correct the specified regulator-min-microvolt value for the buck DCDC_REG2 regulator, which is part of the Rockchip RK809 PMIC, in the Pine64 Quartz64 Model B board dts. According to the RK809 datasheet, version 1.01, this regulator is capable of producing voltages as low as 0.5 V on its output, instead of going down to 0.9 V only, which is additionally confirmed by the regulator-min-microvolt values found in the board dts files for the other supported boards that use the same RK809 PMIC. This allows the DVFS to clock the GPU on the Quartz64 Model B below 700 MHz, all the way down to 200 MHz, which saves some power and reduces the amount of generated heat a bit, improving the thermal headroom and possibly improving the bursty CPU and GPU performance on this board. This also eliminates the following warnings in the kernel log: core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (200000000) core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (300000000) core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (400000000) core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (600000000) Fixes: dcc8c66bef79 ("arm64: dts: rockchip: add Pine64 Quartz64-B device tree") Cc: stable(a)vger.kernel.org Reported-By: Diederik de Haas <didi.debian(a)cknow.org> Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> --- arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts index 26322a358d91..b908ce006c26 100644 --- a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts +++ b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts @@ -289,7 +289,7 @@ vdd_gpu: DCDC_REG2 { regulator-name = "vdd_gpu"; regulator-always-on; regulator-boot-on; - regulator-min-microvolt = <900000>; + regulator-min-microvolt = <500000>; regulator-max-microvolt = <1350000>; regulator-ramp-delay = <6001>;

1 year

5
12
0 0

+ mm-vmalloc-fix-vbq-free-breakage.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/vmalloc: fix vbq->free breakage has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-vmalloc-fix-vbq-free-breakage.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: "hailong.liu" <hailong.liu(a)oppo.com> Subject: mm/vmalloc: fix vbq->free breakage Date: Thu, 30 May 2024 17:31:08 +0800 The function xa_for_each() in _vm_unmap_aliases() loops through all vbs. However, since commit 062eacf57ad9 ("mm: vmalloc: remove a global vmap_blocks xarray") the vb from xarray may not be on the corresponding CPU vmap_block_queue. Consequently, purge_fragmented_block() might use the wrong vbq->lock to protect the free list, leading to vbq->free breakage. Link: https://lkml.kernel.org/r/20240530093108.4512-1-hailong.liu@oppo.com Fixes: fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully utilized blocks") Signed-off-by: Hailong.Liu <liuhailong(a)oppo.com> Reported-by: Guangye Yang <guangye.yang(a)mediatek.com> Cc: Barry Song <21cnbao(a)gmail.com> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Gao Xiang <xiang(a)kernel.org> Cc: Guangye Yang <guangye.yang(a)mediatek.com> Cc: liuhailong <liuhailong(a)oppo.com> Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> Cc: Uladzislau Rezki (Sony) <urezki(a)gmail.com> Cc: Zhaoyang Huang <zhaoyang.huang(a)unisoc.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmalloc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/mm/vmalloc.c~mm-vmalloc-fix-vbq-free-breakage +++ a/mm/vmalloc.c @@ -2830,10 +2830,9 @@ static void _vm_unmap_aliases(unsigned l for_each_possible_cpu(cpu) { struct vmap_block_queue *vbq = &per_cpu(vmap_block_queue, cpu); struct vmap_block *vb; - unsigned long idx; rcu_read_lock(); - xa_for_each(&vbq->vmap_blocks, idx, vb) { + list_for_each_entry_rcu(vb, &vbq->free, free_list) { spin_lock(&vb->lock); /* _ Patches currently in -mm which might be from hailong.liu(a)oppo.com are mm-vmalloc-fix-vbq-free-breakage.patch

1 year

3
3
0 0

[PATCH 5.4.y] x86/mm: Remove broken vsyscall emulation code from the page fault code

by Guilherme G. Piccoli

From: Linus Torvalds <torvalds(a)linux-foundation.org> commit 02b670c1f88e78f42a6c5aee155c7b26960ca054 upstream. The syzbot-reported stack trace from hell in this discussion thread actually has three nested page faults: https://lore.kernel.org/r/000000000000d5f4fc0616e816d4@google.com ... and I think that's actually the important thing here: - the first page fault is from user space, and triggers the vsyscall emulation. - the second page fault is from __do_sys_gettimeofday(), and that should just have caused the exception that then sets the return value to -EFAULT - the third nested page fault is due to _raw_spin_unlock_irqrestore() -> preempt_schedule() -> trace_sched_switch(), which then causes a BPF trace program to run, which does that bpf_probe_read_compat(), which causes that page fault under pagefault_disable(). It's quite the nasty backtrace, and there's a lot going on. The problem is literally the vsyscall emulation, which sets current->thread.sig_on_uaccess_err = 1; and that causes the fixup_exception() code to send the signal *despite* the exception being caught. And I think that is in fact completely bogus. It's completely bogus exactly because it sends that signal even when it *shouldn't* be sent - like for the BPF user mode trace gathering. In other words, I think the whole "sig_on_uaccess_err" thing is entirely broken, because it makes any nested page-faults do all the wrong things. Now, arguably, I don't think anybody should enable vsyscall emulation any more, but this test case clearly does. I think we should just make the "send SIGSEGV" be something that the vsyscall emulation does on its own, not this broken per-thread state for something that isn't actually per thread. The x86 page fault code actually tried to deal with the "incorrect nesting" by having that: if (in_interrupt()) return; which ignores the sig_on_uaccess_err case when it happens in interrupts, but as shown by this example, these nested page faults do not need to be about interrupts at all. IOW, I think the only right thing is to remove that horrendously broken code. The attached patch looks like the ObviouslyCorrect(tm) thing to do. NOTE! This broken code goes back to this commit in 2011: 4fc3490114bb ("x86-64: Set siginfo and context on vsyscall emulation faults") ... and back then the reason was to get all the siginfo details right. Honestly, I do not for a moment believe that it's worth getting the siginfo details right here, but part of the commit says: This fixes issues with UML when vsyscall=emulate. ... and so my patch to remove this garbage will probably break UML in this situation. I do not believe that anybody should be running with vsyscall=emulate in 2024 in the first place, much less if you are doing things like UML. But let's see if somebody screams. Reported-and-tested-by: syzbot+83e7f982ca045ab4405c(a)syzkaller.appspotmail.com Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Tested-by: Jiri Olsa <jolsa(a)kernel.org> Acked-by: Andy Lutomirski <luto(a)kernel.org> Link: https://lore.kernel.org/r/CAHk-=wh9D6f7HUkDgZHKmDCHUQmp+Co89GP+b8+z+G56BKey… Signed-off-by: Sasha Levin <sashal(a)kernel.org> [gpiccoli: Backport the patch due to differences in the trees. The main changes between 5.4.y and 5.15.y are due to renaming the fixup function, by commit 6456a2a69ee1 ("x86/fault: Rename no_context() to kernelmode_fixup_or_oops()"), and on processor.h thread_struct due to commit cf122cfba5b1 ("kill uaccess_try()"). Following 2 commits cause divergence in the diffs too (in the removed lines): cd072dab453a ("x86/fault: Add a helper function to sanitize error code") d4ffd5df9d18 ("x86/fault: Fix wrong signal when vsyscall fails with pkey").] Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)igalia.com> --- Hi folks, this was backported by AUTOSEL up to 5.15.y; I'm manually submitting the backport to 5.4.y and 5.10.y. I've detailed a bit the changes necessary due to other nonrelated missing patches, but these are really simple and non-intrusive. Nevertheless, I've explicitely CCed x86 ML to be sure the maintainers are aware of the backport, and if anybody thinks we shouldn't do it for these (very) old releases, please respond here. Cheers, Guilherme arch/x86/entry/vsyscall/vsyscall_64.c | 28 ++------------------------- arch/x86/include/asm/processor.h | 1 - arch/x86/mm/fault.c | 27 +------------------------- 3 files changed, 3 insertions(+), 53 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c index e7c596dea947..86e5a1c1055f 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -98,11 +98,6 @@ static int addr_to_vsyscall_nr(unsigned long addr) static bool write_ok_or_segv(unsigned long ptr, size_t size) { - /* - * XXX: if access_ok, get_user, and put_user handled - * sig_on_uaccess_err, this could go away. - */ - if (!access_ok((void __user *)ptr, size)) { struct thread_struct *thread = &current->thread; @@ -120,10 +115,8 @@ static bool write_ok_or_segv(unsigned long ptr, size_t size) bool emulate_vsyscall(unsigned long error_code, struct pt_regs *regs, unsigned long address) { - struct task_struct *tsk; unsigned long caller; int vsyscall_nr, syscall_nr, tmp; - int prev_sig_on_uaccess_err; long ret; unsigned long orig_dx; @@ -172,8 +165,6 @@ bool emulate_vsyscall(unsigned long error_code, goto sigsegv; } - tsk = current; - /* * Check for access_ok violations and find the syscall nr. * @@ -233,12 +224,8 @@ bool emulate_vsyscall(unsigned long error_code, goto do_ret; /* skip requested */ /* - * With a real vsyscall, page faults cause SIGSEGV. We want to - * preserve that behavior to make writing exploits harder. + * With a real vsyscall, page faults cause SIGSEGV. */ - prev_sig_on_uaccess_err = current->thread.sig_on_uaccess_err; - current->thread.sig_on_uaccess_err = 1; - ret = -EFAULT; switch (vsyscall_nr) { case 0: @@ -261,23 +248,12 @@ bool emulate_vsyscall(unsigned long error_code, break; } - current->thread.sig_on_uaccess_err = prev_sig_on_uaccess_err; - check_fault: if (ret == -EFAULT) { /* Bad news -- userspace fed a bad pointer to a vsyscall. */ warn_bad_vsyscall(KERN_INFO, regs, "vsyscall fault (exploit attempt?)"); - - /* - * If we failed to generate a signal for any reason, - * generate one here. (This should be impossible.) - */ - if (WARN_ON_ONCE(!sigismember(&tsk->pending.signal, SIGBUS) && - !sigismember(&tsk->pending.signal, SIGSEGV))) - goto sigsegv; - - return true; /* Don't emulate the ret. */ + goto sigsegv; } regs->ax = ret; diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 9cbd86cf0deb..087df5edef78 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -487,7 +487,6 @@ struct thread_struct { mm_segment_t addr_limit; - unsigned int sig_on_uaccess_err:1; unsigned int uaccess_err:1; /* uaccess failed */ /* Floating point and extended processor state */ diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index c494c8c05824..21383ef7b506 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -743,33 +743,8 @@ no_context(struct pt_regs *regs, unsigned long error_code, } /* Are we prepared to handle this kernel fault? */ - if (fixup_exception(regs, X86_TRAP_PF, error_code, address)) { - /* - * Any interrupt that takes a fault gets the fixup. This makes - * the below recursive fault logic only apply to a faults from - * task context. - */ - if (in_interrupt()) - return; - - /* - * Per the above we're !in_interrupt(), aka. task context. - * - * In this case we need to make sure we're not recursively - * faulting through the emulate_vsyscall() logic. - */ - if (current->thread.sig_on_uaccess_err && signal) { - set_signal_archinfo(address, error_code); - - /* XXX: hwpoison faults will set the wrong code. */ - force_sig_fault(signal, si_code, (void __user *)address); - } - - /* - * Barring that, we can do the fixup and be happy. - */ + if (fixup_exception(regs, X86_TRAP_PF, error_code, address)) return; - } #ifdef CONFIG_VMAP_STACK /* -- 2.45.1

1 year

1
0
0 0

[PATCH v2] iio: imu: inv_mpu6050: stabilized timestamping in interrupt

by inv.git-commit＠tdk.com

From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> Use IRQ ONESHOT flag to ensure the timestamp is not updated in the hard handler during the thread handler. And use a fixed value of 1 sample that correspond to this first timestamp. This way we can ensure the timestamp is always corresponding to the value used by the timestamping mechanism. Otherwise, it is possible that between FIFO count read and FIFO processing the timestamp is overwritten in the hard handler. Fixes: 111e1abd0045 ("iio: imu: inv_mpu6050: use the common inv_sensors timestamp module") Cc: stable(a)vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> --- drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 4 ++-- drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c index 0dc0f22a5582..3d3b27f28c9d 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c @@ -100,8 +100,8 @@ irqreturn_t inv_mpu6050_read_fifo(int irq, void *p) goto end_session; /* Each FIFO data contains all sensors, so same number for FIFO and sensor data */ fifo_period = NSEC_PER_SEC / INV_MPU6050_DIVIDER_TO_FIFO_RATE(st->chip_config.divider); - inv_sensors_timestamp_interrupt(&st->timestamp, nb, pf->timestamp); - inv_sensors_timestamp_apply_odr(&st->timestamp, fifo_period, nb, 0); + inv_sensors_timestamp_interrupt(&st->timestamp, 1, pf->timestamp); + inv_sensors_timestamp_apply_odr(&st->timestamp, fifo_period, 1, 0); /* clear internal data buffer for avoiding kernel data leak */ memset(data, 0, sizeof(data)); diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c index 1b603567ccc8..84273660ca2e 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c @@ -300,6 +300,7 @@ int inv_mpu6050_probe_trigger(struct iio_dev *indio_dev, int irq_type) if (!st->trig) return -ENOMEM; + irq_type |= IRQF_ONESHOT; ret = devm_request_threaded_irq(&indio_dev->dev, st->irq, &inv_mpu6050_interrupt_timestamp, &inv_mpu6050_interrupt_handle, -- 2.34.1

1 year

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024