netdev - Re: [PATCH iproute2] iproute: Pass RTM_F_CLONED on dump to fetch cached routes to be flushed

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: <20190625134047.48acabee@redhat.com>
Date:   Tue, 25 Jun 2019 13:40:47 +0200
From:   Stefano Brivio <sbrivio@...hat.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        David Miller <davem@...emloft.net>,
        Jianlin Shi <jishi@...hat.com>, Wei Wang <weiwan@...gle.com>,
        Martin KaFai Lau <kafai@...com>,
        Eric Dumazet <edumazet@...gle.com>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        netdev@...r.kernel.org
Subject: Re: [PATCH iproute2] iproute: Pass RTM_F_CLONED on dump to fetch
 cached routes to be flushed

On Mon, 24 Jun 2019 15:55:49 -0600
David Ahern <dsahern@...il.com> wrote:

> On 6/14/19 7:33 PM, Stefano Brivio wrote:
> > diff --git a/ip/iproute.c b/ip/iproute.c
> > index 2b3dcc5dbd53..192442b42062 100644
> > --- a/ip/iproute.c
> > +++ b/ip/iproute.c
> > @@ -1602,6 +1602,16 @@ static int save_route_prep(void)
> >  	return 0;
> >  }
> >  
> > +static int iproute_flush_flags(struct nlmsghdr *nlh, int reqlen)  
> 
> rename that to iproute_flush_filter to be consistent with
> iproute_dump_filter.

I originally wanted to make it obvious that it's not an actual filter,
but:

> Actually, why can't the flush code use iproute_dump_filter?

...come on. That would be too simple.

No, my original understanding was that strict checking didn't imply
filtering. It does, and the current kernel implementation matches,
now also for RTM_F_CACHED. So yes, we can use it, and it doesn't cause
any unexpected behaviours with older kernels either. Sending v2. Thanks
for pointing this out.

-- 
Stefano