Messages in this thread | | | Subject | Re: [PATCH net-next v1 3/5] ipv4: enable IFA_IF_NETNSID for RTM_GETADDR | From | Nicolas Dichtel <> | Date | Tue, 4 Sep 2018 09:20:16 +0200 |
| |
Le 04/09/2018 à 08:50, Jiri Benc a écrit : > On Mon, 3 Sep 2018 21:11:30 -0600, David Ahern wrote: >> Can only use it once per message type, but NLM_F_DUMP_FILTERED is a flag >> that can be set to explicitly say the request is filtered as requested. > > The problem is that NLM_F_DUMP_FILTERED is too coarse. There's no way > to determine whether the netnsid was honored or whether it was not but > other filtering took effect. > > This is a general problem with netlink: unknown attributes are ignored. > We need a way to detect that certain attribute was understood by the > kernel or was not. And it needs to work retroactively, i.e. the > application has to be able to determine the currently running kernel > does not support the feature (because it's too old). > > That's why we return back the attribute in responses to a request with > IFLA_IF_NETNSID present and why we should do the same for > IFA_IF_NETNSID. +1
> >> See 21fdd092acc7e. I would like to see other filters added for addresses >> in the same release this gets used. The only one that comes to mind for >> addresses is to only return addresses for devices with master device >> index N (same intent as 21fdd092acc7e for neighbors). > > I also question the statement that IFA_F_NETNSID is a filter: my > understanding of "filter" is something that limits the output to a > certain subset. I.e., unfiltered results always contain everything that > is in a filtered result. While with IFA_F_NETNSID, we get a completely > different set of data. Does that really constitute a filter? Note that > we can still filter in the target netns. +1
Regards, Nicolas
| |