mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

May 2024

  • 87 participants
  • 1364 discussions
[PATCH OLK-6.6 0/2] add new kvm_type for Confidential VMs
by Ju Fu 16 May '24

16 May '24
add new kvm_type for Confidential VMs: 1. kvm: add macro CONFIG_CVM_HOST to defconfig 2. kvm: add new kvm_type for cvm arch/arm64/configs/defconfig | 1 + arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/kvm_host.h | 12 ++++ arch/arm64/include/asm/kvm_tmm.h | 93 ++++++++++++++++++++++++++ arch/arm64/kvm/Kconfig | 9 +++ include/uapi/linux/kvm.h | 17 +++++ 6 files changed, 133 insertions(+) create mode 100644 arch/arm64/include/asm/kvm_tmm.h -- 2.25.1.windows.1
2 3
0 0
[PATCH openEuler-1.0-LTS] x86/CPU/AMD: Update the Zenbleed microcode revisions
by Yang Yingliang 16 May '24

16 May '24
From: "Borislav Petkov (AMD)" <bp(a)alien8.de> mainline inclusion from mainline-v6.9-rc1 commit 5c84b051bd4e777cf37aaff983277e58c99618d5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9NZ3E Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Update them to the correct revision numbers. Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix") Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: <stable(a)kernel.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- arch/x86/kernel/cpu/amd.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 27c545a5dc39..0b389735cb71 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -908,11 +908,11 @@ static bool cpu_has_zenbleed_microcode(void) u32 good_rev = 0; switch (boot_cpu_data.x86_model) { - case 0x30 ... 0x3f: good_rev = 0x0830107a; break; - case 0x60 ... 0x67: good_rev = 0x0860010b; break; - case 0x68 ... 0x6f: good_rev = 0x08608105; break; - case 0x70 ... 0x7f: good_rev = 0x08701032; break; - case 0xa0 ... 0xaf: good_rev = 0x08a00008; break; + case 0x30 ... 0x3f: good_rev = 0x0830107b; break; + case 0x60 ... 0x67: good_rev = 0x0860010c; break; + case 0x68 ... 0x6f: good_rev = 0x08608107; break; + case 0x70 ... 0x7f: good_rev = 0x08701033; break; + case 0xa0 ... 0xaf: good_rev = 0x08a00009; break; default: return false; -- 2.25.1
2 1
0 0
[PATCH OLK-5.10] x86/CPU/AMD: Update the Zenbleed microcode revisions
by Yang Yingliang 16 May '24

16 May '24
From: "Borislav Petkov (AMD)" <bp(a)alien8.de> mainline inclusion from mainline-v6.9-rc1 commit 5c84b051bd4e777cf37aaff983277e58c99618d5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9NZ3E Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Update them to the correct revision numbers. Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix") Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: <stable(a)kernel.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- arch/x86/kernel/cpu/amd.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index f9cbb25c55d3..688c9ca69852 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1040,11 +1040,11 @@ static bool cpu_has_zenbleed_microcode(void) u32 good_rev = 0; switch (boot_cpu_data.x86_model) { - case 0x30 ... 0x3f: good_rev = 0x0830107a; break; - case 0x60 ... 0x67: good_rev = 0x0860010b; break; - case 0x68 ... 0x6f: good_rev = 0x08608105; break; - case 0x70 ... 0x7f: good_rev = 0x08701032; break; - case 0xa0 ... 0xaf: good_rev = 0x08a00008; break; + case 0x30 ... 0x3f: good_rev = 0x0830107b; break; + case 0x60 ... 0x67: good_rev = 0x0860010c; break; + case 0x68 ... 0x6f: good_rev = 0x08608107; break; + case 0x70 ... 0x7f: good_rev = 0x08701033; break; + case 0xa0 ... 0xaf: good_rev = 0x08a00009; break; default: return false; -- 2.25.1
2 1
0 0
[PATCH OLK-6.6 V1] sched/fair: limit burst to zero when cfs bandwidth is toggled off
by Cheng Yu 16 May '24

16 May '24
From: Zhao Wenhui <zhaowenhui8(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9PR8C CVE: NA -------------------------------- sched/fair: limit burst to zero when cfs bandwidth is toggled off When the quota value in CFS bandwidth is set to -1, that imples the cfs bandwidth is toggled off. So the burst feature is supposed to be disable as well. Currently, when quota is -1, burst will not be check, so that it can be set to almost arbitery value. Examples: mkdir /sys/fs/cgroup/cpu/test echo -1 > /sys/fs/cgroup/cpu/test/cpu.cfs_quota_us echo 10000000000000000 > /sys/fs/cgroup/cpu/test/cpu.cfs_burst_us Moreover, after the burst modified by this way, quota can't be set to any value: echo 100000 > cpu.cfs_quota_us -bash: echo: write error: Invalid argument This patch can ensure the burst value being zero and unalterable, when quota is set to -1. Fixes: f4183717b370 ("sched/fair: Introduce the burstable CFS controller") Signed-off-by: Zhao Wenhui <zhaowenhui8(a)huawei.com> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- kernel/sched/core.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 9e7a99947de6..5441afe18953 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -11051,6 +11051,12 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota, burst + quota > max_cfs_runtime)) return -EINVAL; + /* + * Ensure burst equals to zero when quota is -1. + */ + if (quota == RUNTIME_INF && burst) + return -EINVAL; + /* * Prevent race between setting of cfs_rq->runtime_enabled and * unthrottle_offline_cfs_rqs(). @@ -11110,8 +11116,10 @@ static int tg_set_cfs_quota(struct task_group *tg, long cfs_quota_us) period = ktime_to_ns(tg->cfs_bandwidth.period); burst = tg->cfs_bandwidth.burst; - if (cfs_quota_us < 0) + if (cfs_quota_us < 0) { quota = RUNTIME_INF; + burst = 0; + } else if ((u64)cfs_quota_us <= U64_MAX / NSEC_PER_USEC) quota = (u64)cfs_quota_us * NSEC_PER_USEC; else -- 2.25.1
3 2
0 0
[PATCH OLK-5.10] ip: Treat IPv4 segment's lowest address as unicast
by Liu Jian 16 May '24

16 May '24
From: Seth David Schoen <schoen(a)loyalty.org> mainline inclusion from mainline-v5.14-rc1 commit 94c821c74bf5fe0c25e09df5334a16f98608db90 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I65HYE Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Treat only the highest, not the lowest, IPv4 address within a local subnet as a broadcast address. Signed-off-by: Seth David Schoen <schoen(a)loyalty.org> Suggested-by: John Gilmore <gnu(a)toad.com> Acked-by: Dave Taht <dave.taht(a)gmail.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Conflicts: net/ipv4/fib_frontend.c [There is no conflict when cherry-picking. But we backport newer commit 0c51e12e218f2 causing the checkconflict CI fail.] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ipv4/fib_frontend.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c index 41f890bf9d4c..efe143885995 100644 --- a/net/ipv4/fib_frontend.c +++ b/net/ipv4/fib_frontend.c @@ -1132,10 +1132,8 @@ void fib_add_ifaddr(struct in_ifaddr *ifa) prefix, ifa->ifa_prefixlen, prim, ifa->ifa_rt_priority); - /* Add network specific broadcasts, when it takes a sense */ + /* Add the network broadcast address, when it makes sense */ if (ifa->ifa_prefixlen < 31) { - fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix, 32, - prim, 0); fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix | ~mask, 32, prim, 0); arp_invalidate(dev, prefix | ~mask, false); -- 2.34.1
2 1
0 0
[PATCH OLK-5.10] iommu/arm-smmu-v3: Reducing the CMD_SYNC times for errata
by Zhang Zekun 16 May '24

16 May '24
Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9G9TI ------------------------------------------------------ Benifiting from the hardware same address blocking mechanism. We only need to send the CMD_SYNC in the granual of the level 3 pagetable block size, this can greatly reduce the amounts of CMD_SYNC times sent to avoiding the errata. Detecting the hardware ability by read the SMMU_USER_CONFIG1. Also, We don't have to send a tlbi before a CMD_SYNC, It will be OK for the hardware to merge the CMD_SYNC. Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 48 ++++++++++++++++----- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 3 ++ 2 files changed, 41 insertions(+), 10 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 423a54b7611d..6946d79fc7b9 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -859,7 +859,9 @@ static int arm_smmu_ecmdq_issue_cmdlist(struct arm_smmu_device *smmu, } while (1); /* 2. Write our commands into the queue */ - arm_smmu_cmdq_write_entries(cmdq, cmds, llq.prod, n); + if (cmds) + arm_smmu_cmdq_write_entries(cmdq, cmds, llq.prod, n); + if (sync) { u64 cmd_sync[CMDQ_ENT_DWORDS]; @@ -963,7 +965,8 @@ static int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu, * 2. Write our commands into the queue * Dependency ordering from the cmpxchg() loop above. */ - arm_smmu_cmdq_write_entries(cmdq, cmds, llq.prod, n); + if (cmds) + arm_smmu_cmdq_write_entries(cmdq, cmds, llq.prod, n); if (sync) { prod = queue_inc_prod_n(&llq, n); arm_smmu_cmdq_build_sync_cmd(cmd_sync, smmu, &cmdq->q, prod); @@ -2946,15 +2949,21 @@ static void arm_smmu_iotlb_sync_map(struct iommu_domain *domain, unsigned long iova, size_t size) { struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); - size_t granule_size; + struct arm_smmu_device *smmu = smmu_domain->smmu; if (!(smmu_domain->smmu->options & ARM_SMMU_OPT_SYNC_MAP)) return; - granule_size = 1 << __ffs(smmu_domain->domain.pgsize_bitmap); + if (smmu_domain->smmu->options & ARM_SMMU_OPT_SYNC_BATCH) { + int pg_shift; + + pg_shift = __ffs(smmu_domain->domain.pgsize_bitmap); + if (likely(iova % (1 << (2 * pg_shift - 3)))) + return; + } /* Add a SYNC command to sync io-pgtale to avoid errors in pgtable prefetch*/ - arm_smmu_tlb_inv_range_domain(iova, granule_size, granule_size, true, smmu_domain); + arm_smmu_cmdq_issue_cmdlist(smmu, NULL, 0, true); } #endif @@ -4932,6 +4941,29 @@ static void arm_smmu_get_httu(struct arm_smmu_device *smmu, u32 reg) fw_features); } +#ifdef CONFIG_HISILICON_ERRATUM_162100602 +static void hisi_smmu_check_errata(struct arm_smmu_device *smmu) +{ + u32 reg, i; + + /* IIDR */ + reg = readl_relaxed(smmu->base + ARM_SMMU_IIDR); + if (!(FIELD_GET(IIDR_VARIANT, reg) == 0x3) || + !(FIELD_GET(IIDR_REVISON, reg) == 0x2)) + return; + + smmu->options |= ARM_SMMU_OPT_SYNC_MAP; + + reg = readl_relaxed(smmu->base + ARM_SMMU_USER_CFG1); + reg = reg & GENMASK(15, 0); + for (i = 0; i < 8; i++) { + if (!(reg && (GENMASK(1, 0) << 2 * i))) + return; + } + smmu->options |= ARM_SMMU_OPT_SYNC_BATCH; +} +#endif + static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) { u32 reg; @@ -5163,11 +5195,7 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) } #ifdef CONFIG_HISILICON_ERRATUM_162100602 - /* IIDR */ - reg = readl_relaxed(smmu->base + ARM_SMMU_IIDR); - if (FIELD_GET(IIDR_VARIANT, reg) == 0x3 && - FIELD_GET(IIDR_REVISON, reg) == 0x2) - smmu->options |= ARM_SMMU_OPT_SYNC_MAP; + hisi_smmu_check_errata(smmu); #endif if (arm_smmu_ops.pgsize_bitmap == -1UL) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h index 776d326de105..ece2904fd728 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -175,6 +175,8 @@ #define ARM_SMMU_USER_CFG0 0xe00 #define ARM_SMMU_USER_MPAM_EN (1UL << 30) +#define ARM_SMMU_USER_CFG1 0xe04 + #define ARM_SMMU_IDR6 0x190 #define IDR6_LOG2NUMP GENMASK(27, 24) #define IDR6_LOG2NUMQ GENMASK(19, 16) @@ -717,6 +719,7 @@ struct arm_smmu_device { #define ARM_SMMU_OPT_PAGE0_REGS_ONLY (1 << 1) #define ARM_SMMU_OPT_MSIPOLL (1 << 2) #define ARM_SMMU_OPT_SYNC_MAP (1 << 3) +#define ARM_SMMU_OPT_SYNC_BATCH (1 << 4) u32 options; union { -- 2.17.1
2 1
0 0
[PATCH OLK-5.10] cpu/SMT: Make SMT control more robust against enumeration failures
by Yang Yingliang 16 May '24

16 May '24
From: Thomas Gleixner <tglx(a)linutronix.de> mainline inclusion from mainline-v6.7-rc1 commit d91bdd96b55cc3ce98d883a60f133713821b80a6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9NZ3E Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The SMT control mechanism got added as speculation attack vector mitigation. The implemented logic relies on the primary thread mask to be set up properly. This turns out to be an issue with XEN/PV guests because their CPU hotplug mechanics do not enumerate APICs and therefore the mask is never correctly populated. This went unnoticed so far because by chance XEN/PV ends up with smp_num_siblings == 2. So smt_hotplug_control stays at its default value CPU_SMT_ENABLED and the primary thread mask is never evaluated in the context of CPU hotplug. This stopped "working" with the upcoming overhaul of the topology evaluation which legitimately provides a fake topology for XEN/PV. That sets smp_num_siblings to 1, which causes the core CPU hot-plug core to refuse to bring up the APs. This happens because smt_hotplug_control is set to CPU_SMT_NOT_SUPPORTED which causes cpu_smt_allowed() to evaluate the unpopulated primary thread mask with the conclusion that all non-boot CPUs are not valid to be plugged. Make cpu_smt_allowed() more robust and take CPU_SMT_NOT_SUPPORTED and CPU_SMT_NOT_IMPLEMENTED into account. Rename it to cpu_bootable() while at it as that makes it more clear what the function is about. The primary mask issue on x86 XEN/PV needs to be addressed separately as there are users outside of the CPU hotplug code too. Fixes: 05736e4ac13c ("cpu/hotplug: Provide knobs to control SMT") Reported-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Juergen Gross <jgross(a)suse.com> Tested-by: Sohil Mehta <sohil.mehta(a)intel.com> Tested-by: Michael Kelley <mikelley(a)microsoft.com> Tested-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Tested-by: Zhang Rui <rui.zhang(a)intel.com> Acked-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lore.kernel.org/r/20230814085112.149440843@linutronix.de Conflicts: kernel/cpu.c [yyl: Don't rename it to cpu_bootable()] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/cpu.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/kernel/cpu.c b/kernel/cpu.c index 89a8e7b9fdac..fdd911b306e0 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -432,6 +432,14 @@ static inline bool cpu_smt_allowed(unsigned int cpu) if (cpu_smt_control == CPU_SMT_ENABLED) return true; + /* All CPUs are bootable if controls are not configured */ + if (cpu_smt_control == CPU_SMT_NOT_IMPLEMENTED) + return true; + + /* All CPUs are bootable if CPU is not SMT capable */ + if (cpu_smt_control == CPU_SMT_NOT_SUPPORTED) + return true; + if (topology_is_primary_thread(cpu)) return true; -- 2.25.1
2 1
0 0
[PATCH openEuler-1.0-LTS] cpu/SMT: Make SMT control more robust against enumeration failures
by Yang Yingliang 16 May '24

16 May '24
From: Thomas Gleixner <tglx(a)linutronix.de> mainline inclusion from mainline-v6.7-rc1 commit d91bdd96b55cc3ce98d883a60f133713821b80a6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9NZ3E Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The SMT control mechanism got added as speculation attack vector mitigation. The implemented logic relies on the primary thread mask to be set up properly. This turns out to be an issue with XEN/PV guests because their CPU hotplug mechanics do not enumerate APICs and therefore the mask is never correctly populated. This went unnoticed so far because by chance XEN/PV ends up with smp_num_siblings == 2. So smt_hotplug_control stays at its default value CPU_SMT_ENABLED and the primary thread mask is never evaluated in the context of CPU hotplug. This stopped "working" with the upcoming overhaul of the topology evaluation which legitimately provides a fake topology for XEN/PV. That sets smp_num_siblings to 1, which causes the core CPU hot-plug core to refuse to bring up the APs. This happens because smt_hotplug_control is set to CPU_SMT_NOT_SUPPORTED which causes cpu_smt_allowed() to evaluate the unpopulated primary thread mask with the conclusion that all non-boot CPUs are not valid to be plugged. Make cpu_smt_allowed() more robust and take CPU_SMT_NOT_SUPPORTED and CPU_SMT_NOT_IMPLEMENTED into account. Rename it to cpu_bootable() while at it as that makes it more clear what the function is about. The primary mask issue on x86 XEN/PV needs to be addressed separately as there are users outside of the CPU hotplug code too. Fixes: 05736e4ac13c ("cpu/hotplug: Provide knobs to control SMT") Reported-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Juergen Gross <jgross(a)suse.com> Tested-by: Sohil Mehta <sohil.mehta(a)intel.com> Tested-by: Michael Kelley <mikelley(a)microsoft.com> Tested-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Tested-by: Zhang Rui <rui.zhang(a)intel.com> Acked-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lore.kernel.org/r/20230814085112.149440843@linutronix.de Conflicts: kernel/cpu.c [yyl: Don't rename it to cpu_bootable()] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/cpu.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/cpu.c b/kernel/cpu.c index c943454b748e..d1d61f363a2c 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -402,6 +402,10 @@ static inline bool cpu_smt_allowed(unsigned int cpu) if (cpu_smt_control == CPU_SMT_ENABLED) return true; + /* All CPUs are bootable if CPU is not SMT capable */ + if (cpu_smt_control == CPU_SMT_NOT_SUPPORTED) + return true; + if (topology_is_primary_thread(cpu)) return true; -- 2.25.1
2 1
0 0
[PATCH OLK-5.10] clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays
by Zheng Zucheng 16 May '24

16 May '24
From: Gabor Juhos <j4g8y7(a)gmail.com> stable inclusion from stable-v5.10.215 commit ae60e3342296f766f88911d39199f77b05f657a6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5OA CVE: CVE-2024-26970 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit cdbc6e2d8108bc47895e5a901cfcaf799b00ca8d ] The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. Fixes: d9db07f088af ("clk: qcom: Add ipq6018 Global Clock Controller support") Signed-off-by: Gabor Juhos <j4g8y7(a)gmail.com> Reviewed-by: Stephen Boyd <sboyd(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240229-freq-table-terminator-v1-2-074334f0905c@… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/clk/qcom/gcc-ipq6018.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/qcom/gcc-ipq6018.c b/drivers/clk/qcom/gcc-ipq6018.c index 4c5c7a8f41d0..b9844e41cf99 100644 --- a/drivers/clk/qcom/gcc-ipq6018.c +++ b/drivers/clk/qcom/gcc-ipq6018.c @@ -1557,6 +1557,7 @@ static struct clk_regmap_div nss_ubi0_div_clk_src = { static const struct freq_tbl ftbl_pcie_aux_clk_src[] = { F(24000000, P_XO, 1, 0, 0), + { } }; static const struct clk_parent_data gcc_xo_gpll0_core_pi_sleep_clk[] = { @@ -1737,6 +1738,7 @@ static const struct freq_tbl ftbl_sdcc_ice_core_clk_src[] = { F(160000000, P_GPLL0, 5, 0, 0), F(216000000, P_GPLL6, 5, 0, 0), F(308570000, P_GPLL6, 3.5, 0, 0), + { } }; static const struct clk_parent_data gcc_xo_gpll0_gpll6_gpll0_div2[] = { -- 2.34.1
2 1
0 0
[PATCH OLK-6.6 0/2] add new kvm_type for Confidential VMs
by Ju Fu 16 May '24

16 May '24
add new kvm_type for Confidential VMs: 1. kvm: add macro CONFIG_CVM_HOST to defconfig 2. kvm: add new kvm_type for cvm arch/arm64/configs/defconfig | 1 + arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/kvm_host.h | 12 +++++ arch/arm64/include/asm/kvm_tmm.h | 71 ++++++++++++++++++++++++++ arch/arm64/kvm/Kconfig | 8 +++ 5 files changed, 93 insertions(+) create mode 100644 arch/arm64/include/asm/kvm_tmm.h -- 2.25.1.windows.1
2 3
0 0
  • ← Newer
  • 1
  • ...
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • ...
  • 137
  • Older →

HyperKitty Powered by HyperKitty