Messages in this thread |  | | Subject | Re: [PATCH net-next 0/3 V1] rtnetlink: enable IFLA_IF_NETNSID for RTM_{DEL,SET}LINK | From | Nicolas Dichtel <> | Date | Thu, 25 Jan 2018 15:20:59 +0100 |
| |
Le 24/01/2018 à 17:35, Jiri Benc a écrit : > On Wed, 24 Jan 2018 16:24:34 +0100, Nicolas Dichtel wrote: >> I wonder if it would be possible to do something in the netlink framework, like >> NETLINK_LISTEN_ALL_NSID. >> Having some ancillary data at the netlink socket level and a function like >> nlsock_net() (instead of sock_net()) to get the corresponding netns. >> With that, it would be possible, in a generci way, to support this feature for >> all netlink family. > > I'm not sure it's worth the effort to do that in the framework. You'll > need modifications all the way down to the code that generates the > attributes anyway. > > It's not enough to just specify that the operation should be done on a > different netns and hide that from the handlers. Take for example the > existing RTM_GETLINK. Let's say it's executed from within ns_a and > targeted to ns_b (thus IFLA_IF_NETNSID = netnsid of ns_b). Now, if > there's a veth interface in ns_b whose other end is in ns_c, there will > be IFLA_LINK_NETNSID attribute in the response. But the value has to be > netnsid of ns_c as seen from *ns_a*. If you just pretended to switch to > ns_b before invoking rtnl_getlink, it would be netnsid of ns_c as seen > from ns_b which would be wrong. Hmm, I don't agree. For me, it would be the correct answer. If user has a socket in ns_a and targets a RTM_GETLINK in ns_b, the answer he gets should be like if it was done in ns_b. This is already the case with messages received with NETLINK_LISTEN_ALL_NSID, there is no reason to do something different.
Regards, Nicolas
|  |