> On May 29, 2018, at 4:53 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > >> On May 29, 2018, at 4:07 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >> >> On Fri, May 25, 2018 at 6:35 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>> >>> I can think of legitimate cases where two unique NFSv4.0 >>> clients having the same IP address might mount the same >>> server. >>> >>> - clientaddr=0.0.0.0, as mentioned above >> >> I think this should be prohibited. If this is used a way to signify to >> the server to no give out delegations, then there could be other means >> of doing so. Let's add a mount option 'nodeleg', client would send a >> valid callback info to the server but if the option is set, then it >> will not start a callback server. That would prevent the server from >> being able to establish a callback path (which is the same thing as >> sending 0.0.0.0). > > That introduces delays while the server is probing the client's > callback server. The spec specifically allows a client to send > 0.0.0.0 to signify that the server should not use callbacks. > > And mount.nfs has allowed that setting for a long time. > > IMO we have to continue to allow 0.0.0.0. Still thinking about this. Not using cl_ipaddr in the client ID string helps. I have a patch that does this. The question I've been wondering since the original post is "are there any other use cases where mount.nfs can't properly guess which address to provide?" That's why I was asking why your customer was using clientaddr. If we have confidence that mount.nfs is 100% reliable about choosing a good local address, except in the NAT case where we should just be disabling CB, then we could have mount.nfs strip off a user-supplied clientaddr and construct its own in all cases but the "clientaddr= 0.0.0.0" case (and it's IPv6 equivalent). -- Chuck Lever -- 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
