Re: [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush fib

[Ido Schimmel <idosch@idosch.org>]

On Fri, Jul 21, 2023 at 01:46:13PM +0800, Hangbin Liu wrote:
> On Thu, Jul 20, 2023 at 10:01:06PM -0600, David Ahern wrote:
> > >>> How about ignore route deletion for link down? e.g.
> > >>>
> > >>> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> > >>> index 74d403dbd2b4..11c0f325e887 100644
> > >>> --- a/net/ipv4/fib_trie.c
> > >>> +++ b/net/ipv4/fib_trie.c
> > >>> @@ -2026,6 +2026,7 @@ void fib_table_flush_external(struct fib_table *tb)
> > >>>  int fib_table_flush(struct net *net, struct fib_table *tb, bool flush_all)
> > >>>  {
> > >>>         struct trie *t = (struct trie *)tb->tb_data;
> > >>> +       struct nl_info info = { .nl_net = net };
> > >>>         struct key_vector *pn = t->kv;
> > >>>         unsigned long cindex = 1;
> > >>>         struct hlist_node *tmp;
> > >>> @@ -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.

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.