From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [PATCH RFC v2 net-next 00/25] rtnetlink: Add support for rigid checking of data in dump request Date: Wed, 3 Oct 2018 09:21:15 -0600 Message-ID: <953ee3e1-d305-4058-bf2d-4e56268bccd1@gmail.com> References: <20181002002851.5002-1-dsahern@kernel.org> <20181003075909.4d977567@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, davem@davemloft.net, christian@brauner.io, jbenc@redhat.com To: Stephen Hemminger , David Ahern Return-path: Received: from mail-pg1-f195.google.com ([209.85.215.195]:43198 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726748AbeJCWKK (ORCPT ); Wed, 3 Oct 2018 18:10:10 -0400 Received: by mail-pg1-f195.google.com with SMTP id 80-v6so1711478pgh.10 for ; Wed, 03 Oct 2018 08:21:19 -0700 (PDT) In-Reply-To: <20181003075909.4d977567@xeon-e3> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 10/3/18 8:59 AM, Stephen Hemminger wrote: > On Mon, 1 Oct 2018 17:28:26 -0700 > David Ahern wrote: > >> How to resolve the problem of not breaking old userspace yet be able to >> move forward with new features such as kernel side filtering which are >> crucial for efficient operation at high scale? > > What about forward compatibility? How would this work when running new iproute2 > command on older kernels? > > I expect the new command would set the "I am smart flag" and the older > kernel would ignore it. The if the header for the message type had > changed, the dump would be broken. > The kernel today happily ignores garbage in the request it does not understand. If the new iproute2 sends a dump request with attributes or fields in the header set the kernel ignores it. With the setsockopt option for setting the flag, userspace knows the kernel does not support attribute checking and kernel side filtering. As far as changing the header (new iproute2 on old kernel), there are 3 dumps that look at the header beyond the family: 1. link dumps - but it has the expected ifinfomsg header 2. neighbor dumps (expects the right ndmsg header) 3. fdb dumps - wrongly expect ifinfomsg header but there is patch to detect when the ndmsg header is sent (ip neigh vs bridge fdb) The 4th dump that looks at the header is addresses. Those patches were added in this development cycle. Those dumps need to be wrapped in the 'userspace has a clue' setting or reverted until this is figured out.