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: Fri, 4 Aug 2023 16:09:08 +0800 [thread overview]
Message-ID: <ZMyyJKZDaR8zED8j@Laptop-X1> (raw)
In-Reply-To: <ZLzY42I/GjWCJ5Do@shredder>
On Sun, Jul 23, 2023 at 10:38:11AM +0300, Ido Schimmel wrote:
> > > >> 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.
>
Hi Ido,
I reconsidered this issue this week. As we can't get the device status in
fib_table_flush(). How about adding another flag to track the deleted src
entries. e.g. RTNH_F_UNRESOLVED. Which is only used in ipmr currently.
When the src route address is deleted, the route entry also could be
considered as unresolved. With this idea, the patch could be like:
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 51c13cf9c5ae..5c41d34ab447 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -420,7 +420,7 @@ struct rtnexthop {
#define RTNH_F_ONLINK 4 /* Gateway is forced on link */
#define RTNH_F_OFFLOAD 8 /* Nexthop is offloaded */
#define RTNH_F_LINKDOWN 16 /* carrier-down on nexthop */
-#define RTNH_F_UNRESOLVED 32 /* The entry is unresolved (ipmr) */
+#define RTNH_F_UNRESOLVED 32 /* The entry is unresolved (ipmr/dead src) */
#define RTNH_F_TRAP 64 /* Nexthop is trapping packets */
#define RTNH_COMPARE_MASK (RTNH_F_DEAD | RTNH_F_LINKDOWN | \
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 65ba18a91865..a7ef21a6d271 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1883,7 +1883,7 @@ int fib_sync_down_addr(struct net_device *dev, __be32 local)
fi->fib_tb_id != tb_id)
continue;
if (fi->fib_prefsrc == local) {
- fi->fib_flags |= RTNH_F_DEAD;
+ fi->fib_flags |= (RTNH_F_DEAD | RTNH_F_UNRESOLVED);
ret++;
}
}
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 74d403dbd2b4..88c593967063 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_UNRESOLVED) {
+ fi->fib_flags &= ~RTNH_F_UNRESOLVED;
+ rtmsg_fib(RTM_DELROUTE, htonl(n->key), fa,
+ KEYLENGTH - fa->fa_slen, tb->tb_id, &info, 0);
+ }
hlist_del_rcu(&fa->fa_list);
fib_release_info(fa->fa_info);
alias_free_mem_rcu(fa);
Thanks
Hangbin
next prev parent reply other threads:[~2023-08-04 8:09 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
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 [this message]
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=ZMyyJKZDaR8zED8j@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox