From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D186CC28CC5 for ; Sat, 8 Jun 2019 05:59:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A6ECF2089E for ; Sat, 8 Jun 2019 05:59:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728913AbfFHF7T (ORCPT ); Sat, 8 Jun 2019 01:59:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52242 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725906AbfFHF7T (ORCPT ); Sat, 8 Jun 2019 01:59:19 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 75AAE368E0; Sat, 8 Jun 2019 05:59:19 +0000 (UTC) Received: from localhost (ovpn-112-18.ams2.redhat.com [10.36.112.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2B3B45C220; Sat, 8 Jun 2019 05:59:16 +0000 (UTC) Date: Sat, 8 Jun 2019 07:59:11 +0200 From: Stefano Brivio To: Martin Lau Cc: David Ahern , David Miller , Jianlin Shi , Wei Wang , Eric Dumazet , "netdev@vger.kernel.org" Subject: Re: [PATCH net 1/2] ipv6: Dump route exceptions too in rt6_dump_route() Message-ID: <20190608075911.2622aecf@redhat.com> In-Reply-To: <20190608054003.5uwggebuawjtetyg@kafai-mbp.dhcp.thefacebook.com> References: <085ce9fbe0206be0d1d090b36e656aa89cef3d98.1559851514.git.sbrivio@redhat.com> <20190606231834.72182c33@redhat.com> <05041be2-e658-8766-ba77-ee01cdfe62bb@gmail.com> <20190608054003.5uwggebuawjtetyg@kafai-mbp.dhcp.thefacebook.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Sat, 08 Jun 2019 05:59:19 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sat, 8 Jun 2019 05:40:06 +0000 Martin Lau wrote: > On Thu, Jun 06, 2019 at 04:47:00PM -0600, David Ahern wrote: > > On 6/6/19 3:18 PM, Stefano Brivio wrote: > > > On Thu, 6 Jun 2019 14:57:33 -0600 > > > David Ahern wrote: > > > > > >>> This will cause a non-trivial conflict with commit cc5c073a693f > > >>> ("ipv6: Move exception bucket to fib6_nh") on net-next. I can submit > > >>> an equivalent patch against net-next, if it helps. > > >>> > > >> > > >> Thanks for doing this. It is on my to-do list. > > >> > > >> Can you do the same for IPv4? > > > > > > You mean this same fix? On IPv4, for flushing, iproute2 > > > uses /proc/sys/net/ipv4/route/flush in iproute_flush_cache(), and that > > > works. > > > > > > Listing doesn't work instead, for some different reason I haven't > > > looked into yet. That doesn't look as critical as the situation on IPv6 > > > where one can't even flush the cache: exceptions can also be fetched > > > with 'ip route get', and that works. > > > > > > Still, it's bad, I can look into it within a few days. > > > > > > > I meant the ability to dump the exception cache. > > > > Currently, we do not get the exceptions in a fib dump. There is a flag > > to only show cloned (cached) entries, but no way to say 'no cloned > > entries'. Maybe these should only be dumped if the cloned flag is set. > > That's the use case I was targeting: > > 1. fib dumps - RTM_F_CLONED not set > I also think the fib dump should stay as is. > > To be clear, I do not expect exception routes output from the > 'ip [-6] r l'. Otherwise, I will get pages of exceptions > that I am not interested at. This should apply for both > v4 and v6. I also agree it makes more sense to filter routes this way. But it wasn't like this before 2b760fcf5cfb, so this smells like breaking userspace expectations, even though iproute already filters routes this way: with 'cache' it only displays routes with RTM_F_CLONED, without, it won't display exceptions, see filter_nlmsg(): if (filter.cloned == !(r->rtm_flags & RTM_F_CLONED)) return 0; This, together with the fact it's been like that for almost two years now, makes it acceptable in my opinion. What do you think? If we agree on this, I'll go ahead and start changing this in my patch for IPv6. -- Stefano