All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Andy Chiu" <tchiu@tenstorrent.com>
Cc: linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH v2 2/3] riscv: vector: allow non-preemptible kernel-mode vector with IRQs off
Date: Wed, 15 Jul 2026 05:32:20 +0000	[thread overview]
Message-ID: <20260715053221.148C81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260715051629.1169645-3-tchiu@tenstorrent.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Exported `get_cpu_vector_context` and `put_cpu_vector_context` dynamically evaluate `irqs_disabled()` to balance `local_bh_disable()` and `local_bh_enable()`. If a caller alters the IRQ state between the two calls, it will lead to preempt count corruption.
--

--- Patch [2]: [PATCH v2 2/3] riscv: vector: allow non-preemptible kernel-mode vector with IRQs off ---
commit cfe6cf4c78a9ea0fadcde3b4c39aafb48ebeaec6
Author: Andy Chiu <tchiu@tenstorrent.com>

riscv: vector: allow non-preemptible kernel-mode vector with IRQs off

This commit updates get_cpu_vector_context and put_cpu_vector_context to
conditionally disable and enable bottom halves based on whether interrupts
are disabled. It also exports these symbols so they can be used by the KVM
module, specifically for kvm_arch_vcpu_load and put.

> diff --git a/arch/riscv/kernel/kernel_mode_vector.c b/arch/riscv/kernel/kernel_mode_vector.c
> index 307ac369c3d4a..6627e1a82e19e 100644
> --- a/arch/riscv/kernel/kernel_mode_vector.c
> +++ b/arch/riscv/kernel/kernel_mode_vector.c
[ ... ]
> @@ -55,13 +55,16 @@ void get_cpu_vector_context(void)
>  	 * disable softirqs so it is impossible for softirqs to nest
>  	 * get_cpu_vector_context() when kernel is actively using Vector.
>  	 */
> -	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> -		local_bh_disable();
> -	else
> +	if (!IS_ENABLED(CONFIG_PREEMPT_RT)) {
> +		if (!irqs_disabled())
> +			local_bh_disable();
> +	} else {
>  		preempt_disable();
> +	}
>  
>  	riscv_v_start(RISCV_KERNEL_MODE_V);
>  }
> +EXPORT_SYMBOL_GPL(get_cpu_vector_context);
>  
>  /*
>   * Release the CPU vector context.
> @@ -74,11 +77,14 @@ void put_cpu_vector_context(void)
>  {
>  	riscv_v_stop(RISCV_KERNEL_MODE_V);
>  
> -	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> -		local_bh_enable();
> -	else
> +	if (!IS_ENABLED(CONFIG_PREEMPT_RT)) {
> +		if (!irqs_disabled())
> +			local_bh_enable();
> +	} else {

[Severity: High]
Does dynamically checking irqs_disabled() in both get_cpu_vector_context()
and put_cpu_vector_context() risk corrupting the preempt count if the IRQ
state changes between the two calls?

The commit message mentions these are intended for kvm_arch_vcpu_load() and
kvm_arch_vcpu_put(). If KVM calls vcpu_load() during sched_in with IRQs
enabled, get_cpu_vector_context() will call local_bh_disable().

If it later calls vcpu_put() during sched_out with IRQs disabled,
put_cpu_vector_context() will skip local_bh_enable().

Will this permanently leak the BH disable count on every context switch?

>  		preempt_enable();
> +	}
>  }
> +EXPORT_SYMBOL_GPL(put_cpu_vector_context);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715051629.1169645-1-tchiu@tenstorrent.com?part=2

  reply	other threads:[~2026-07-15  5:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15  5:16 [PATCH v2 0/3] RISC-V: KVM: fix vcpu vector context handling Andy Chiu
2026-07-15  5:16 ` Andy Chiu
2026-07-15  5:16 ` Andy Chiu
2026-07-15  5:16 ` [PATCH v2 1/3] riscv: vector: refactor riscv_v_start_kernel_context Andy Chiu
2026-07-15  5:16   ` Andy Chiu
2026-07-15  5:16 ` [PATCH v2 2/3] riscv: vector: allow non-preemptible kernel-mode vector with IRQs off Andy Chiu
2026-07-15  5:16   ` Andy Chiu
2026-07-15  5:16   ` Andy Chiu
2026-07-15  5:32   ` sashiko-bot [this message]
2026-07-15  5:16 ` [PATCH v2 3/3] RISC-V: KVM: fix vcpu vector context handling for kernel-mode vector Andy Chiu
2026-07-15  5:16   ` Andy Chiu
2026-07-15  5:16   ` Andy Chiu
2026-07-15  5:34   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260715053221.148C81F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tchiu@tenstorrent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.