Re: [Xen-devel] [PATCH] schedule: mask out XEN_RUNSTATE_UPDATE from state entry time

[Andrii Anisov <andrii.anisov@xxxxxxxxx>]

Hello Jan,

On 18.07.19 18:04, Jan Beulich wrote:
> On 18.07.2019 16:12, Andrii Anisov wrote:
> > The scenario is quite trivial: some vcpu uptdating its runstate values
> > (e.g. context switching) while those values are being read by a guest using
> > other vcpu.
> Well, that's (afaia) not an intended usage scenario. That's specifically
> what the XEN_RUNSTATE_UPDATE flag was introduced for: This way guests
> can notice that they shouldn't use the values, as they're likely
> inconsistent. They'd pause for a brief moment and make another attempt;
> see Linux'es xen_get_runstate_snapshot_cpu_delta().
OK, I did this patch a while ago and wrongly recalled the scenario.
The race occurs when some vcpu was just scheduled out in RUNSTATE_blocked. 
Going down by schedule path it enters `update_runstate_area(prev)`, and, at 
this moment, it is kicked by `vcpu_wake()` from other PCPU.

> But neither from the code change nor from the description I would have
> implied that it's a guest side problem you're trying to address. So
> far I was assuming you had found a race in Xen itself.
As I describe above the race is in XEN itself. Yet it has no practical impact 
on the system at this moment.
This patch does fix the race in XEN, but breaks what was fixed by 
XEN_RUNSTATE_UPDATE. So I have to recall it.

> > > Considering the value of XEN_RUNSTATE_UPDATE it must be a rather rare race
> > > anyway, I would guess.
> > I'm not sure how do you link the value of XEN_RUNSTATE_UPDATE and the issue
> > occurrence rate. Could you please provide more details about the idea?
> The value is huge, hence it being wrongly part of a calculation ought to
> be easily noticeable _if_ it occurred often enough.
Well, the `delta` value become negative, so it is not accumulated into the 
current runstate time and the new runstate entry time is not updated.
While we currently seeing this effect for blocked-to-runnable transition only, 
it can be ignored.

--
Sincerely,
Andrii Anisov.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel