sockopt: Introduce the SO_BINDTOIFINDEX
Subsystems (4)
PATCH 1/1 sockopt: Introduce the SO_BINDTOIFINDEX
Gentlemen,
here's how the symmetrical sk_bound_dev set/get would look like. If it's OK for you, I would ask David for inclusion.
It was noted that it was not good to have the non-symmetrical SO_BINDTODEVICE sockoption (set works with name, get reports index) and we'd rather implement another option to set and get socket bound device that work on ifindex.
The SO_BINDTONETDEV get-er is removed, as getting a device name is tricky and having one doesn't worth that pain.
--- include/uapi/asm-generic/socket.h | 2 + net/core/sock.c | 41 ++++++++++++++++++++++++++++++++++-- 2 files changed, 40 insertions(+), 3 deletions(-)
include/uapi/asm-generic/socket.h +2 -0
@@ -72,4 +72,6 @@/* Instruct lower device to use last 4-bytes of skb data as FCS */ #define SO_NOFCS 43 +#define SO_BINDTOIFINDEX 44 +#endif /* __ASM_GENERIC_SOCKET_H */
net/core/sock.c +38 -3
65 lines not on this page · raw message
Signature · 1 line
1.7.6.5
David Miller
maintainerThis is really a huge ball of confusion.
The user asks for a device to bind to, and they want the device which had a particular name at the time of the call.
If you allow setting this via ifindex, the issues and races are the same whether the name-->ifindex translation is done before the sockopt() call or during it.
Furthermore both the name and the ifindex can change (that latter via module unload/load).
If you want me to consider these changes seriously, talk less about obtuse issues like symmetry and more about what problems it actually solves. As far as I can tell, all the same real issues still exist even if we had this new interface.
In fact, I wouldn't mind if a getsockopt() on SO_BINDTODEVICE returned BOTH the name and the ifindex in a special structure. Then you could actually construct a more foolproof mechanism on the user side to try various ways to get the same device bound to during restart.
Symmetry is over-rated.
Quoted 9 lines · David Miller
This is really a huge ball of confusion.
The user asks for a device to bind to, and they want the device which had a particular name at the time of the call.
If you allow setting this via ifindex, the issues and races are the same whether the name-->ifindex translation is done before the
sockopt()call or during it.
Yes, there are race conditions in the socket APIs, even IP addresses can go away right before a bind() call.
Quoted 7 lines
Furthermore both the name and the ifindex can change (that latter via module unload/load).
If you want me to consider these changes seriously, talk less about obtuse issues like symmetry and more about what problems it actually solves. As far as I can tell, all the same real issues still exist even if we had this new interface.
Noone's complained about not having this getsockopt() for over 7+ years, so in that sense I'm not sure what problem it solved adding it.
Quoted 4 lines
In fact, I wouldn't mind if a
getsockopt()onSO_BINDTODEVICEreturned BOTH the name and the ifindex in a special structure. Then you could actually construct a more foolproof mechanism on the user side to try various ways to get the same device bound to during restart.
There is no fool-proof way to do any of this since we can agree device names and indexes can change. But people aren't typically running daemons listening on interfaces that are constantly changing like taps or tunnels, instead it's on eth1 so they can run a private DHCP server.
Quoted 1 line
Symmetry is over-rated.
If any of the other SO_* options didn't set and get using the same structure I'd agree with you, but I can't find any that do.
-Brian