All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>, Ismael Luceno <iluceno@suse.de>
Cc: "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: Wed, 22 Jun 2022 22:01:37 -0600	[thread overview]
Message-ID: <fef8b8d5-e07d-6d8f-841a-ead4ebee8d29@gmail.com> (raw)
In-Reply-To: <20220622165547.71846773@kernel.org>

On 6/22/22 5:55 PM, Jakub Kicinski wrote:
> On Wed, 22 Jun 2022 13:12:18 +0200 Ismael Luceno wrote:
>> So, just for clarification:
>>
>> Scenario 1:
>> - 64 KB packet is filled.
>> - protocol table shrinks
>> - Next iteration finds it's done
>> - next protocol clears the seq, so nothing is flaged
>> - ...
>> - NLMSG_DONE (not flagged)
>>
>> Scenario 2:
>> - 64 KB packet is filled.
>> - protocol table shrinks
>> - Next iteration finds it's done
>> - NLMSG_DONE (flagged with NLM_F_DUMP_INTR)
>>
>> So, in order to break as little as possible, I was thinking about
>> introducing a new packet iff it happens we have to signal INTR between
>> protocols.
>>
>> Does that sound good?
> 
> Right, the question is what message can we introduce here which would
> not break old user space?

I would hope a "normal" message with just the flags set is processed by
userspace. iproute2 does - lib/libnetlink.c, rtnl_dump_filter_l(). It
checks the nlmsg_flags first.

> 
> The alternative of not wiping the _DUMP_INTR flag as we move thru
> protocols seems more and more appealing, even tho I was initially
> dismissive.
> 
> We should make sure we do one last consistency check before we return 0
> from the handlers. Or even at the end of the loop in rtnl_dump_all().

Seems like netlink_dump_done should handle that for the last dump?

That said, in rtnl_dump_all how about a flags check after dumpit() and
send the message if INTR is set? would need to adjust the return code of
rtnl_dump_all so netlink_dump knows the dump is not done yet.



  reply	other threads:[~2022-06-23  4:41 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 [this message]
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=fef8b8d5-e07d-6d8f-841a-ead4ebee8d29@gmail.com \
    --to=dsahern@gmail.com \
    --cc=davem@davemloft.net \
    --cc=iluceno@suse.de \
    --cc=kuba@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.