Fix r356919.

[kib]

Summary

Instead of waiting for pc_curthread which is overwritten by init_secondary_tail(), wait for pc_curpcb.
Assert that pc_curpcb is not set too early.

Reported by: rlibby

[markj]

Isn't curpcb set while still on the old stack? We load the new rsp after setting curpcb. In fact, the same is true for curthread, I didn't notice it before.

[kib]

In D23330#511542, @markj wrote:

Isn't curpcb set while still on the old stack? We load the new rsp after setting curpcb. In fact, the same is true for curthread, I didn't notice it before.

You mean that %rsp points to the old stack. cpu_switch does not access it at all after the old thread is unblocked. It must be because old thread might already start executing on another CPU. Interrupts are disabled, and non-maskable interrupts like NMI or MCE use non-zero ist.

[markj]

In D23330#511544, @kib wrote:

In D23330#511542, @markj wrote:

Isn't curpcb set while still on the old stack? We load the new rsp after setting curpcb. In fact, the same is true for curthread, I didn't notice it before.

You mean that %rsp points to the old stack. cpu_switch does not access it at all after the old thread is unblocked. It must be because old thread might already start executing on another CPU. Interrupts are disabled, and non-maskable interrupts like NMI or MCE use non-zero ist.

I see, thanks.

[rlibby]

Looks good. Thanks. I applied this patch and rebooted about ten times and saw no issues (previous frequency for me was maybe 1/3).