[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:


* 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.


* 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.


* 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(-)


More information about the kernel-team mailing list