June 2025 - Linux-stable-mirror

Re: [PATCH 5.10.y 2/3] rtc: Make rtc_time64_to_tm() support dates before 1970

by Uwe Kleine-König

Hello Cassio, thanks for your input. On Tue, Jun 10, 2025 at 09:31:48PM +0100, Cassio Neri wrote: > Although untested, I'm pretty sure that with very small changes, the > previous revision (1d1bb12) can handle dates prior to 1970-01-01 with no > need to add extra branches or arithmetic operations. Indeed, 1d1bb12 > contains: > > <code> > /* time must be positive */ > days = div_s64_rem(time, 86400, &secs); > > /* day of the week, 1970-01-01 was a Thursday */ > tm->tm_wday = (days + 4) % 7; > > /* long comments */ > > udays = ((u32) days) + 719468; > </code> > > This could have been changed to: > > <code> > /* time must be >= -719468 * 86400 which corresponds to 0000-03-01 */ > udays = div_u64_rem(time + 719468 * 86400, 86400, &secs); > > /* day of the week, 0000-03-01 was a Wednesday (in the proleptic Gregorian > calendar) */ > tm->tm_wday = (days + 3) % 7; > > /* long comments */ > </code> > > Indeed, the addition of 719468 * 86400 to `time` makes `days` to be 719468 > more than it should be. Therefore, in the calculation of `udays`, the > addition of 719468 becomes unnecessary and thus, `udays == days`. Moreover, > this means that `days` can be removed altogether and replaced by `udays`. > (Not the other way around because in the remaining code `udays` must be > u32.) > > Now, 719468 % 7 = 1 and thus tm->wday is 1 day after what it should be and > we correct that by adding 3 instead of 4. > > Therefore, I suggest these changes on top of 1d1bb12 instead of those made > in 7df4cfe. Since you're working on this, can I please kindly suggest two > other changes? It's to late for "instead", and we're discussing a backport to stable for a commit that is already in v6.16-rc1. While your concerns are correct (though I didn't check the details yet), I claim that 7df4cfef8b35 is correct and it's the right thing to backport that today. Incremental changes can then go in the development version (and backported if deemed necessary). > 1) Change the reference provided in the long comment. It should say, "The > following algorithm is, basically, Figure 12 of Neri and Schneider [1]" and > [1] should refer to the published article: > > Neri C, Schneider L. Euclidean affine functions and their application to > calendar algorithms. Softw Pract Exper. 2023;53(4):937-970. doi: > 10.1002/spe.3172 > https://doi.org/10.1002/spe.3172 > > The article is much better written and clearer than the pre-print currently > referred to. I'll add that to my todo list. (that = improving rtc_time64_to_tm() and reading your paper :-) > 2) Function rtc_time64_to_tm_test_date_range in drivers/rtc/lib_test.c, is > a kunit test that checks the result for everyday in a 160000 years range > starting at 1970-01-01. It'd be nice if this test is adapted to the new > code and starts at 1900-01-01 (technically, it could start at 0000-03-01 > but since tm->year counts from 1900, it would be weird to see tm->year == > -1900 to mean that the calendar year is 0.) Also 160000 is definitely an > overkill (my bad!) and a couple of thousands of years, say 3000, should be > more than safe for anyone. :-) I already did 2), see https://git.kernel.org/linus/ccb2dba3c19f. Best regards Uwe

2 months, 2 weeks

1
0
0 0

Mailbox Alert: Storage Limit Almost Reached

by lists.linaro.org 通知

2 months, 2 weeks

1
0
0 0

[PATCH] x86/mm: Disable INVLPGB when PTI is enabled

by Dave Hansen

From: Dave Hansen <dave.hansen(a)linux.intel.com> PTI uses separate ASIDs (aka. PCIDs) for kernel and user address spaces. When the kernel needs to flush the user address space, it just sets a bit in a bitmap and then flushes the entire PCID on the next switch to userspace. But, this bitmap is a single 'unsigned long' which is plenty for all 6 dynamic ASIDs. But, unfortunately, the INVLPGB support brings along a bunch more user ASIDs, as many as ~2k more. The bitmap can't address that many. Fortunately, the bitmap is only needed for PTI and all the CPUs with INVLPGB are AMD CPUs that aren't vulnerable to Meltdown and don't need PTI. The only way someone can run into an issue in practice is by booting with pti=on on a newer AMD CPU. Disable INVLPGB if PTI is enabled. Avoid overrunning the small bitmap. Note: this will be fixed up properly by making the bitmap bigger. For now, just avoid the mostly theoretical bug. Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Fixes: 4afeb0ed1753 ("x86/mm: Enable broadcast TLB invalidation for multi-threaded processes") Cc: stable(a)vger.kernel.org Cc: Rik van Riel <riel(a)surriel.com> Cc: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> --- b/arch/x86/mm/pti.c | 5 +++++ 1 file changed, 5 insertions(+) diff -puN arch/x86/mm/pti.c~no-INVLPGB-plus-KPTI arch/x86/mm/pti.c --- a/arch/x86/mm/pti.c~no-INVLPGB-plus-KPTI 2025-06-10 15:02:14.439554339 -0700 +++ b/arch/x86/mm/pti.c 2025-06-10 15:09:47.713198206 -0700 @@ -98,6 +98,11 @@ void __init pti_check_boottime_disable(v return; setup_force_cpu_cap(X86_FEATURE_PTI); + + if (cpu_feature_enabled(X86_FEATURE_INVLPGB)) { + pr_debug("PTI enabled, disabling INVLPGB\n"); + setup_clear_cpu_cap(X86_FEATURE_INVLPGB); + } } static int __init pti_parse_cmdline(char *arg) _

2 months, 2 weeks

3
2
0 0

[PATCH v2] mm/memory-tier: Fix abstract distance calculation overflow

by Li Zhijian

In mt_perf_to_adistance(), the calculation of abstract distance (adist) involves multiplying several int values including MEMTIER_ADISTANCE_DRAM. ``` *adist = MEMTIER_ADISTANCE_DRAM * (perf->read_latency + perf->write_latency) / (default_dram_perf.read_latency + default_dram_perf.write_latency) * (default_dram_perf.read_bandwidth + default_dram_perf.write_bandwidth) / (perf->read_bandwidth + perf->write_bandwidth); ``` Since these values can be large, the multiplication may exceed the maximum value of an int (INT_MAX) and overflow (Our platform did), leading to an incorrect adist. User-visible impact: The memory tiering subsystem will misinterpret slow memory (like CXL) as faster than DRAM, causing inappropriate demotion of pages from CXL (slow memory) to DRAM (fast memory). For example, we will see the following demotion chains from the dmesg, where Node0,1 are DRAM, and Node2,3 are CXL node: Demotion targets for Node 0: null Demotion targets for Node 1: null Demotion targets for Node 2: preferred: 0-1, fallback: 0-1 Demotion targets for Node 3: preferred: 0-1, fallback: 0-1 Change MEMTIER_ADISTANCE_DRAM to be a long constant by writing it with the 'L' suffix. This prevents the overflow because the multiplication will then be done in the long type which has a larger range. Fixes: 3718c02dbd4c ("acpi, hmat: calculate abstract distance with HMAT") Cc: stable(a)vger.kernel.org Reviewed-by: Huang Ying <ying.huang(a)linux.alibaba.com> Acked-by: Balbir Singh <balbirs(a)nvidia.com> Reviewed-by: Donet Tom <donettom(a)linux.ibm.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Signed-off-by: Li Zhijian <lizhijian(a)fujitsu.com> --- V2: Document the 'User-visible impact' # Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/memory-tiers.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/memory-tiers.h b/include/linux/memory-tiers.h index 0dc0cf2863e2..7a805796fcfd 100644 --- a/include/linux/memory-tiers.h +++ b/include/linux/memory-tiers.h @@ -18,7 +18,7 @@ * adistance value (slightly faster) than default DRAM adistance to be part of * the same memory tier. */ -#define MEMTIER_ADISTANCE_DRAM ((4 * MEMTIER_CHUNK_SIZE) + (MEMTIER_CHUNK_SIZE >> 1)) +#define MEMTIER_ADISTANCE_DRAM ((4L * MEMTIER_CHUNK_SIZE) + (MEMTIER_CHUNK_SIZE >> 1)) struct memory_tier; struct memory_dev_type { -- 2.41.0

2 months, 2 weeks

1
0
0 0

+ maple_tree-restart-walk-on-correct-status.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: maple_tree: restart walk on correct status has been added to the -mm mm-new branch. Its filename is maple_tree-restart-walk-on-correct-status.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-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. 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: Wei Yang <richard.weiyang(a)gmail.com> Subject: maple_tree: restart walk on correct status Date: Wed, 11 Jun 2025 01:12:52 +0000 Commit a8091f039c1e ("maple_tree: add MAS_UNDERFLOW and MAS_OVERFLOW states") adds more status during maple tree walk. But it introduce a typo on the status check during walk. It expects to mean neither active nor start, we would restart the walk, while current code means we would always restart the walk. Link: https://lkml.kernel.org/r/20250611011253.19515-3-richard.weiyang@gmail.com Fixes: a8091f039c1e ("maple_tree: add MAS_UNDERFLOW and MAS_OVERFLOW states") Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/maple_tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/lib/maple_tree.c~maple_tree-restart-walk-on-correct-status +++ a/lib/maple_tree.c @@ -4930,7 +4930,7 @@ void *mas_walk(struct ma_state *mas) { void *entry; - if (!mas_is_active(mas) || !mas_is_start(mas)) + if (!mas_is_active(mas) && !mas_is_start(mas)) mas->status = ma_start; retry: entry = mas_state_walk(mas); _ Patches currently in -mm which might be from richard.weiyang(a)gmail.com are maple_tree-fix-mt_destroy_walk-on-root-leaf-node.patch maple_tree-restart-walk-on-correct-status.patch maple_tree-assert-retrieving-new-value-on-a-tree-containing-just-a-leaf-node.patch

2 months, 2 weeks

1
0
0 0

+ maple_tree-fix-mt_destroy_walk-on-root-leaf-node.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: maple_tree: fix mt_destroy_walk() on root leaf node has been added to the -mm mm-new branch. Its filename is maple_tree-fix-mt_destroy_walk-on-root-leaf-node.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-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. 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: Wei Yang <richard.weiyang(a)gmail.com> Subject: maple_tree: fix mt_destroy_walk() on root leaf node Date: Wed, 11 Jun 2025 01:12:51 +0000 Patch series "maple_tree: Fix the replacement of a root leaf node", v3. On destroy we should set each node dead. But current code miss this when the maple tree has only the root node. The reason is that mt_destroy_walk() leverages mte_destroy_descend() to set the node dead, but this is skipped since the only root node is a leaf. Patch 1 fixes this. When adding a test case, I found we always get the new value even when we leave the old root node not dead. It turns out we always re-walk the tree in mas_walk(). It looks like a typo on the status check of mas_walk(). Patch 2 fixes this. Patch 3 adds a test case to assert retrieving new value when overwriting the whole range to a tree with only root node. This patch (of 3): On destroy, we should set each node dead. But current code miss this when the maple tree has only the root node. The reason is mt_destroy_walk() leverage mte_destroy_descend() to set node dead, but this is skipped since the only root node is a leaf. Fixes this by setting the node dead if it is a leaf. Link: https://lkml.kernel.org/r/20250611011253.19515-1-richard.weiyang@gmail.com Link: https://lkml.kernel.org/r/20250611011253.19515-2-richard.weiyang@gmail.com Fixes: 54a611b60590 ("Maple Tree: add new data structure") Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/maple_tree.c | 1 + 1 file changed, 1 insertion(+) --- a/lib/maple_tree.c~maple_tree-fix-mt_destroy_walk-on-root-leaf-node +++ a/lib/maple_tree.c @@ -5319,6 +5319,7 @@ static void mt_destroy_walk(struct maple struct maple_enode *start; if (mte_is_leaf(enode)) { + mte_set_node_dead(enode); node->type = mte_node_type(enode); goto free_leaf; } _ Patches currently in -mm which might be from richard.weiyang(a)gmail.com are maple_tree-fix-mt_destroy_walk-on-root-leaf-node.patch maple_tree-restart-walk-on-correct-status.patch maple_tree-assert-retrieving-new-value-on-a-tree-containing-just-a-leaf-node.patch

2 months, 2 weeks

1
0
0 0

[PATCH v3 5/9] LoongArch: KVM: INTC: Avoid overflow with array index

by Bibo Mao

Variable index is modified and reused as array index when modify register EIOINTC_ENABLE. There will be array index overflow problem. Cc: stable(a)vger.kernel.org Fixes: 3956a52bc05b ("LoongArch: KVM: Add EIOINTC read and write functions") Signed-off-by: Bibo Mao <maobibo(a)loongson.cn> --- arch/loongarch/kvm/intc/eiointc.c | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/arch/loongarch/kvm/intc/eiointc.c b/arch/loongarch/kvm/intc/eiointc.c index ed80bf290755..0bc870796f56 100644 --- a/arch/loongarch/kvm/intc/eiointc.c +++ b/arch/loongarch/kvm/intc/eiointc.c @@ -447,17 +447,16 @@ static int loongarch_eiointc_writew(struct kvm_vcpu *vcpu, break; case EIOINTC_ENABLE_START ... EIOINTC_ENABLE_END: index = (offset - EIOINTC_ENABLE_START) >> 1; - old_data = s->enable.reg_u32[index]; + old_data = s->enable.reg_u16[index]; s->enable.reg_u16[index] = data; /* * 1: enable irq. * update irq when isr is set. */ data = s->enable.reg_u16[index] & ~old_data & s->isr.reg_u16[index]; - index = index << 1; for (i = 0; i < sizeof(data); i++) { u8 mask = (data >> (i * 8)) & 0xff; - eiointc_enable_irq(vcpu, s, index + i, mask, 1); + eiointc_enable_irq(vcpu, s, index * 2 + i, mask, 1); } /* * 0: disable irq. @@ -466,7 +465,7 @@ static int loongarch_eiointc_writew(struct kvm_vcpu *vcpu, data = ~s->enable.reg_u16[index] & old_data & s->isr.reg_u16[index]; for (i = 0; i < sizeof(data); i++) { u8 mask = (data >> (i * 8)) & 0xff; - eiointc_enable_irq(vcpu, s, index, mask, 0); + eiointc_enable_irq(vcpu, s, index * 2 + i, mask, 0); } break; case EIOINTC_BOUNCE_START ... EIOINTC_BOUNCE_END: @@ -540,10 +539,9 @@ static int loongarch_eiointc_writel(struct kvm_vcpu *vcpu, * update irq when isr is set. */ data = s->enable.reg_u32[index] & ~old_data & s->isr.reg_u32[index]; - index = index << 2; for (i = 0; i < sizeof(data); i++) { u8 mask = (data >> (i * 8)) & 0xff; - eiointc_enable_irq(vcpu, s, index + i, mask, 1); + eiointc_enable_irq(vcpu, s, index * 4 + i, mask, 1); } /* * 0: disable irq. @@ -552,7 +550,7 @@ static int loongarch_eiointc_writel(struct kvm_vcpu *vcpu, data = ~s->enable.reg_u32[index] & old_data & s->isr.reg_u32[index]; for (i = 0; i < sizeof(data); i++) { u8 mask = (data >> (i * 8)) & 0xff; - eiointc_enable_irq(vcpu, s, index, mask, 0); + eiointc_enable_irq(vcpu, s, index * 4 + i, mask, 0); } break; case EIOINTC_BOUNCE_START ... EIOINTC_BOUNCE_END: @@ -626,10 +624,9 @@ static int loongarch_eiointc_writeq(struct kvm_vcpu *vcpu, * update irq when isr is set. */ data = s->enable.reg_u64[index] & ~old_data & s->isr.reg_u64[index]; - index = index << 3; for (i = 0; i < sizeof(data); i++) { u8 mask = (data >> (i * 8)) & 0xff; - eiointc_enable_irq(vcpu, s, index + i, mask, 1); + eiointc_enable_irq(vcpu, s, index * 8 + i, mask, 1); } /* * 0: disable irq. @@ -638,7 +635,7 @@ static int loongarch_eiointc_writeq(struct kvm_vcpu *vcpu, data = ~s->enable.reg_u64[index] & old_data & s->isr.reg_u64[index]; for (i = 0; i < sizeof(data); i++) { u8 mask = (data >> (i * 8)) & 0xff; - eiointc_enable_irq(vcpu, s, index, mask, 0); + eiointc_enable_irq(vcpu, s, index * 8 + i, mask, 0); } break; case EIOINTC_BOUNCE_START ... EIOINTC_BOUNCE_END: -- 2.39.3

2 months, 2 weeks

1
0
0 0

[PATCH v3 3/9] LoongArch: KVM: INTC: Disable update property num_cpu and feature

by Bibo Mao

Property num_cpu and feature is read-only once eiointc is created, which is set with KVM_DEV_LOONGARCH_EXTIOI_GRP_CTRL attr group before device creation. Attr group KVM_DEV_LOONGARCH_EXTIOI_GRP_SW_STATUS is to update register and software state for migration and reset usage, property num_cpu and feature can not be update again if it is created already. Here discard write operation with property num_cpu and feature in attr group KVM_DEV_LOONGARCH_EXTIOI_GRP_CTRL. Cc: stable(a)vger.kernel.org Fixes: 1ad7efa552fd ("LoongArch: KVM: Add EIOINTC user mode read and write functions") Signed-off-by: Bibo Mao <maobibo(a)loongson.cn> --- arch/loongarch/kvm/intc/eiointc.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/arch/loongarch/kvm/intc/eiointc.c b/arch/loongarch/kvm/intc/eiointc.c index 0b648c56b0c3..b48511f903b5 100644 --- a/arch/loongarch/kvm/intc/eiointc.c +++ b/arch/loongarch/kvm/intc/eiointc.c @@ -910,9 +910,22 @@ static int kvm_eiointc_sw_status_access(struct kvm_device *dev, data = (void __user *)attr->addr; switch (addr) { case KVM_DEV_LOONGARCH_EXTIOI_SW_STATUS_NUM_CPU: + /* + * Property num_cpu and feature is read-only once eiointc is + * created with KVM_DEV_LOONGARCH_EXTIOI_GRP_CTRL group API + * + * Disable writing with KVM_DEV_LOONGARCH_EXTIOI_GRP_SW_STATUS + * group API + */ + if (is_write) + return ret; + p = &s->num_cpu; break; case KVM_DEV_LOONGARCH_EXTIOI_SW_STATUS_FEATURE: + if (is_write) + return ret; + p = &s->features; break; case KVM_DEV_LOONGARCH_EXTIOI_SW_STATUS_STATE: -- 2.39.3

2 months, 2 weeks

1
0
0 0

[PATCH v3 2/9] LoongArch: KVM: INTC: Check interrupt route from physical cpu

by Bibo Mao

With eiointc interrupt controller, physical cpu id is set for irq route. However function kvm_get_vcpu() is used to get destination vCPU when delivering irq. With API kvm_get_vcpu(), logical cpu is used. With API kvm_get_vcpu_by_cpuid(), vCPU can be searched from physical cpu id. Cc: stable(a)vger.kernel.org Fixes: 3956a52bc05b ("LoongArch: KVM: Add EIOINTC read and write functions") Signed-off-by: Bibo Mao <maobibo(a)loongson.cn> --- arch/loongarch/kvm/intc/eiointc.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/arch/loongarch/kvm/intc/eiointc.c b/arch/loongarch/kvm/intc/eiointc.c index d2c521b0e923..0b648c56b0c3 100644 --- a/arch/loongarch/kvm/intc/eiointc.c +++ b/arch/loongarch/kvm/intc/eiointc.c @@ -9,7 +9,8 @@ static void eiointc_set_sw_coreisr(struct loongarch_eiointc *s) { - int ipnum, cpu, irq_index, irq_mask, irq; + int ipnum, cpu, irq_index, irq_mask, irq, cpuid; + struct kvm_vcpu *vcpu; for (irq = 0; irq < EIOINTC_IRQS; irq++) { ipnum = s->ipmap.reg_u8[irq / 32]; @@ -20,7 +21,12 @@ static void eiointc_set_sw_coreisr(struct loongarch_eiointc *s) irq_index = irq / 32; irq_mask = BIT(irq & 0x1f); - cpu = s->coremap.reg_u8[irq]; + cpuid = s->coremap.reg_u8[irq]; + vcpu = kvm_get_vcpu_by_cpuid(s->kvm, cpuid); + if (vcpu == NULL) + continue; + + cpu = vcpu->vcpu_id; if (!!(s->coreisr.reg_u32[cpu][irq_index] & irq_mask)) set_bit(irq, s->sw_coreisr[cpu][ipnum]); else @@ -68,17 +74,23 @@ static void eiointc_update_irq(struct loongarch_eiointc *s, int irq, int level) static inline void eiointc_update_sw_coremap(struct loongarch_eiointc *s, int irq, u64 val, u32 len, bool notify) { - int i, cpu; + int i, cpu, cpuid; + struct kvm_vcpu *vcpu; for (i = 0; i < len; i++) { - cpu = val & 0xff; + cpuid = val & 0xff; val = val >> 8; if (!(s->status & BIT(EIOINTC_ENABLE_CPU_ENCODE))) { - cpu = ffs(cpu) - 1; - cpu = (cpu >= 4) ? 0 : cpu; + cpuid = ffs(cpuid) - 1; + cpuid = (cpuid >= 4) ? 0 : cpuid; } + vcpu = kvm_get_vcpu_by_cpuid(s->kvm, cpuid); + if (vcpu == NULL) + continue; + + cpu = vcpu->vcpu_id; if (s->sw_coremap[irq + i] == cpu) continue; -- 2.39.3

2 months, 2 weeks

1
0
0 0

[PATCH v3 1/9] LoongArch: KVM: INTC: Fix interrupt route update with eiointc

by Bibo Mao

With function eiointc_update_sw_coremap(), there is forced assignment like val = *(u64 *)pvalue. Parameter pvalue may be pointer to char type or others, there is problem with forced assignment with u64 type. Here the detailed value is passed rather address pointer. Cc: stable(a)vger.kernel.org Fixes: 3956a52bc05b ("LoongArch: KVM: Add EIOINTC read and write functions") Signed-off-by: Bibo Mao <maobibo(a)loongson.cn> --- arch/loongarch/kvm/intc/eiointc.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/loongarch/kvm/intc/eiointc.c b/arch/loongarch/kvm/intc/eiointc.c index f39929d7bf8a..d2c521b0e923 100644 --- a/arch/loongarch/kvm/intc/eiointc.c +++ b/arch/loongarch/kvm/intc/eiointc.c @@ -66,10 +66,9 @@ static void eiointc_update_irq(struct loongarch_eiointc *s, int irq, int level) } static inline void eiointc_update_sw_coremap(struct loongarch_eiointc *s, - int irq, void *pvalue, u32 len, bool notify) + int irq, u64 val, u32 len, bool notify) { int i, cpu; - u64 val = *(u64 *)pvalue; for (i = 0; i < len; i++) { cpu = val & 0xff; @@ -398,7 +397,7 @@ static int loongarch_eiointc_writeb(struct kvm_vcpu *vcpu, irq = offset - EIOINTC_COREMAP_START; index = irq; s->coremap.reg_u8[index] = data; - eiointc_update_sw_coremap(s, irq, (void *)&data, sizeof(data), true); + eiointc_update_sw_coremap(s, irq, data, sizeof(data), true); break; default: ret = -EINVAL; @@ -484,7 +483,7 @@ static int loongarch_eiointc_writew(struct kvm_vcpu *vcpu, irq = offset - EIOINTC_COREMAP_START; index = irq >> 1; s->coremap.reg_u16[index] = data; - eiointc_update_sw_coremap(s, irq, (void *)&data, sizeof(data), true); + eiointc_update_sw_coremap(s, irq, data, sizeof(data), true); break; default: ret = -EINVAL; @@ -570,7 +569,7 @@ static int loongarch_eiointc_writel(struct kvm_vcpu *vcpu, irq = offset - EIOINTC_COREMAP_START; index = irq >> 2; s->coremap.reg_u32[index] = data; - eiointc_update_sw_coremap(s, irq, (void *)&data, sizeof(data), true); + eiointc_update_sw_coremap(s, irq, data, sizeof(data), true); break; default: ret = -EINVAL; @@ -656,7 +655,7 @@ static int loongarch_eiointc_writeq(struct kvm_vcpu *vcpu, irq = offset - EIOINTC_COREMAP_START; index = irq >> 3; s->coremap.reg_u64[index] = data; - eiointc_update_sw_coremap(s, irq, (void *)&data, sizeof(data), true); + eiointc_update_sw_coremap(s, irq, data, sizeof(data), true); break; default: ret = -EINVAL; @@ -809,7 +808,7 @@ static int kvm_eiointc_ctrl_access(struct kvm_device *dev, for (i = 0; i < (EIOINTC_IRQS / 4); i++) { start_irq = i * 4; eiointc_update_sw_coremap(s, start_irq, - (void *)&s->coremap.reg_u32[i], sizeof(u32), false); + s->coremap.reg_u32[i], sizeof(u32), false); } break; default: -- 2.39.3

2 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2025