April 2024 - Linux-stable-mirror

[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

5 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);

5 months, 3 weeks

4
4
0 0

[PATCH v4 0/5] Pinephone video out fixes (flipping between two frames)

by Frank Oltmanns

On some pinephones the video output sometimes freezes (flips between two frames) [1]. It seems to be that the reason for this behaviour is that PLL-MIPI is outside its limits, and the GPU is not running at a fixed rate. In this patch series I propose the following changes: 1. sunxi-ng: Adhere to the following constraints given in the Allwinner A64 Manual regarding PLL-MIPI: * M/N <= 3 * (PLL_VIDEO0)/M >= 24MHz * 500MHz <= clockrate <= 1400MHz 2. Remove two operating points from the A64 DTS OPPs, so that the GPU runs at a fixed rate of 432 MHz. Note, that when pinning the GPU to 432 MHz the issue [1] completely disappears for me. I've searched the BSP and could not find any indication that supports the idea of having the three OPPs. The only frequency I found in the BPSs for A64 is 432 MHz, which has also proven stable for me. I very much appreciate your feedback! [1] https://gitlab.com/postmarketOS/pmaports/-/issues/805 Signed-off-by: Frank Oltmanns <frank(a)oltmanns.dev> --- Changes in v4: - sunxi-ng: common: Address review comments. - Link to v3: https://lore.kernel.org/r/20240304-pinephone-pll-fixes-v3-0-94ab828f269a@ol… Changes in v3: - dts: Pin GPU to 432 MHz. - nkm and a64: Move minimum and maximum rate handling to the common part of the sunxi-ng driver. - Removed st7703 patch from series. - Link to v2: https://lore.kernel.org/r/20240205-pinephone-pll-fixes-v2-0-96a46a2d8c9b@ol… Changes in v2: - dts: Increase minimum GPU frequency to 192 MHz. - nkm and a64: Add minimum and maximum rate for PLL-MIPI. - nkm: Use the same approach for skipping invalid rates in ccu_nkm_find_best() as in ccu_nkm_find_best_with_parent_adj(). - nkm: Improve names for ratio struct members and hence get rid of describing comments. - nkm and a64: Correct description in the commit messages: M/N <= 3 - Remove patches for nm as they were not needed. - st7703: Rework the commit message to cover more background for the change. - Link to v1: https://lore.kernel.org/r/20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@ol… --- Frank Oltmanns (5): clk: sunxi-ng: common: Support minimum and maximum rate clk: sunxi-ng: a64: Set minimum and maximum rate for PLL-MIPI clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and parent rate arm64: dts: allwinner: a64: Run GPU at 432 MHz arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 -------- drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +++++++++----- drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++ drivers/clk/sunxi-ng/ccu_common.h | 3 +++ drivers/clk/sunxi-ng/ccu_nkm.c | 21 +++++++++++++++++++++ drivers/clk/sunxi-ng/ccu_nkm.h | 2 ++ 6 files changed, 54 insertions(+), 13 deletions(-) --- base-commit: dcb6c8ee6acc6c347caec1e73fb900c0f4ff9806 change-id: 20231218-pinephone-pll-fixes-0ccdfde273e4 Best regards, -- Frank Oltmanns <frank(a)oltmanns.dev>

6 months

9
20
0 0

[PATCH v1] pmdomain: imx8m-blk-ctrl: fix suspend/resume order

by Vitor Soares

From: Vitor Soares <vitor.soares(a)toradex.com> During the probe, the genpd power_dev is added to the dpm_list after blk_ctrl due to its parent/child relationship. Making the blk_ctrl suspend after and resume before the genpd power_dev. As a consequence, the system hangs when resuming the VPU due to the power domain dependency. To ensure the proper suspend/resume order, add a device link betweem blk_ctrl and genpd power_dev. It guarantees genpd power_dev is suspended after and resumed before blk-ctrl. Cc: <stable(a)vger.kernel.org> Closes: https://lore.kernel.org/all/fccbb040330a706a4f7b34875db1d896a0bf81c8.camel@… Link: https://lore.kernel.org/all/20240409085802.290439-1-ivitro@gmail.com/ Fixes: 2684ac05a8c4 ("soc: imx: add i.MX8M blk-ctrl driver") Suggested-by: Lucas Stach <l.stach(a)pengutronix.de> Signed-off-by: Vitor Soares <vitor.soares(a)toradex.com> --- This is a new patch, but is a follow-up of: https://lore.kernel.org/all/20240409085802.290439-1-ivitro@gmail.com/ As suggested by Lucas, we are addressing this PM issue in the imx8m-blk-ctrl driver instead of in the imx8mm.dtsi. drivers/pmdomain/imx/imx8m-blk-ctrl.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/pmdomain/imx/imx8m-blk-ctrl.c b/drivers/pmdomain/imx/imx8m-blk-ctrl.c index ca942d7929c2..cd0d2296080d 100644 --- a/drivers/pmdomain/imx/imx8m-blk-ctrl.c +++ b/drivers/pmdomain/imx/imx8m-blk-ctrl.c @@ -283,6 +283,20 @@ static int imx8m_blk_ctrl_probe(struct platform_device *pdev) goto cleanup_pds; } + /* + * Enforce suspend/resume ordering by making genpd power_dev a + * provider of blk-ctrl. Genpd power_dev is suspended after and + * resumed before blk-ctrl. + */ + if (!device_link_add(dev, domain->power_dev, DL_FLAG_STATELESS)) { + ret = -EINVAL; + dev_err_probe(dev, ret, + "failed to link to %s\n", data->name); + pm_genpd_remove(&domain->genpd); + dev_pm_domain_detach(domain->power_dev, true); + goto cleanup_pds; + } + /* * We use runtime PM to trigger power on/off of the upstream GPC * domain, as a strict hierarchical parent/child power domain @@ -324,6 +338,7 @@ static int imx8m_blk_ctrl_probe(struct platform_device *pdev) of_genpd_del_provider(dev->of_node); cleanup_pds: for (i--; i >= 0; i--) { + device_link_remove(dev, bc->domains[i].power_dev); pm_genpd_remove(&bc->domains[i].genpd); dev_pm_domain_detach(bc->domains[i].power_dev, true); } @@ -343,6 +358,7 @@ static void imx8m_blk_ctrl_remove(struct platform_device *pdev) for (i = 0; bc->onecell_data.num_domains; i++) { struct imx8m_blk_ctrl_domain *domain = &bc->domains[i]; + device_link_remove(&pdev->dev, domain->power_dev); pm_genpd_remove(&domain->genpd); dev_pm_domain_detach(domain->power_dev, true); } -- 2.34.1

6 months

6
7
0 0

FAILED: patch "[PATCH] iommu/dma: Trace bounce buffer usage when mapping buffers" 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 a63c357b9fd56ad5fe64616f5b22835252c6a76a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024012226-unmanned-marshy-5819@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: a63c357b9fd5 ("iommu/dma: Trace bounce buffer usage when mapping buffers") f316ba0a8814 ("dma-iommu: Check that swiotlb is active before trying to use it") a17e3026bc4d ("iommu: Move flush queue data into iommu_dma_cookie") f7f07484542f ("iommu/iova: Move flush queue code to iommu-dma") ea4d71bb5e3f ("iommu/iova: Consolidate flush queue code") 87f60cc65d24 ("iommu/vt-d: Use put_pages_list") 649ad9835a37 ("iommu/iova: Squash flush_cb abstraction") d5c383f2c98a ("iommu/iova: Squash entry_dtor abstraction") d7061627d701 ("iommu/iova: Fix race between FQ timeout and teardown") 2e727bffbe93 ("iommu/dma: Check CONFIG_SWIOTLB more broadly") 9b49bbc2c4df ("iommu/dma: Fold _swiotlb helpers into callers") ee9d4097cc14 ("iommu/dma: Skip extra sync during unmap w/swiotlb") 06e620345d54 ("iommu/dma: Fix arch_sync_dma for map") 08ae5d4a1ae9 ("iommu/dma: Fix sync_sg with swiotlb") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a63c357b9fd56ad5fe64616f5b22835252c6a76a Mon Sep 17 00:00:00 2001 From: "Isaac J. Manjarres" <isaacmanjarres(a)google.com> Date: Fri, 8 Dec 2023 15:41:40 -0800 Subject: [PATCH] iommu/dma: Trace bounce buffer usage when mapping buffers When commit 82612d66d51d ("iommu: Allow the dma-iommu api to use bounce buffers") was introduced, it did not add the logic for tracing the bounce buffer usage from iommu_dma_map_page(). All of the users of swiotlb_tbl_map_single() trace their bounce buffer usage, except iommu_dma_map_page(). This makes it difficult to track SWIOTLB usage from that function. Thus, trace bounce buffer usage from iommu_dma_map_page(). Fixes: 82612d66d51d ("iommu: Allow the dma-iommu api to use bounce buffers") Cc: stable(a)vger.kernel.org # v5.15+ Cc: Tom Murphy <murphyt7(a)tcd.ie> Cc: Lu Baolu <baolu.lu(a)linux.intel.com> Cc: Saravana Kannan <saravanak(a)google.com> Signed-off-by: Isaac J. Manjarres <isaacmanjarres(a)google.com> Link: https://lore.kernel.org/r/20231208234141.2356157-1-isaacmanjarres@google.com Signed-off-by: Joerg Roedel <jroedel(a)suse.de> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index 85163a83df2f..037fcf826407 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -29,6 +29,7 @@ #include <linux/spinlock.h> #include <linux/swiotlb.h> #include <linux/vmalloc.h> +#include <trace/events/swiotlb.h> #include "dma-iommu.h" @@ -1156,6 +1157,8 @@ static dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page, return DMA_MAPPING_ERROR; } + trace_swiotlb_bounced(dev, phys, size); + aligned_size = iova_align(iovad, size); phys = swiotlb_tbl_map_single(dev, phys, size, aligned_size, iova_mask(iovad), dir, attrs);

6 months, 1 week

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

6 months, 2 weeks

4
4
0 0

[PATCH] riscv: fix overlap of allocated page and PTR_ERR

by Nam Cao

On riscv32, it is possible for the last page in virtual address space (0xfffff000) to be allocated. This page overlaps with PTR_ERR, so that shouldn't happen. There is already some code to ensure memblock won't allocate the last page. However, buddy allocator is left unchecked. Fix this by reserving physical memory that would be mapped at virtual addresses greater than 0xfffff000. Reported-by: Björn Töpel <bjorn(a)kernel.org> Closes: https://lore.kernel.org/linux-riscv/878r1ibpdn.fsf@all.your.base.are.belong… Fixes: 76d2a0493a17 ("RISC-V: Init and Halt Code") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Cc: <stable(a)vger.kernel.org> --- arch/riscv/mm/init.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 968761843203..7c985435b3fc 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -235,18 +235,19 @@ static void __init setup_bootmem(void) kernel_map.va_pa_offset = PAGE_OFFSET - phys_ram_base; /* - * memblock allocator is not aware of the fact that last 4K bytes of - * the addressable memory can not be mapped because of IS_ERR_VALUE - * macro. Make sure that last 4k bytes are not usable by memblock - * if end of dram is equal to maximum addressable memory. For 64-bit - * kernel, this problem can't happen here as the end of the virtual - * address space is occupied by the kernel mapping then this check must - * be done as soon as the kernel mapping base address is determined. + * Reserve physical address space that would be mapped to virtual + * addresses greater than (void *)(-PAGE_SIZE) because: + * - This memory would overlap with ERR_PTR + * - This memory belongs to high memory, which is not supported + * + * This is not applicable to 64-bit kernel, because virtual addresses + * after (void *)(-PAGE_SIZE) are not linearly mapped: they are + * occupied by kernel mapping. Also it is unrealistic for high memory + * to exist on 64-bit platforms. */ if (!IS_ENABLED(CONFIG_64BIT)) { - max_mapped_addr = __pa(~(ulong)0); - if (max_mapped_addr == (phys_ram_end - 1)) - memblock_set_current_limit(max_mapped_addr - 4096); + max_mapped_addr = __va_to_pa_nodebug(-PAGE_SIZE); + memblock_reserve(max_mapped_addr, (phys_addr_t)-max_mapped_addr); } min_low_pfn = PFN_UP(phys_ram_base); -- 2.39.2

6 months, 3 weeks

4
3
0 0

[RESEND PATCH] perf/x86/intel/uncore: Fix the bits of the CHA extended umask for SPR

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> The perf stat errors out with UNC_CHA_TOR_INSERTS.IA_HIT_CXL_ACC_LOCAL event. $perf stat -e uncore_cha_55/event=0x35,umask=0x10c0008101/ -a -- ls event syntax error: '..0x35,umask=0x10c0008101/' \___ Bad event or PMU The definition of the CHA umask is config:8-15,32-55, which is 32bit. However, the umask of the event is bigger than 32bit. This is an error in the original uncore spec. Add a new umask_ext5 for the new CHA umask range. Fixes: 949b11381f81 ("perf/x86/intel/uncore: Add Sapphire Rapids server CHA support") Closes: https://lore.kernel.org/linux-perf-users/alpine.LRH.2.20.2401300733310.1135… Reviewed-by: Ian Rogers <irogers(a)google.com> Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- arch/x86/events/intel/uncore_snbep.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c index a96496bef678..7924f315269a 100644 --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -461,6 +461,7 @@ #define SPR_UBOX_DID 0x3250 /* SPR CHA */ +#define SPR_CHA_EVENT_MASK_EXT 0xffffffff #define SPR_CHA_PMON_CTL_TID_EN (1 << 16) #define SPR_CHA_PMON_EVENT_MASK (SNBEP_PMON_RAW_EVENT_MASK | \ SPR_CHA_PMON_CTL_TID_EN) @@ -477,6 +478,7 @@ DEFINE_UNCORE_FORMAT_ATTR(umask_ext, umask, "config:8-15,32-43,45-55"); DEFINE_UNCORE_FORMAT_ATTR(umask_ext2, umask, "config:8-15,32-57"); DEFINE_UNCORE_FORMAT_ATTR(umask_ext3, umask, "config:8-15,32-39"); DEFINE_UNCORE_FORMAT_ATTR(umask_ext4, umask, "config:8-15,32-55"); +DEFINE_UNCORE_FORMAT_ATTR(umask_ext5, umask, "config:8-15,32-63"); DEFINE_UNCORE_FORMAT_ATTR(qor, qor, "config:16"); DEFINE_UNCORE_FORMAT_ATTR(edge, edge, "config:18"); DEFINE_UNCORE_FORMAT_ATTR(tid_en, tid_en, "config:19"); @@ -5957,7 +5959,7 @@ static struct intel_uncore_ops spr_uncore_chabox_ops = { static struct attribute *spr_uncore_cha_formats_attr[] = { &format_attr_event.attr, - &format_attr_umask_ext4.attr, + &format_attr_umask_ext5.attr, &format_attr_tid_en2.attr, &format_attr_edge.attr, &format_attr_inv.attr, @@ -5993,7 +5995,7 @@ ATTRIBUTE_GROUPS(uncore_alias); static struct intel_uncore_type spr_uncore_chabox = { .name = "cha", .event_mask = SPR_CHA_PMON_EVENT_MASK, - .event_mask_ext = SPR_RAW_EVENT_MASK_EXT, + .event_mask_ext = SPR_CHA_EVENT_MASK_EXT, .num_shared_regs = 1, .constraints = skx_uncore_chabox_constraints, .ops = &spr_uncore_chabox_ops, -- 2.35.1

6 months, 4 weeks

2
1
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); }

7 months

4
3
0 0

backport a patch for Linux kernel-5.10 and 6.6 stable tree

by Lin Gui (桂林)

Hi reviewers, I suggest to backport a commit to Linux kernel-5.10 and 6.6 stable tree. 　　https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/d… author Lin Gui lin.gui(a)mediatek.com 2023-12-19 07:05:32 +0800 committer Ulf Hansson ulf.hansson(a)linaro.org 2024-01-02 17:54:05 +0100 commit e4df56ad0bf3506c5189abb9be83f3bea05a4c4f (patch) tree a5db3a85f44b29dd773c5c65c3340d50b74b6687 /drivers/mmc/core/mmc.c parent b062136d0d6f46d7ad5c88219cbd75f90cb18e81 (diff) download linux-e4df56ad0bf3506c5189abb9be83f3bea05a4c4f.tar.gz mmc: core: Add wp_grp_size sysfs node The eMMC card can be set into write-protected mode to prevent data from being accidentally modified or deleted. Wp_grp_size (Write Protect Group Size) refers to an attribute of the eMMC card, used to manage write protection and is the CSD register [36:32] of the eMMC device. Wp_grp_size (Write Protect Group Size) indicates how many eMMC blocks are contained in each write protection group on the eMMC card. To allow userspace easy access of the CSD register bits, let's add sysfs node "wp_grp_size". Signed-off-by: Lin Gui lin.gui(a)mediatek.com Signed-off-by: Bo Ye bo.ye(a)mediatek.com Reviewed-by: AngeloGioacchino Del Regno angelogioacchino.delregno(a)collabora.com Link: https://lore.kernel.org/r/20231218230532.82427-1-bo.ye@mediatek.com Signed-off-by: Ulf Hansson ulf.hansson(a)linaro.org ------------------------------------ Best Regards ！ Guilin ===================================== MediaTek(ChengDu)Inc. Email: mailto:lin.gui@mediatek.com tel:+86-28-85939000-67009 Fax:+86-28-85929875 ==============================================

7 months

3
5
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024