[PATCH 0/4][SRU][focal:linux] NFSv4.1: Don't rebind to the same source port when reconnecting to the server

[Khaled Elmously]

I was wrong about changing the behaviour of NFSv4.0 - it does appear to be kept unchanged, as per:

-       if (minorversion > 0 && proto == XPRT_TRANSPORT_TCP)
+       if (minorversion == 0)
+               __set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
+       else if (proto == XPRT_TRANSPORT_TCP)
                cl_init.nconnect = nconnect;



But you do appear to making a small change in the behaviour of NFSv3.x though, as per patches 2 and 3. It seems you needed patch 2 only to be able to cleanly cherry-pick patch 3, but that ends up introducing the NFS_CS_DS flag to NFSv3.x clients.

Would it be safer to omit patch 2 entirely and skip the changes to fs/nfs/nfs3client.c from patch 3? It should have no effect on your final intended fix.





On 2022-11-22 13:39:10 , Tim Gardner wrote:
> BugLink: https://bugs.launchpad.net/bugs/1997488
> 
> SRU Justification
> 
> Microsoft asked for this backport complaining that, 
> "NFS 4.1 mounts on AKS are reusing the same source port when a reconnect needs to happen".
> 
> Patches 1-3 are scaffolding in order to provide a clean cherrypick for patch 4.
> This issue looks applicable to the generic kernel.
> 
> [Impact]
> 
> NFSv2, v3 and NFSv4 servers often have duplicate replay caches that look
> at the source port when deciding whether or not an RPC call is a replay
> of a previous call. This requires clients to perform strange TCP gymnastics
> in order to ensure that when they reconnect to the server, they bind
> to the same source port.
> 
> NFSv4.1 and NFSv4.2 have sessions that provide proper replay semantics,
> that do not look at the source port of the connection. This patch therefore
> ensures they can ignore the rebind requirement.
> 
> [Where things could go wrong]
> 
> NFS reconnects may erroneously fail.
> 
> [Other Info]
> 
> SF: #00345839
> 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team