On Wed, 2026-08-05 at 20:47 +0000, sashiko-bot@kernel.org wrote:
> [Severity: High]
> Does this new helper inadvertently bypass the required vCPU kick when the
> vcpu_info cache check fails?

Oops, I frowned at that for doing the kick *within* the RCU read section,
and missed the bug when moving it down. Will fix.

> [Severity: Critical]
> This is a pre-existing issue, but does test_and_set_bit() here risk a
> host denial of service via a hardware split lock?

It does, and likewise for the lockless double read of long_mode
reported against v2 patch 7¹: max_evtchn_port() and the branch below it
can disagree, in which case port_word_bit can be up to 127 and the
test_and_set_bit() runs off the end of evtchn_pending_sel.

I knew I'd looked at those both before... they're both covered by the
series I posted in June:

  https://lore.kernel.org/all/20260605143034.3603-1-dwmw2@infradead.org/

I owe a refresh and repost of that one.




¹ https://lore.kernel.org/all/20260529174710.29CB31F00893@smtp.kernel.org/
[unhandled content-type:application/pkcs7-signature]