Jason A. Donenfeld e329f488d5 driver: socket: defer WskInit until sockets are actually created ...

It turns out that MINIPORT_INITIALIZE can actually delay system load,
and we currently have reports of people's systems hanging indefinitely.
WskCaptureNPI is known to deadlock if called too early in boot (say,
from DriverEntry of a PnP driver), but it was thought that
MINIPORT_INITIALIZE was sufficiently late that it was okay. Perhaps that
assumption is incorrect. In case it is, this patch moves WSK
initialization to when sockets are created, which always happens in the
context of a user thread, which naturally happens late in boot and can
block.

We know empirically that MINIPORT_INITIALIZE can block system boot, by
adding a `KeDelayExecutionThread(KernelMode, FALSE, &(LARGE_INTEGER){
.QuadPart = -SEC_TO_SYS_TIME_UNITS(300) });` to the top and noting that
boot takes 5 minutes longer. So the theory that the assumption is
incorrect is at least plausible.

All this commit does is move the call to WskInit() from InitializeEx in
device.c to SocketInit() in socket.c. The diff looks more verbose than
it is because making WskInit static and removing its forward declaration
required shuffling some functions around in socket.c, but no code
changed during that shuffle.

Reported-by: Oliver Freyermuth <freyermuth@physik.uni-bonn.de>
Reported-by: Joshua Sjoding <joshua.sjoding@scjalliance.com>
Reported-by: John-Paul Andreini <jandreini@geonerco.com>
Reported-by: Arlo Clauser <Arlo@starcubedesign.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

2021-09-24 12:39:10 -06:00

40 KiB

Raw Permalink Blame History

View Raw