[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20200521.172604.648069177650832955.davem@davemloft.net>
Date: Thu, 21 May 2020 17:26:04 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: sd@...asysnail.net
Cc: netdev@...r.kernel.org, dsahern@...il.com
Subject: Re: [PATCH net] net: don't return invalid table id error when we
fall back to PF_UNSPEC
From: Sabrina Dubroca <sd@...asysnail.net>
Date: Wed, 20 May 2020 11:15:46 +0200
> In case we can't find a ->dumpit callback for the requested
> (family,type) pair, we fall back to (PF_UNSPEC,type). In effect, we're
> in the same situation as if userspace had requested a PF_UNSPEC
> dump. For RTM_GETROUTE, that handler is rtnl_dump_all, which calls all
> the registered RTM_GETROUTE handlers.
>
> The requested table id may or may not exist for all of those
> families. commit ae677bbb4441 ("net: Don't return invalid table id
> error when dumping all families") fixed the problem when userspace
> explicitly requests a PF_UNSPEC dump, but missed the fallback case.
>
> For example, when we pass ipv6.disable=1 to a kernel with
> CONFIG_IP_MROUTE=y and CONFIG_IP_MROUTE_MULTIPLE_TABLES=y,
> the (PF_INET6, RTM_GETROUTE) handler isn't registered, so we end up in
> rtnl_dump_all, and listing IPv6 routes will unexpectedly print:
>
> # ip -6 r
> Error: ipv4: MR table does not exist.
> Dump terminated
>
> commit ae677bbb4441 introduced the dump_all_families variable, which
> gets set when userspace requests a PF_UNSPEC dump. However, we can't
> simply set the family to PF_UNSPEC in rtnetlink_rcv_msg in the
> fallback case to get dump_all_families == true, because some messages
> types (for example RTM_GETRULE and RTM_GETNEIGH) only register the
> PF_UNSPEC handler and use the family to filter in the kernel what is
> dumped to userspace. We would then export more entries, that userspace
> would have to filter. iproute does that, but other programs may not.
>
> Instead, this patch removes dump_all_families and updates the
> RTM_GETROUTE handlers to check if the family that is being dumped is
> their own. When it's not, which covers both the intentional PF_UNSPEC
> dumps (as dump_all_families did) and the fallback case, ignore the
> missing table id error.
>
> Fixes: cb167893f41e ("net: Plumb support for filtering ipv4 and ipv6 multicast route dumps")
> Signed-off-by: Sabrina Dubroca <sd@...asysnail.net>
Applied and queued up for -stable, thank you.
Powered by blists - more mailing lists