Messages in this thread | | | Date | Tue, 4 Sep 2018 08:50:06 +0200 | From | Jiri Benc <> | Subject | Re: [PATCH net-next v1 3/5] ipv4: enable IFA_IF_NETNSID for RTM_GETADDR |
| |
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.
> 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.
Thanks,
Jiri
| |