All of lore.kernel.org
 help / color / mirror / Atom feed
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].

  reply	other threads:[~2023-11-10 19:17 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.