On 07/17/2018 07:27 PM, Sowmini Varadhan wrote:
On (07/17/18 13:32), Ka-Cheong Poon wrote:
The app can use either structures to make the call. When the
app fills in the structure, it knows what it is filling in,
either sockaddr_in or sockaddr_in6. So it knows the right size
to use. The app can also use IPv4 mapped address in a sockaddr_in6
without a problem.
tupical applications that I have seen in routing applicaitons
will use a union like
union {
struct sockaddr_in sin;
struct sockaddr_in sin5;
}
Or they will use sockadd_storage. Passing down the sizeoof that structure
will do the worng thing thing in the existing code for ipv4 (even
though it will not generate EFAOIT)..
What a typical socket (not routing) app will do is to pass in
the right sizeof based on the socket address structure in doing
things like connect() or bind(). The app needs to fill in the
structure correctly according to which one after all. And this
avoids the unnecessary copy of garbage data from user to kernel.
Could you please explain the inconsistency? An app can use IPv4
mapped address in a sockaddr_in6 to operate on an IPv4 connection,
in case you are thinking of this new addition in v3 of the patch.
bind() and connect() are using the sa_family/ss_family to have
the application signal to the kernel about whether ipv4 or ipv6 is
desired. (and bind and connect are doing the right thing for
v4mapped, so that doesnt seem to be a problem there)
In this case you want the application to signal that info via
the optlen. (And the reason for this inconsistency is that you dont
want to deal with the user->kernel copy in the same way?)
Because doing that can break existing RDS apps. Existing code
does not check the address family in processing this socket
option. It only cares about the address and port. If the new
code suddenly checks that and use it to decide on the address
family, working app will break. As I mentioned before, this
patch set does not change existing behavior. And doing what
you mentioned will change existing behavior and break apps.
--
K. Poon
ka-cheong.p...@oracle.com
