netdev - Re: [PATCH net-next] ipv4/fib: send RTM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230915095948.63f9dd69@hermes.local>
Date: Fri, 15 Sep 2023 09:59:48 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: David Ahern <dsahern@...nel.org>
Cc: nicolas.dichtel@...nd.com, Thomas Haller <thaller@...hat.com>, Benjamin
 Poirier <bpoirier@...dia.com>, Hangbin Liu <liuhangbin@...il.com>, Ido
 Schimmel <idosch@...sch.org>, netdev@...r.kernel.org, "David S . Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
 <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush
 fib

On Wed, 13 Sep 2023 08:41:05 -0600
David Ahern <dsahern@...nel.org> wrote:

> On 9/13/23 1:58 AM, Nicolas Dichtel wrote:
> > Le 11/09/2023 à 11:50, Thomas Haller a écrit :
> > [snip]  
> >> - the fact that it isn't fixed in more than a decade, shows IMO that
> >> getting caching right for routes is very hard. Patches that improve the
> >> behavior should not be rejected with "look at libnl3 or FRR".  
> > +1
> > 
> > I just hit another corner case:
> > 
> > ip link set ntfp2 up
> > ip address add 10.125.0.1/24 dev ntfp2
> > ip nexthop add id 1234 via 10.125.0.2 dev ntfp2
> > ip route add 10.200.0.0/24 nhid 1234
> > 
> > Check the config:
> > $ ip route
> > <snip>
> > 10.200.0.0/24 nhid 1234 via 10.125.0.2 dev ntfp2
> > $ ip nexthop
> > id 1234 via 10.125.0.2 dev ntfp2 scope link
> > 
> > 
> > Set the carrier off on ntfp2:
> > ip monitor label link route nexthop&
> > ip link set ntfp2 carrier off
> > 
> > $ ip link set ntfp2 carrier off
> > $ [LINK]4: ntfp2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
> > DOWN group default
> >     link/ether de:ed:02:67:61:1f brd ff:ff:ff:ff:ff:ff
> >   
> > => No nexthop event nor route event (net.ipv4.nexthop_compat_mode = 1)  
> 
> carrier down is a link event and as you show here, link events are sent.
> 
> > 
> > 'ip nexthop' and 'ip route' show that the nexthop and the route have been deleted.  
> 
> nexthop objects are removed on the link event; any routes referencing
> those nexthops are removed.

The netlink notification path can and does not have any flow control.
The problem with what is propoosed is that if there are 1M route entries
and a link event happens, some of the RTM_DELROUTE events will be dropped
when the netlink queue overruns. Therefore daemons can not depend on RTM_DELROUTE
for tracking, and instead should look for the link event and do bulk
cleanup then.