Re: [PATCH v0.9.1 3/6] sched/umcg: implement UMCG syscalls

On Mon, Dec 06, 2021 at 12:32:22PM +0100, Peter Zijlstra wrote:

On Mon, Nov 29, 2021 at 03:38:38PM -0800, Peter Oskolkov wrote:

quoted

On Mon, Nov 29, 2021 at 1:08 PM Peter Zijlstra [off-list ref] wrote:

Now, the above situation is actually simple to fix, but it gets more
interesting when we're using sys_umcg_wait() to build wait primitives.
Because in that case we get stuff like:

	for (;;) {
		self->state = RUNNABLE;
		smp_mb();
		if (cond)
			break;
		sys_umcg_wait();
	}
	self->state = RUNNING;

And we really need to not block and also not do sys_umcg_wait() early.

So yes, I agree that we need a special case here that ensures
umcg_notify_resume() doesn't block. Let me ponder naming and comments.
Either a TF_COND_WAIT or a whole new state. I can't decide yet.

Hurmph... OTOH since self above hasn't actually done anything yet, it
isn't reported as runnable yet, and so for all intents and purposes the
userspace state thinks it's running (which is true) and nobody should be
trying a concurrent wakeup and there anre't any races.

Bah, now I'm confused again :-) Let me go think more.