All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hangbin Liu <liuhangbin@gmail.com>
To: Ido Schimmel <idosch@idosch.org>
Cc: David Ahern <dsahern@kernel.org>,
	Stephen Hemminger <stephen@networkplumber.org>,
	netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Thomas Haller <thaller@redhat.com>
Subject: Re: [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush fib
Date: Mon, 24 Jul 2023 16:56:37 +0800	[thread overview]
Message-ID: <ZL48xbowL8QQRr9s@Laptop-X1> (raw)
In-Reply-To: <ZLzY42I/GjWCJ5Do@shredder>

On Sun, Jul 23, 2023 at 10:38:11AM +0300, Ido Schimmel wrote:
> > > >>> @@ -2088,6 +2089,11 @@ int fib_table_flush(struct net *net, struct fib_table *tb, bool flush_all)
> > > >>>
> > > >>>                         fib_notify_alias_delete(net, n->key, &n->leaf, fa,
> > > >>>                                                 NULL);
> > > >>> +                       if (!(fi->fib_flags & RTNH_F_LINKDOWN)) {
> > > >>> +                               rtmsg_fib(RTM_DELROUTE, htonl(n->key), fa,
> > > >>> +                                         KEYLENGTH - fa->fa_slen, tb->tb_id, &info, 0);
> > > >>> +                       }
> > > >>
> > > >> Will you get a notification in this case for 198.51.100.0/24?
> > > > 
> > > > No. Do you think it is expected with this patch or not?
> > > 
> > > The intent is that notifications are sent for link events but not route
> > > events which are easily deduced from the link events.
> > 
> > Sorry, I didn't get what you mean. The link events should be notified to user
> > via rtmsg_ifinfo_event()? So I think here we ignore the route events caused by
> > link down looks reasonable.
> 
> The route in the scenario I mentioned wasn't deleted because of a link
> event, but because the source address was deleted yet no notification
> was emitted. IMO, this is wrong given the description of the patch.

OK. I got what you mean now. Is there a way to get the device the route
bond in fib_table_flush() so we can also check the dev flag?

> 
> I assume NetworkManager already knows how to delete routes given
> RTM_DELLINK events. Can't it be taught to react to RTM_DELADDR events as
> well? Then this functionality will always work, regardless of the kernel
> version being used.

The NetworkManager keeps a cache of the routes. Missing/Wrong events mean that
the cache becomes inconsistent. The IPv4 will not send src route delete info
if it's bond to other device. While IPv6 only modify the src route instead of
delete it, and also no notify. So NetworkManager developers complained and
hope to have a consistent and clear notification about route modify/delete.

Thanks
Hangbin

  reply	other threads:[~2023-07-24  8:56 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-18  8:00 [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush fib Hangbin Liu
2023-07-18 10:19 ` Ido Schimmel
2023-07-18 10:32   ` Ido Schimmel
2023-07-18 14:45     ` David Ahern
2023-07-18 15:58   ` Stephen Hemminger
2023-07-20  7:51     ` Hangbin Liu
2023-07-20 14:29       ` Ido Schimmel
2023-07-21  1:34         ` Hangbin Liu
2023-07-21  4:01           ` David Ahern
2023-07-21  5:46             ` Hangbin Liu
2023-07-23  7:38               ` Ido Schimmel
2023-07-24  8:56                 ` Hangbin Liu [this message]
2023-07-24 15:48                   ` Stephen Hemminger
2023-07-25  8:20                     ` Hangbin Liu
2023-07-25 16:36                       ` Stephen Hemminger
2023-07-28 13:01                         ` Nicolas Dichtel
2023-07-28 15:42                           ` David Ahern
2023-08-02  9:10                             ` Thomas Haller
2023-08-08  1:44                               ` David Ahern
2023-08-08 18:59                                 ` Benjamin Poirier
2023-09-11  9:50                                   ` Thomas Haller
2023-09-13  7:58                                     ` Nicolas Dichtel
2023-09-13  9:54                                       ` Hangbin Liu
2023-09-13 14:11                                         ` Nicolas Dichtel
2023-09-13 14:43                                           ` David Ahern
2023-09-13 14:53                                             ` Nicolas Dichtel
2023-09-14 15:43                                               ` Nicolas Dichtel
2023-09-15  3:07                                                 ` David Ahern
2023-09-15 15:54                                                   ` Nicolas Dichtel
2023-09-13 14:41                                       ` David Ahern
2023-09-15 16:59                                         ` Stephen Hemminger
2023-07-26 10:17                     ` [Questions] Some issues about IPv4/IPv6 nexthop route (was Re: [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush fib) Hangbin Liu
2023-07-26 15:57                       ` David Ahern
2023-07-27  4:19                         ` [Questions] Some issues about IPv4/IPv6 nexthop route Hangbin Liu
2023-07-27 15:35                           ` David Ahern
2023-07-27 14:45                       ` [Questions] Some issues about IPv4/IPv6 nexthop route (was Re: [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush fib) Ido Schimmel
2023-08-28  7:53                         ` [Questions] Some issues about IPv4/IPv6 nexthop route Hangbin Liu
2023-08-28 15:06                           ` David Ahern
2023-08-29  1:07                             ` Hangbin Liu
2023-08-29  1:42                               ` David Ahern
2023-08-02  9:06                 ` [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush fib Thomas Haller
2023-08-04  8:09                 ` Hangbin Liu
2023-08-09  7:06                   ` Ido Schimmel
2023-08-09 10:02                     ` Hangbin Liu
2023-07-25 14:13 ` kernel test robot

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=ZL48xbowL8QQRr9s@Laptop-X1 \
    --to=liuhangbin@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=idosch@idosch.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stephen@networkplumber.org \
    --cc=thaller@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.