From: Jakub Kicinski <kuba@kernel.org>
To: "Jong eon Park" <jongeon.park@samsung.com>
Cc: "'Paolo Abeni'" <pabeni@redhat.com>,
"'David S. Miller'" <davem@davemloft.net>,
"'Eric Dumazet'" <edumazet@google.com>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
"'Dong ha Kang'" <dongha7.kang@samsung.com>
Subject: Re: [PATCH] netlink: introduce netlink poll to resolve fast return issue
Date: Fri, 10 Nov 2023 11:00:02 -0800 [thread overview]
Message-ID: <20231110110002.7279f895@kernel.org> (raw)
In-Reply-To: <000001da13e5$d9b99e30$8d2cda90$@samsung.com>
On Fri, 10 Nov 2023 23:54:48 +0900 Jong eon Park wrote:
> Interestingly, in this issue, even though netlink overrun frequently
> happened and caused POLLERRs, the user was managing it well through
> POLLIN and 'recv' function without a specific POLLERR handler.
> However, in the current situation, rcv queue is already empty and
> NETLINK_S_CONGESTED flag prevents any more incoming packets. This makes
> it impossible for the user to call 'recv'.
>
> This "congested" situation is a bit ambiguous. The queue is empty, yet
> 'congested' remains. This means kernel can no longer deliver uevents
> despite the empty queue, and it lead to the persistent 'congested' status.
>
> The reason for the difference in netlink lies in the NETLINK_S_CONGESTED
> flag. If it were UDP, upon seeing the empty queue, it might have kept
> pushing the received packets into the queue (making possible to call
> 'recv').
I see, please add a comment saying that NETLINK_S_CONGESTED prevents
new skbs from being queued before the new test in netlink_poll().
Please repost next week (i.e. after the merge window) with subject
tagged [PATCH net-next v2].
next prev parent reply other threads:[~2023-11-10 19:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20231103072245epcas1p4471a31e9f579e38501c8c856d3ca2a77@epcas1p4.samsung.com>
2023-11-03 7:22 ` [PATCH] netlink: introduce netlink poll to resolve fast return issue Jong eon Park
2023-11-06 23:48 ` Jakub Kicinski
2023-11-07 2:05 ` Jong eon Park
2023-11-07 16:53 ` Jakub Kicinski
2023-11-10 14:54 ` Jong eon Park
2023-11-10 19:00 ` Jakub Kicinski [this message]
2023-11-13 3:50 ` Jong eon Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231110110002.7279f895@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dongha7.kang@samsung.com \
--cc=edumazet@google.com \
--cc=jongeon.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).