On Jan 28, 2013, at 3:45 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Mon, 28 Jan 2013 15:34:49 -0500 > Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > >> >> On Jan 28, 2013, at 3:26 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >> >>> On Mon, 28 Jan 2013 12:16:17 -0800 (PST) >>> Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>> >>>> >>>> On Jan 28, 2013, at 3:05 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >>>> >>>>> On Mon, 28 Jan 2013 11:51:13 -0800 (PST) >>>>> Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>>>> >>>>>> >>>>>> On Jan 28, 2013, at 2:41 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >>>>>> >>>>>>> Currently, it only stores the first 16 bytes of any address. struct >>>>>>> sockaddr_in6 is 28 bytes however, so we're currently ignoring the last >>>>>>> 12 bytes of the address. >>>>>>> >>>>>>> Expand the c_addr field to a sockaddr_in6, >>>>>> >>>>>> What do you do about link-local addresses? >>>>>> >>>>> >>>>> I use rpc_cmp_addr() which should handle the scope correctly for >>>>> link-local addrs. Now that you mention it though, I think we may have a >>>>> bug in __rpc_copy_addr6. It doesn't touch the scope_id at all -- >>>>> shouldn't we be setting the scopeid in that function as well? >>>> >>>> It looks like rpc_copy_addr() is invoked to copy only source addresses, so the scope ID probably doesn't apply. The comment over rpc_copy_addr() says it explicitly ignores port and scope ID. >>>> >>> >>> Well, it copies the source address of the client, but all of the >>> callers are in nfsd code. So I think it probably does matter: >>> >>> Consider a server that has 2 interfaces, and 2 clients with identical >>> link-local addresses hitting the link local address of each interface. >>> The only way to distinguish them at that point is to look at their >>> scope_ids. >> >> Yes, but we want to use the server's scope IDs in this case, don't we? Copying the client's scope IDs may not be the right thing to do. That's why __rpc_copy_addr6() doesn't copy the scope ID. >> > > Is there any real distinction between the two? Whenever we start > discussing scopeids I mentally substitute "interface index", since it's > the same thing on linux. > > AIUI, scopeids only have a meaning on the host itself. When a > link-local address gets used, the sockaddr_in6 in question gets the > sin6_scope_id set to the index of the interface to which it is > associated. > > So if we have a client and server "pair" using link-local addresses, > then they should have equivalent scope IDs since they are associated > with the same interface on the local machine. I don't think we can assume that the interface indices are the same on both the client and server. There is no co-ordination of that number space between separate hosts. What may be the case is that the server's network layer copies in the correct scope ID for the server when it exposes source addresses to its upper layers. In that case, the ID's probably safe to use when comparing addresses locally on the server. Since we don't know for sure how this works, we should have someone create unit tests to explore this, fix any bugs that are discovered, and ensure that it continues to work. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
