On Mon, Aug 03, 2026 at 04:11:24PM +1000, David Gibson wrote:
> On Fri, Jul 31, 2026 at 06:23:24PM +0200, Laurent Vivier wrote:
> > Move the static flow_timer_run variable out of flow.c and pass it as a
> > parameter to flow_defer_handler().  This allows each caller to maintain
> > its own timer state: each vhost-user queue pair worker uses the per-qpair
> > context.
> > 
> > Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> 
> One small misgiving about this, although I doubt it can cause a real
> problem.  Becayse this timer processing now doesn't happen all at
> once, at each queue is on a separate timer cycle, it's theoretically
> possible for a flow to change qpair every FLOW_TIMER_INTERVAL and
> thereby indefinitely avoid having the timer running on it.
> 
> It's pretty tricky to do (depending on how close in real time each
> queue's timers end up running), and I don't *think* that can do
> anything terribly bad (maybe delay cleanup).  But since the guest
> could in principle control the qpair placements to specifically
> trigger this, it just makes me think it warrants a good close look to
> make sure that something bad can't be triggered that way.

Looking at the next patch, I realised there's a much easier to hit
concern here.  Kind of the opposite of the one above, if there's a
migration at the wrong moment, we might run the timer twice on a flow
in a much smaller interval than usual.  AFAICT, the worst that can do
- at least with our current flow_defer() and flow_timer() functions is
a little bit of unnecessary work, so I think it's ok.  That's because
none of them unconditionally do anything damaging - they always check
an independent timestamp.

However, it does add another wrinkle to what is and isn't safe in the
defer and timer functions: they cannot rely on being called at most
every INTERVAL seconds.  We should probably document
that... somewhere.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson