We currently have a potential (albeit unlikely) liveness bug in the net stack task protocol. It goes like this:
A task attempts to send a packet.
The net stack reports that the socket's outgoing queue is full and the task should try again later.
The task begins waiting for the queue-available notification.
The net stack crashes and restarts, losing its table of which tasks are owed a notification.
It sees all queues as having available space and goes on about its business.
The task will only be woken up when it next receives a packet.
After discussion with @mkeeter I think the simplest way of addressing this is to change the protocol slightly. Specifically:
On net restart, all tasks should be treated as waiting_to_send.
This will cause net to distribute a notification to all sockets on restart. Since we treat notifications as potentially spurious, the worst that this will do is cause the clients to wake up briefly and do unnecessary checking before going back to sleep. But, if a task was waiting for available TX queue space, this would cause it to discover its queues empty and make forward progress again.
We currently have a potential (albeit unlikely) liveness bug in the net stack task protocol. It goes like this:
The task will only be woken up when it next receives a packet.
After discussion with @mkeeter I think the simplest way of addressing this is to change the protocol slightly. Specifically:
On
net
restart, all tasks should be treated aswaiting_to_send
.This will cause
net
to distribute a notification to all sockets on restart. Since we treat notifications as potentially spurious, the worst that this will do is cause the clients to wake up briefly and do unnecessary checking before going back to sleep. But, if a task was waiting for available TX queue space, this would cause it to discover its queues empty and make forward progress again.