- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/2] CVE-2026-100074
by Pu Lehui 13 Oct '26

13 Oct '26

Kumar Kartikeya Dwivedi (1): bpf: Mark bpf_refcount field as unique Mykyta Yatsenko (1): bpf: refactor special field-type detection kernel/bpf/btf.c | 59 ++++++++++++++++++++++++------------------------ 1 file changed, 29 insertions(+), 30 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] bpf: check_cond_jmp_op(): properly infer if register is null
by Pu Lehui 13 Oct '26

13 Oct '26

From: Eduard Zingerman <eddyz87(a)gmail.com> mainline inclusion from mainline-v7.3-rc2 commit d3ef6c097ba078e1f8c7239d76a0ce8b61e75095 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19697 CVE: CVE-2026-98134 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Nicholas Carlini reported a bug when verifier can incorrectly infer that a pointer is non-null. The bug occurs when two pointers are compared and one of them has a type w/o PTR_MAYBE_NULL flag, but which allows a value to be NULL at runtime. Here is an example: // `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED // `a` is 0 at runtime. // `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL void *a = bpf_rdonly_cast(0, 0); int *b = bpf_map_lookup_elem(...); if (a == b) *b = 42; // verifier does not catch null pointer dereference This happens because of a special case in check_cond_jmp_op(), which attempts to strip PTR_MAYBE_NULL flags from pointer types, when processing comparisons like `rA == rB`, if either rA or rB can't be null. The non-null property is derived based on the absence of PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient for types like PTR_TO_MEM, as in the example. This patch replaces type_may_be_null() call with reg_not_null(), which contains an allowlist of types for which absence of PTR_MAYBE_NULL actually means that the value can't be NULL at runtime. At the moment, the list in the reg_not_null() omits two types for which PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF. In order to remain backward compatible, and assuming that only comparison between pointers of the same type makes sense, this commit extends reg_not_null(). W/o such an extension e.g. verifier_jeq_infer_not_null/null_ptr_to_map_value fails. reg_not_null() can be extended further, but I deem that out of scope for the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID checks in the check_cond_jmp_op() can be removed with migration to reg_not_null(), but that is a behavioural change, as the special case would start matching for PTR_TO_BTF_ID that is also is_trusted_reg(). I omit the behavioural change from this commit. Fixes: befae75856ab ("bpf: propagate nullness information for reg to reg comparisons") Suggested-by: Nicholas Carlini <npc(a)anthropic.com> Signed-off-by: Eduard Zingerman <eddyz87(a)gmail.com> Link: https://lore.kernel.org/r/20260826-bug-029-bad-non-null-inference-v2-1-1367… Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Conflicts: kernel/bpf/verifier.c [reg_not_null has no env arg] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/verifier.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index b796d985e420..55c470694a80 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -470,6 +470,8 @@ static bool reg_not_null(const struct bpf_reg_state *reg) type = base_type(type); return type == PTR_TO_SOCKET || type == PTR_TO_TCP_SOCK || + type == PTR_TO_XDP_SOCK || + type == PTR_TO_BUF || type == PTR_TO_MAP_VALUE || type == PTR_TO_MAP_KEY || type == PTR_TO_SOCK_COMMON || @@ -15170,7 +15172,6 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env, */ if (!is_jmp32 && BPF_SRC(insn->code) == BPF_X && __is_pointer_value(false, src_reg) && __is_pointer_value(false, dst_reg) && - type_may_be_null(src_reg->type) != type_may_be_null(dst_reg->type) && base_type(src_reg->type) != PTR_TO_BTF_ID && base_type(dst_reg->type) != PTR_TO_BTF_ID) { eq_branch_regs = NULL; @@ -15186,9 +15187,11 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env, break; } if (eq_branch_regs) { - if (type_may_be_null(src_reg->type)) + /* src == dst && dst != NULL => src != NULL */ + if (reg_not_null(dst_reg) && type_may_be_null(src_reg->type)) mark_ptr_not_null_reg(&eq_branch_regs[insn->src_reg]); - else + /* src == dst && src != NULL => dst != NULL */ + if (reg_not_null(src_reg) && type_may_be_null(dst_reg->type)) mark_ptr_not_null_reg(&eq_branch_regs[insn->dst_reg]); } } -- 2.34.1

2 1

[PATCH OLK-6.6] bpf: backtracking shouldn't clear outer frame R1-R5 for callbacks
by Pu Lehui 13 Oct '26

13 Oct '26

From: Eduard Zingerman <eddyz87(a)gmail.com> mainline inclusion from mainline-v7.3-rc2 commit e3e4f66cc4b72333d0886ae2673c360248987889 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19752 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- When processing calls to bpf_loop() verifier marks R1 (and R4) as precise. R1 tracks loop iterations number and because of the 'callback_depth < R1' mechanics in check_helper_call() must be marked precise. However, precision propagation for R1 was broken, when bpf_loop() call was verified on a second iteration. Consider the following verification trace: - main: bpf_loop(nr_loops, callback ...) - callback: BPF_EXIT - main: bpf_loop(nr_loops, callback ...) - ... While the first visit of the call to bpf_loop() propagated R1 precision as expected, the second call to mark_chain_precision() in the check_helper_call() set R1, but it was immediately reset when backtrack_insn() processed preceding BPF_EXIT in the loop deleted in this patch. Because of that, the second visit of the call to bpf_loop() injected checkpoint with R1 not marked as precise. Which could trick the verifier into accepting unsafe programs. See the next patch for an example of such program. Commit is structured in a way to minimize conflicts when 'bpf' would be eventually merged with 'bpf-next'. Fixes: ab5cfac139ab ("bpf: verify callbacks as if they are called unknown number of times") Reported-by: Nicholas Carlini <npc(a)anthropic.com> Suggested-by: Nicholas Carlini <npc(a)anthropic.com> Signed-off-by: Eduard Zingerman <eddyz87(a)gmail.com> Link: https://lore.kernel.org/r/20260831-bug-015-backtrack-cb-args-precise-v1-1-6… Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Conflicts: kernel/bpf/verifier.c [ctx conflicts] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/verifier.c | 37 +++++++++++++++++-------------------- 1 file changed, 17 insertions(+), 20 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index b796d985e420..98454d1d1358 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -3997,37 +3997,34 @@ static int backtrack_insn(struct bpf_verifier_env *env, int idx, int subseq_idx, return -EFAULT; } } else if (opcode == BPF_EXIT) { - bool r0_precise; + bool from_subprog_call, r0_precise; + + /* BPF_EXIT in subprog or callback always returns + * right after the call instruction, so by checking + * whether the instruction at subseq_idx-1 is subprog + * call or not we can distinguish actual exit from + * *subprog* from exit from *callback*. In the former + * case, we need to propagate r0 precision, if + * necessary. In the former we never do that. + */ + from_subprog_call = subseq_idx - 1 >= 0 && + bpf_pseudo_call(&env->prog->insnsi[subseq_idx - 1]); + + r0_precise = from_subprog_call && bt_is_reg_set(bt, BPF_REG_0); /* Backtracking to a nested function call, 'idx' is a part of * the inner frame 'subseq_idx' is a part of the outer frame. * In case of a regular function call, instructions giving * precision to registers R1-R5 should have been found already. - * In case of a callback, it is ok to have R1-R5 marked for - * backtracking, as these registers are set by the function - * invoking callback. + * In case of a callback from bpf_loop(), R{1,4} in the calling + * frame would be set as precise and that is correct. */ - if (subseq_idx >= 0 && calls_callback(env, subseq_idx)) - for (i = BPF_REG_1; i <= BPF_REG_5; i++) - bt_clear_reg(bt, i); - if (bt_reg_mask(bt) & BPF_REGMASK_ARGS) { + if (from_subprog_call && (bt_reg_mask(bt) & BPF_REGMASK_ARGS)) { verbose(env, "BUG regs %x\n", bt_reg_mask(bt)); WARN_ONCE(1, "verifier backtracking bug"); return -EFAULT; } - /* BPF_EXIT in subprog or callback always returns - * right after the call instruction, so by checking - * whether the instruction at subseq_idx-1 is subprog - * call or not we can distinguish actual exit from - * *subprog* from exit from *callback*. In the former - * case, we need to propagate r0 precision, if - * necessary. In the former we never do that. - */ - r0_precise = subseq_idx - 1 >= 0 && - bpf_pseudo_call(&env->prog->insnsi[subseq_idx - 1]) && - bt_is_reg_set(bt, BPF_REG_0); - bt_clear_reg(bt, BPF_REG_0); if (bt_subprog_enter(bt)) return -EFAULT; -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] Fix the perf tool cs-etm-decoder compilation issue
by Tengda Wu 13 Oct '26

13 Oct '26

Fix the perf tool cs-etm-decoder compilation issue. This issue was introduced by the stable-v6.6.157 version and has not yet been resolved, so temporarily revert it as a workaround. Tengda Wu (2): Revert "perf cs-etm: Fix thread leaks on trace queue init failure" Revert "perf cs-etm: Queue context packets for frontend" .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 21 +- tools/perf/util/cs-etm.c | 240 +++++++----------- tools/perf/util/cs-etm.h | 8 +- 3 files changed, 102 insertions(+), 167 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/2] Fix the perf tool cs-etm-decoder compilation issue.
by Tengda Wu 13 Oct '26

13 Oct '26

Fix the perf tool cs-etm-decoder compilation issue. This issue was introduced by the stable-v6.6.157 version and has not yet been resolved, so temporarily revert it as a workaround. Tengda Wu (2): Revert "perf cs-etm: Fix thread leaks on trace queue init failure" Revert "perf cs-etm: Queue context packets for frontend" .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 21 +- tools/perf/util/cs-etm.c | 240 +++++++----------- tools/perf/util/cs-etm.h | 8 +- 3 files changed, 102 insertions(+), 167 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/2] CVE-2026-100074
by Pu Lehui 13 Oct '26

13 Oct '26

Kumar Kartikeya Dwivedi (1): bpf: Mark bpf_refcount field as unique Mykyta Yatsenko (1): bpf: refactor special field-type detection kernel/bpf/btf.c | 59 ++++++++++++++++++++++++------------------------ 1 file changed, 29 insertions(+), 30 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] mm/huge_memory: fix unconditional pgtable deposit for special huge PMD in copy_huge_pmd()
by Jinjiang Tu 13 Oct '26

13 Oct '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/10116 -------------------------------- In copy_huge_pmd(), the special huge PMD path unconditionally allocates a pgtable and deposits it to the destination PMD. However, the pgtable withdraw in zap_huge_pmd() is guarded by arch_needs_pgtable_deposit(), which returns false on x86. This asymmetry causes a 4KB pgtable page and an mm->nr_ptes counter increment to leak on every fork+zap cycle of a special huge PMD on x86. Guard the deposit for special huge PMD in copy_huge_pmd() with the same arch_needs_pgtable_deposit() check, matching what vmf_insert_pfn_pmd() already does at insertion time and what zap_huge_pmd() does at teardown. Fixes: 923e224a1246 ("mm: introduce remap_pfn_range_try_pmd() for PMD-level hugepage mapping") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/huge_memory.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 805a903d8423..d423824dc67a 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1834,9 +1834,11 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm, pmd = pmdp_get_lockless(src_pmd); if (unlikely(pmd_present(pmd) && pmd_special(pmd))) { - pgtable = pte_alloc_one(dst_mm); - if (unlikely(!pgtable)) - goto out; + if (arch_needs_pgtable_deposit(dst_vma)) { + pgtable = pte_alloc_one(dst_mm); + if (unlikely(!pgtable)) + goto out; + } dst_ptl = pmd_lock(dst_mm, dst_pmd); src_ptl = pmd_lockptr(src_mm, src_pmd); spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING); @@ -1854,8 +1856,10 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm, /* dax won't reach here, it will be intercepted at vma_needs_copy() */ VM_WARN_ON_ONCE(vma_is_dax(src_vma)); - mm_inc_nr_ptes(dst_mm); - pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable); + if (pgtable) { + mm_inc_nr_ptes(dst_mm); + pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable); + } goto set_pmd; } -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters
by Xia Fukun 13 Oct '26

13 Oct '26

From: TanZheng <tanzheng(a)kylinos.cn> mainline inclusion from mainline-v7.3-rc1 commit b38f98e176050850f41bb6415f3a71400056623e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19940 CVE: CVE-2026-100075 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When srpt_alloc_rw_ctxs() fails partway through a multi-buffer indirect descriptor, the unwind path destroys RDMA contexts but leaves stale n_rw_ctx and n_rdma values (and a dangling rw_ctxs pointer). Later sq_wr_avail accounting in srpt_queue_response() or srpt_write_pending() can then subtract the wrong number of send queue credits. Reset the counters and clear rw_ctxs after freeing the heap allocation before returning an error. Fixes: b99f8e4d7bcd ("IB/srpt: convert to the generic RDMA READ/WRITE API") Signed-off-by: TanZheng <tanzheng(a)kylinos.cn> Link: https://patch.msgid.link/20260715101550.45345-1-kensanya@163.com Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/infiniband/ulp/srpt/ib_srpt.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c index 4948d5b446b6..e72e112ebf2e 100644 --- a/drivers/infiniband/ulp/srpt/ib_srpt.c +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c @@ -891,6 +891,7 @@ static int srpt_alloc_rw_ctxs(struct srpt_send_ioctx *ioctx, struct srpt_rdma_ch *ch = ioctx->ch; struct scatterlist *prev = NULL; unsigned prev_nents; + u8 n_rdma, n_rw_ctx; int ret, i; if (nbufs == 1) { @@ -902,6 +903,9 @@ static int srpt_alloc_rw_ctxs(struct srpt_send_ioctx *ioctx, return -ENOMEM; } + n_rw_ctx = ioctx->n_rw_ctx; + n_rdma = ioctx->n_rdma; + for (i = ioctx->n_rw_ctx; i < nbufs; i++, db++) { struct srpt_rw_ctx *ctx = &ioctx->rw_ctxs[i]; u64 remote_addr = be64_to_cpu(db->va); @@ -948,6 +952,9 @@ static int srpt_alloc_rw_ctxs(struct srpt_send_ioctx *ioctx, } if (ioctx->rw_ctxs != &ioctx->s_rw_ctx) kfree(ioctx->rw_ctxs); + ioctx->rw_ctxs = NULL; + ioctx->n_rw_ctx = n_rw_ctx; + ioctx->n_rdma = n_rdma; return ret; } -- 2.34.1

2 1

[PATCH OLK-6.6] mm/huge_memory: fix unconditional pgtable deposit for special huge PMD in copy_huge_pmd()
by Jinjiang Tu 13 Oct '26

13 Oct '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/10116 -------------------------------- In copy_huge_pmd(), the special huge PMD path unconditionally allocates a pgtable and deposits it to the destination PMD. However, the corresponding withdraw in zap_huge_pmd() is guarded by arch_needs_pgtable_deposit(), which returns false on x86 and powerpc64 radix. This asymmetry causes a 4KB pgtable page and an mm->nr_ptes counter increment to leak on every fork+zap cycle of a special huge PMD on those architectures. Guard the deposit in copy_huge_pmd() with the same arch_needs_pgtable_deposit(dst_vma) check, matching what vmf_insert_pfn_pmd() already does at insertion time and what zap_huge_pmd() does at teardown. Fixes: 923e224a1246 ("mm: introduce remap_pfn_range_try_pmd() for PMD-level hugepage mapping") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/huge_memory.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 805a903d8423..d423824dc67a 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1834,9 +1834,11 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm, pmd = pmdp_get_lockless(src_pmd); if (unlikely(pmd_present(pmd) && pmd_special(pmd))) { - pgtable = pte_alloc_one(dst_mm); - if (unlikely(!pgtable)) - goto out; + if (arch_needs_pgtable_deposit(dst_vma)) { + pgtable = pte_alloc_one(dst_mm); + if (unlikely(!pgtable)) + goto out; + } dst_ptl = pmd_lock(dst_mm, dst_pmd); src_ptl = pmd_lockptr(src_mm, src_pmd); spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING); @@ -1854,8 +1856,10 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm, /* dax won't reach here, it will be intercepted at vma_needs_copy() */ VM_WARN_ON_ONCE(vma_is_dax(src_vma)); - mm_inc_nr_ptes(dst_mm); - pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable); + if (pgtable) { + mm_inc_nr_ptes(dst_mm); + pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable); + } goto set_pmd; } -- 2.43.0

2 1

[PATCH OLK-6.6 1/1] KVM: arm64: Fix kernel panic due to uninitialized fpmr pointer
by Qinxin Xia 13 Oct '26

13 Oct '26

driver inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8904 ---------------------------------------------------------------------- When the hardware implements FEAT_FPMR but CONFIG_ENABLE_KVM_FPMR is not set in the kernel config, starting a VM crashes the host with the following panic: | Unable to handle kernel paging request at virtual address d6d0b7173a7d8b80 | Mem abort info: | ESR = 0x0000000096000044 | EC = 0x25: DABT (current EL), IL = 32 bits | FSC = 0x04: level 0 translation fault | CM = 0, WnR = 1, TnD = 0, TagAccess = 0 | [d6d0b7173a7d8b80] address between user and kernel address ranges | pc : fpsimd_save+0xd0/0x160 | lr : fpsimd_save+0x38/0x160 | Call trace: | fpsimd_save+0xd0/0x160 | fpsimd_save_and_flush_cpu_state+0x34/0xa8 | kvm_arch_vcpu_put_fp+0xf0/0x250 | kvm_arch_vcpu_put+0x44/0xf0 | vcpu_put+0x20/0x50 | kvm_arch_vcpu_ioctl_run+0x70/0x630 | Kernel panic - not syncing: Oops: Fatal exception The root cause is an asymmetric gating of the FPMR context switch introduced when backporting upstream FPMR support: - The consumer side (fpsimd_save()) saves FPMR whenever the hardware capability is detected at runtime: if (system_supports_fpmr()) *(last->fpmr) = read_sysreg_s(SYS_FPMR); - The producer side (kvm_arch_vcpu_ctxsync_fp()) only assigns fp_state.fpmr under #ifdef CONFIG_ENABLE_KVM_FPMR, while the struct cpu_fp_state stack variable is left uninitialized. With the config disabled, fpsimd_bind_state_to_cpu() binds stack garbage into the per-CPU fpsimd_last_state.fpmr, and the first guest exit writes FPMR to this garbage pointer, causing the above level 0 translation fault. Fixes: 17d5edd67293d ("KVM: arm64: Add save/restore support for FPMR") Signed-off-by: Qinxin Xia <xiaqinxin(a)huawei.com> Signed-off-by: Hongye Lin <linhongye(a)h-partners.com> --- arch/arm64/kernel/fpsimd.c | 2 +- arch/arm64/kvm/fpsimd.c | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index a81103cdcbdb..49b5f70f41a5 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -478,7 +478,7 @@ static void fpsimd_save(void) if (test_thread_flag(TIF_FOREIGN_FPSTATE)) return; - if (system_supports_fpmr()) + if (system_supports_fpmr() && last->fpmr) *(last->fpmr) = read_sysreg_s(SYS_FPMR); /* diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c index 90fb893e47ba..0100acc69964 100644 --- a/arch/arm64/kvm/fpsimd.c +++ b/arch/arm64/kvm/fpsimd.c @@ -122,7 +122,7 @@ void kvm_arch_vcpu_ctxflush_fp(struct kvm_vcpu *vcpu) */ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu) { - struct cpu_fp_state fp_state; + struct cpu_fp_state fp_state = { }; WARN_ON_ONCE(!irqs_disabled()); @@ -139,6 +139,8 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu) fp_state.svcr = &vcpu->arch.svcr; #ifdef CONFIG_ENABLE_KVM_FPMR fp_state.fpmr = &__vcpu_sys_reg(vcpu, FPMR); +#else + fp_state.fpmr = NULL; #endif fp_state.fp_type = &vcpu->arch.fp_type; -- 2.33.0

2 1