LeencyandClaude Opus 5
1159103075
Summary: three paths in tcp_process_input called tcp_close/tcp_drop while still holding the socket's mutex, which socket_free then tries to take itself -- a self-deadlock of the TCP input thread, and, now that socket_free also holds socket_mutex, a freeze of every socket syscall behind it. Подробно: tcp_process_input locks the socket's own mutex right after .found_socket and keeps it for the whole state processing. Three of its paths reached socket_free without releasing it: - data arriving for a terminated process (tcp_close, then a reset reply); - a new SYN arriving in TIME_WAIT (tcp_close, then restart at .findpcb); - a SYN inside the window (tcp_drop, then .drop_with_reset). socket_free has always locked the socket's mutex at its top, and the mutex is not recursive, so these paths hung the TCP input thread the moment they were taken. Since socket_free now also takes socket_mutex first, the hung thread would additionally hold the list lock, stalling every socket syscall in every process -- which is what turned this from a latent bug into one worth fixing on the same branch. Each site now unlocks the socket mutex first, the shape the file already uses in .unlock_and_close and in the refused-connection path of .state_syn_sent. The terminated-process path preserves edx across tcp_close because the reset reply is built from the segment header; the TIME_WAIT path preserves ecx and edx because .findpcb and everything after it still need the data count and the header. The SYN-in-window path now leaves through .drop_no_socket instead of .drop_with_reset: the old exit would have unlocked the freed socket's mutex and built the reply out of freed memory, and the reply itself is redundant -- the connection is synchronized here, so tcp_drop already sends the RST via tcp_output (tcp_outflags for TCPS_CLOSED is RST+ACK). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
KolibriOS
KolibriOS is a hobby operating system for x86-compatible computers, which is currently being developed by a small but passionate team of enthusiasts.
Its kernel, most drivers, and many programs are written entirely in FASM assembly language, making them very compact and lean on system resources.
Based on MenuetOS, it uses its own standards and is NOT fully POSIX or UNIX compliant.
Website
Visit the official KolibriOS website for more information, downloads, and documentation.
Contributing
We would appreciate any participation in the project and always welcome new users and contributors.
Detailed instructions for the contribution process can be found in the contributing guide.
Common list of tasks, issues and enhancement proposals can be found on this page.
Special thanks
The KolibriOS team expresses special thanks to the author of the 32-bit MenuetOS, Ville Turjanmaa. We also want to note that all MenuetOS copyrights have been preserved.