wintun/api, branch master

driver: fix missed-wakeup race in ring buffer Alertable signaling

2026-03-18T17:49:30Z

Add MemoryBarrier() between store-load pairs in the Dekker-style synchronization used by the Receive ring's Alertable/Tail protocol. On x86-64, WriteRelease/ReadAcquire only prevent compiler reordering and provide acquire/release semantics, but do not emit MFENCE — the only instruction that prevents store-load reordering across cores. Without a full barrier, both the userspace producer and the kernel consumer can simultaneously read stale values: Userspace: STORE(Tail) ... LOAD(Alertable) -> sees FALSE (stale) Driver: STORE(Alertable=TRUE) ... LOAD(Tail) -> sees old tail The driver then enters KeWaitForMultipleObjects with no pending SetEvent, sleeping until a TCP retransmission (typically 4-5s later) re-triggers the send path and wins the race. The fix adds MemoryBarrier() (MFENCE on x86) on both sides: - api/session.c WintunSendPacket: between WriteULongRelease(Tail) and ReadAcquire(Alertable) - driver/twintun.c TunProcessReceiveData: between WriteRelease(Alertable, TRUE) and ReadULongAcquire(Tail) This guarantees that at least one side always observes the other's store, preventing the missed wakeup while preserving the Alertable optimization that avoids unnecessary SetEvent syscalls. Reported-by: Alexey Lapuka Reference: https://lists.zx2c4.com/pipermail/wireguard/2026-February/009523.html Signed-off-by: Simon Rozman

doc: fix WintunReceivePacket name

2026-02-09T10:24:51Z

There is no `WintunReceivePackets`. Just `WintunReceivePacket`. Signed-off-by: Simon Rozman

api: header: silence MSVC warnings for MSVC only

2021-12-03T08:17:19Z

MinGW ignores unknown `#pragma warning` lines, but displays a warning nevertheless. Signed-off-by: Simon Rozman

api: main: avoid excessive function cast

2021-10-15T00:43:52Z