From: Jakub Kicinski <kuba@kernel.org>
To: Ismael Luceno <iluceno@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>, David Ahern <dsahern@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: Netlink NLM_F_DUMP_INTR flag lost
Date: Wed, 15 Jun 2022 09:00:44 -0700 [thread overview]
Message-ID: <20220615090044.54229e73@kernel.org> (raw)
In-Reply-To: <20220615171113.7d93af3e@pirotess>
CC: netdev ML
On Wed, 15 Jun 2022 17:11:13 +0200 Ismael Luceno wrote:
> It seems a RTM_GETADDR request with AF_UNSPEC has a corner case where
> the NLM_F_DUMP_INTR flag is lost.
>
> After a change in an address table, if a packet has been fully filled
> just previous, and if the end of the table is found at the same time,
> then the next packet should be flagged, which works fine when it's
> NLMSG_DONE, but gets clobbered when another table is to be dumped next.
Could you describe how it gets clobbered? You mean that prev_seq gets
updated somewhere without setting the flag or something overwrites
nlmsg_flags? Or we set _INTR on an empty skb which never ends up
getting sent? Or..
> A customer noticed the issue using kubernetes, when a large
> number of short-lived containers would push the system constantly
> towards this corner case.
>
> I'm entertaining the following options:
>
> 1) introduce a new packet type just to convey flags in cases like this.
> 2) preserve the flag and apply it to the NLMSG_DONE packet.
> 3) flag the first packet of the following table.
>
> I don't like option 2 and 3 because we can't tell which table is
> affected, which I'm guessing programs might be relying on.
>
> Option 1 adds a little bit of overhead, but enables us to tell which
> table is affected, and can be ignored by existing software that doesn't
> understand it, so IMHO it's the least disruptive option.
>
> I want to have a little discussion before introducing a patch, since
> option 1 might have other implications I'm not aware of...
next parent reply other threads:[~2022-06-15 16:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220615171113.7d93af3e@pirotess>
2022-06-15 16:00 ` Jakub Kicinski [this message]
2022-06-16 15:10 ` Netlink NLM_F_DUMP_INTR flag lost Ismael Luceno
2022-06-17 0:16 ` Jakub Kicinski
2022-06-17 13:01 ` Ismael Luceno
2022-06-17 14:55 ` David Ahern
2022-06-17 15:22 ` Jakub Kicinski
2022-06-17 16:17 ` David Ahern
2022-06-17 16:28 ` David Ahern
2022-08-24 10:59 ` Ismael Luceno
2022-08-24 11:46 ` Florian Westphal
2022-06-22 11:12 ` Ismael Luceno
2022-06-22 23:55 ` Jakub Kicinski
2022-06-23 4:01 ` David Ahern
2022-06-23 16:03 ` Jakub Kicinski
2022-06-23 16:17 ` David Ahern
2022-06-23 16:36 ` Jakub Kicinski
2022-06-23 17:31 ` David Ahern
2022-06-23 19:03 ` Jakub Kicinski
2022-06-28 19:38 ` Ismael Luceno
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=20220615090044.54229e73@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=iluceno@suse.de \
--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.