code review 11920044: runtime: fix potential deadlock in netpoll on windows

runtime: fix potential deadlock in netpoll on windows
If netpoll has been told to block, it must not return with nil,
otherwise scheduler assumes that netpoll is disabled.

[dvyukov, 2013-07-26 14:37:43]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://dvyukov%40google.com@code.google.com/p/go/

[brainman, 2013-07-27 02:30:44]

LGTM

I assumed that netpollready will always set gp to non nil given it io completion
packet. How is it possible to otherwise? Do you think this could be solution to
our problem?

I haven't seen BSOD but because of faulty drivers or hardware. I am very
surprised with what you are seeing. I will keep looking. I will try and see
again, if I did see CPU 100% or process was just locked like you have described.
Do you think we should disable net test temporarily until we decide what to do
next?

Alex

[dvyukov, 2013-07-27 09:46:47]

*** Submitted as https://code.google.com/p/go/source/detail?r=c3466cad62b0 ***

runtime: fix potential deadlock in netpoll on windows
If netpoll has been told to block, it must not return with nil,
otherwise scheduler assumes that netpoll is disabled.

R=golang-dev, alex.brainman
CC=golang-dev
https://codereview.appspot.com/11920044

[dvyukov, 2013-07-27 09:52:41]

On 2013/07/27 02:30:44, brainman wrote:
> LGTM
> 
> I assumed that netpollready will always set gp to non nil given it io
completion
> packet. How is it possible to otherwise? Do you think this could be solution
to
> our problem?

There a logical race condition between waiter calling netpollblock and netpoll
calling netpollunblock. If the latter happens first, then netpollunblock just
sets the semaphore to READY and returns with nil gp. netpollblock will consume
READY w/o blocking.
The protocol between scheduler and netpoll is that netpoll(block=true) must not
return with nil gp, otherwise scheduler assumes that netpoll is disabled.

Unfortunately it is not the cause of the hang we observe, I've patched it very
early during my investigation (though, it could be).


> I haven't seen BSOD but because of faulty drivers or hardware. I am very
> surprised with what you are seeing. I will keep looking. I will try and see
> again, if I did see CPU 100% or process was just locked like you have
described.

I've seen in goroutine tracebacks that the goroutine is blocked in
WaitCancelled, which means that it has received the timeout.
I've inserted time.Sleep(time.Hour) when the hang is detected and seen with
ProcExplorer that one of the threads is blocked in GQCS, and it also does not
consume CPU during hang.


> Do you think we should disable net test temporarily until we decide what to do
> next?

I've filed https://code.google.com/p/go/issues/detail?id=5971
and disabled the test for now.