From: Jakub Kicinski <kuba@kernel.org>
To: David Ahern <dsahern@gmail.com>
Cc: Ismael Luceno <iluceno@suse.de>,
"David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: Netlink NLM_F_DUMP_INTR flag lost
Date: Thu, 23 Jun 2022 09:36:09 -0700 [thread overview]
Message-ID: <20220623093609.1b104859@kernel.org> (raw)
In-Reply-To: <bd76637b-0404-12e3-37b6-4bdedd625965@gmail.com>
On Thu, 23 Jun 2022 10:17:17 -0600 David Ahern wrote:
> > Yup, the question for me is what's the risk / benefit of sending
> > the empty message vs putting the _DUMP_INTR on the next family.
> > I'm leaning towards putting it on the next family and treating
> > the entire dump as interrupted, do you reckon that's suboptimal?
>
> I think it is going to be misleading; the INTR flag needs to be set on
> the dump that is affected.
Right, it's a bit of a philosophical discussion but dump is delineated
but NLMSG_DONE. PF_UNSPEC dump is a single dump, not a group of multiple
independent per-family dumps. If we think of a nlmsg as a representation
of an object having an empty one is awkward. What if someone does a dump
to just count objects? Too speculative?
I guess one can argue either way, no empty messages is a weaker promise
and hopefully lower risk, hence my preference. Do you feel strongly for
the message? Do we flip a coin? :)
> All of the dumps should be checking the consistency at the end of the
> dump - regardless of any remaining entries on a particular round (e.g.,
> I mentioned this what the nexthop dump does). Worst case then is DONE
> and INTR are set on the same message with no data, but it tells
> explicitly the set of data affected.
Okay, perhaps we should put a WARN_ON_ONCE(seq && seq != prev_seq)
in rtnl_dump_all() then, to catch those who get it wrong.
next prev parent reply other threads:[~2022-06-23 16:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220615171113.7d93af3e@pirotess>
2022-06-15 16:00 ` Netlink NLM_F_DUMP_INTR flag lost Jakub Kicinski
2022-06-16 15:10 ` 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 [this message]
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=20220623093609.1b104859@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.