Re: [PATCH v3 4/7] KVM: x86/xen: Extract delivery of event to vCPU into a separate helper

[David Woodhouse]

On Thu, 2026-08-06 at 00:35 +0200, David Woodhouse wrote:
> > [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@xxxxxxxxxxxxx/
> 
> I owe a refresh and repost of that one.

Hm, it probably wants to live before the RCU part. I think the plan
should be to first send these in parallel as they don't conflict:

 • Patch 1 from this series (the syzbot races).
 • The updated xen series.

Separately, we can remove the non_block_start() from the OOM reaper
path (patch 2 of this series), marking it as fixing the existing KVM
mn_invalidate_lock splat under RT¹.

The actual conversion to RCU (which fixes the GPC RT issues) can be
rebased on top of all of the above, and wait in the wings for a little
while longer until they've landed.

I'll build a 'xen-rcu' branch with that all in a single linear set, and
redo all the testing.


¹ https://lore.kernel.org/all/787aa26cf62dfd361eea8ed19f384fc517892501.camel@xxxxxxxxxxxxx/

Attachment: smime.p7s
Description: S/MIME cryptographic signature