There are several code paths inside network stack which cause repeated lock→ unlock→ relock of the socket mutex.
Not only is it inefficient, another thread could sneak in between the calls causing various havoc.
When the lock is re-acquired, the state of the socket might have changed, or it might even no longer exist.
The following problematic sequences have been identified:
There are several code paths inside network stack which cause repeated lock→ unlock→ relock of the socket mutex.
Not only is it inefficient, another thread could sneak in between the calls causing various havoc.
When the lock is re-acquired, the state of the socket might have changed, or it might even no longer exist.
The following problematic sequences have been identified:
| Location | Pattern | Risk |
| --- | --- | --- |
| Accept / socket_fork | Unlock listening socket → create+lock child | Race on listening socket while fork runs |
| Various entry points (e.g. tcp_input) | unlock → tcp_output → relock | state altered before output |
| Pure-ACK header prediction | Unlock → notify → tcp_output → never relock | Window after unlock |
| tcp_close call sites | Unlock → tcp_close | Depends on whether tcp_close re-locks |
| Various .drop* / final paths | Unlock and leave | Lifetime window (to be fixed by #606) |
| socket_ring_read | Unlock before copy | Data race on the ring (to be fixed by #606) |
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
There are several code paths inside network stack which cause repeated lock→ unlock→ relock of the socket mutex.
Not only is it inefficient, another thread could sneak in between the calls causing various havoc.
When the lock is re-acquired, the state of the socket might have changed, or it might even no longer exist.
The following problematic sequences have been identified: