lkml.org 
[lkml]   [2023]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectFurther Elaboration on this patch
Date
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.

\
 
 \ /
  Last update: 2023-08-23 18:47    [W:0.043 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site