[SRU][F][G][PATCH 0/1] smc: SMC connections hang with later-level implementations (LP: 1882088)
frank.heimes at canonical.com
frank.heimes at canonical.com
Fri Jul 10 19:21:44 UTC 2020
Buglink: https://bugs.launchpad.net/bugs/1882088
SRU Justification:
[Impact]
* Connections from later-level SMC (protocol) versions to an SMC-enabled server on Linux hang.
* Later-level versions of SMC (although backwards-compatible) present a higher version number and use larger messages during the CLC handshake.
* The solution to avoid such hangs is to introduce toleration for later version numbers, and support CLC messages of arbitrary length.
[Fix]
* fb4f79264c0fc6fd5a68ffe3e31bfff97311e1f1 fb4f79264c0f "net/smc: tolerate future SMCD versions"
[Test Case]
* Requires two IBM z13/z13s GA2 or LinuxONE Rockhopper/Emperor systems with RoCE Express adapter v2(.1) for SMC-D usage.
* One system needs to run the initial SMC-D version, the other a newer version.
* Establish a connection between both system and monitor/verify if it's reliable or if it hangs.
[Regression Potential]
* The regression can be considered as medium to low:
* Since SMC-D is a pretty special way of doing shared memory communications and not that wide-spread.
* However, the code that is changed is common code.
* But the patch is straight forward and only modifies /net/smc/smc_clc.c and /net/smc/smc_clc.h
* It largely bumps limits (allows larger messages), adds a check and introduces toleration, rather than changing control or flow.
[Other]
* The above fix is currently in 'linux-next' and tagged with next-20200709.
* It is still assumed that it gets accepted for 5.8.
* However, since this is not guaranteed this SRU request is for focal and groovy - to make sure that no potential regressions are introduced in case the patch will not end up in 5.8.
Ursula Braun (1):
From: Ursula Braun <ubraun at linux.ibm.com>
net/smc/smc_clc.c | 45 ++++++++++++++++++++++++++++++++-------------
net/smc/smc_clc.h | 4 ++++
2 files changed, 36 insertions(+), 13 deletions(-)
--
2.25.1
More information about the kernel-team
mailing list