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] [thread-next>] [day] [month] [year] [list]
Date: Thu, 20 Jul 2023 22:01:06 -0600
From: David Ahern <dsahern@...nel.org>
To: Hangbin Liu <liuhangbin@...il.com>, Ido Schimmel <idosch@...sch.org>
Cc: Stephen Hemminger <stephen@...workplumber.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>, Thomas Haller <thaller@...hat.com>
Subject: Re: [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush
 fib

On 7/20/23 7:34 PM, Hangbin Liu wrote:
> On Thu, Jul 20, 2023 at 05:29:58PM +0300, Ido Schimmel wrote:
>>>>> IMO, the number of routes being flushed because a preferred source
>>>>> address is deleted is significantly lower compared to interface down /
>>>>> deletion, so generating notifications in this case is probably OK. It
>>>
>>> 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ