mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-09-02 00:42:22 +00:00
5af3c6ca90
After introducing SO_SNDBUF socket option, a possible deadlock situation
slipped into the TCP implementation. The scenario for the deadlock:
* application thread tries to send some data, it enters
net_context_send() which locks the context mutex,
* internal context_sendto() blocks on a TX packet allocation, if the
TX pool is empty rescheduling takes place,
* now, if at the same time some incoming packet has arrived (ACK for
example), TCP stack enters tcp_in() function from a different
thread. The function locks the TCP connection mutex, and tries to
obtain the SNDBUF option value. net_context_get_option() tries to
lock the context mutex, but it is already held by the transmitting
thread, so the receiver thread blocks
* when TX packet is available again, the transmitting thread unblocks
and tries to pass the packet down to TCP stack. net_tcp_queue_data()
is called which attempts to lock the TCP connection mutex, but it is
already held by the receiving thread. Both threads are in a deadlock
now with no chance to recover.
Fix this, by obtaining the SNDBUF option value in tcp_in() before
locking the TCP connection mutex.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
|
||
|---|---|---|
| .. | ||
| ip | ||
| l2 | ||
| lib | ||
| pkt_filter | ||
| buf.c | ||
| CMakeLists.txt | ||
| hostname.c | ||
| Kconfig | ||
| Kconfig.hostname | ||
| Kconfig.template.log_config.default.net | ||
| Kconfig.template.log_config.net | ||