Re: propagating vmgenid outward and upward

["Jason A. Donenfeld" <Jason@zx2c4.com>]

Hey Alex,

On Thu, Mar 10, 2022 at 12:18 PM Alexander Graf <graf@amazon.com> wrote:
> I agree on the slightly racy compromise and that it's a step into the
> right direction. Doing this is a no brainer IMHO and I like the proc
> based poll approach.

Alright. I'm going to email a more serious patch for that in the next
few hours and you can have a look. Let's do that for 5.19.

> I have an additional problem you might have an idea for with the poll
> based path. In addition to the clone notification, I'd need to know at
> which point everyone who was listening to a clone notification is
> finished acting up it. If I spawn a tiny VM to do "work", I want to know
> when it's safe to hand requests into it. How do I find out when that
> point in time is?

Seems tricky to solve. Even a count of current waiters and a
generation number won't be sufficient, since it wouldn't take into
account users who haven't _yet_ gotten to waiting. But maybe it's not
the right problem to solve? Or somehow not necessary? For example, if
the problem is a bit more constrained a solution becomes easier: you
have a fixed/known set of readers that you know about, and you
guarantee that they're all waiting before the fork. Then after the
fork, they all do something to alert you in their poll()er, and you
count up how many alerts you get until it matches the number of
expected waiters. Would that work? It seems like anything more general
than that is just butting heads with the racy compromise we're already
making.

Jason