Messages in this thread | | | From | Qingjie Xing <> | Subject | Further Elaboration on this patch | Date | Wed, 23 Aug 2023 09:43:34 -0700 |
| |
First of all, I'd like to apologize for the duplication of emails. I'm sorry for any inconvenience this may have caused.
It's important to emphasize that this fix primarily addresses an anomaly in the behavior of `netlink_rcv_wake()` and `netlink_overrun()` when dealing with the `NETLINK_S_CONGESTED` flag. This issue only arises when the --sk->sk_receive_queue-- is empty.
This situation occurs when `netlink_recvmsg()` completes the reception of the last packet in the sk->sk_receive_queue, leaving it empty. Within netlink_rcv_wake()`, the `NETLINK_S_CONGESTED` flag is cleared. However, concurrently, `netlink_overrun()` proceeds to set the `NETLINK_S_CONGESTED` flag again.
In this specific scenario, due to the `NETLINK_S_CONGESTED` flag being set, packets sent to this socket cannot be added to the sk->sk_receive_queue. Because the sk->sk_receive_queue is empty, the `EPOLLIN` flag, which is monitored by the `poll()` call, won't be set. Consequently, further calls to `netlink_recvmsg()` will not be triggered.
When the sk->sk_receive_queue is not empty, or when concurrent actions lead to the non-emptiness of sk->sk_receive_queue, these situations will not pose a problem. This is because as long as there are packets in the sk->sk_receive_queue, the `netlink_recvmsg()` function will be invoked continuously until the queue becomes empty. Only when the sk->sk_receive_queue becomes empty, the `netlink_rcv_wake()` function will attempt once again to clear the `NETLINK_S_CONGESTED` flag. Therefore, we only need to consider the scenario described above, where the sk->sk_receive_queue is empty.
| |