_utmx_op: don't recurse on chain busy

[kevans]

Summary

In handling a PP mutex, we'll busy it as soon as we enter the loop and
unbusy it either prior to sleeping or at exit time. In this particular
case, if we fail to transition the mutex from OWNERDEAD -> owned because
of casueword(9) failure and the suspend check fails, we'll start over
and attempt to busy an already-busied chain and irrecoverably lock up
both this thread and anything else that tries to busy the chain.

Unbusy the chain prior to restarting because I couldn't decide if that
was a better or worse idea than just keeping track of whether we dirtied
it in do_lock_pp() and avoiding re-dirty. This is marginally easier to
reason about as it returns us to expected state on entry to thw loop.

[olce]

Unbusy the chain prior to restarting because I couldn't decide if (...)

I suspect it is marginally better to do that, as if the thread lost the race, some other revived the mutex, probably to lock it, and has thus been running enough to have a more up-to-date view of its (and surrounding) state. In any case, I agree the code is easier to grasp like that.

sys/kern/kern_umtx.c

2608–2617

This is unrelated to your changes here, but since the setting of error to EBUSY here is never observed (as error is then reset to 0 unconditionally), I'd suggest simplifying the code while here.