[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.