Further Elaboration on this patch

[Qingjie Xing <xqjcool@gmail.com>]

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.