summaryrefslogtreecommitdiffstats
path: root/device/receive.go
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2021-01-07 15:56:52 +0100
committerJason A. Donenfeld <Jason@zx2c4.com>2021-01-07 17:08:41 +0100
commit29b04775856b62213d7bc01937641e2db081d707 (patch)
tree6044865a29772209154acd59ba7f66274a623403 /device/receive.go
parentdevice: add latency and throughput benchmarks (diff)
downloadwireguard-go-29b04775856b62213d7bc01937641e2db081d707.tar.xz
wireguard-go-29b04775856b62213d7bc01937641e2db081d707.zip
device: receive: drain decryption queue before exiting RoutineDecryption
It's possible for RoutineSequentialReceiver to try to lock an elem after RoutineDecryption has exited. Before this meant we didn't then unlock the elem, so the whole program deadlocked. As well, it looks like the flush code (which is now potentially unnecessary?) wasn't properly dropping the buffers for the not-already-dropped case. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Diffstat (limited to 'device/receive.go')
-rw-r--r--device/receive.go15
1 files changed, 14 insertions, 1 deletions
diff --git a/device/receive.go b/device/receive.go
index 4b6f278..0bd22bf 100644
--- a/device/receive.go
+++ b/device/receive.go
@@ -251,7 +251,20 @@ func (device *Device) RoutineDecryption() {
for {
select {
case <-device.signals.stop:
- return
+ for {
+ select {
+ case elem, ok := <-device.queue.decryption:
+ if ok {
+ if !elem.IsDropped() {
+ elem.Drop()
+ device.PutMessageBuffer(elem.buffer)
+ }
+ elem.Unlock()
+ }
+ default:
+ return
+ }
+ }
case elem, ok := <-device.queue.decryption: