Our partner Cherry at Google requested z-stream releases for RHEL 7.7 and 7.9.

If it's feasible to do so, it might make sense to ship z-streams for RHEL 7.4 and 7.6. AFAIK (this information may no longer be up-to-date), RHEL 7.4 and 7.6 are still covered under EUS for SAP HA.

I don't recommend to include patch in RHEL 7.4 and 7.6. There were big changes in totemconfig.c so patch is not applicable there cleanly (without making big patch). Even 7.7 is a bit problematic, but doable.

(In reply to Jan Friesse from comment #6)
> I don't recommend to include patch in RHEL 7.4 and 7.6. There were big
> changes in totemconfig.c so patch is not applicable there cleanly (without
> making big patch). Even 7.7 is a bit problematic, but doable.

In that case I agree that it's not worth the trouble.

I had to correct my statement. 7.7 seems to be more or less equally problematic as 7.6, so we can either have big patch for both 7.6 and 7.7, or vanilla upstream patch, but only for 7.9 (this is preferred by me).

Scratch build with patch (7.9.z) http://brew-task-repos.usersys.redhat.com/repos/scratch/jfriesse/corosync/2.4.5/7.el7_9.2/

For QA:
What I've tested/checked:
- There is new option totem.cancel_token_hold_on_retransmit
  - Described in corosync.conf man page
  - Current value exported as runtime.config.totem.cancel_token_hold_on_retransmit
  - Default value is "no". When set to "yes" behavior of corosync is same as before patch
- One (or more) nodes are delaying larger packets (I was using following script):
```
#!/bin/bash

iptables -t mangle -A POSTROUTING \
  -p udp -s $SOURCE_IP \
  -m length --length 1000:2000 -j MARK --set-mark 10

iptables -t mangle -L

tc qdisc add dev $SOURCE_DEV root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
tc qdisc add dev $SOURCE_DEV parent 1:1 handle 2: netem delay 1000ms
```
- Running two nodes
- Send one larger message using cpg-load (https://github.com/jfriesse/csts/blob/master/apps/cpg-load.c)
```
./cpg-load -m 1 -n 1 -L 1500 -l 1500
```
- Without patch (or cancel_token_hold_on_retransmit set to "yes") corosync ends with "FAILED TO RECEIVE" and reforming cluster
- With patch corosync slows resending packets after a while and packet is delivered after delay (for above example 1000 ms)
- When running continuous load (`/cpg-load -n 1 -L 1500 -l 1500`) corosync slows down, but messages are delivered (with delay) and membership keeps stable
- After removal of netem/iptables rules corosync returns back to full speed
- For more than two nodes cluster "FAILED TO RECEIVE" wasn't happening regularly, but network was overloaded by resended messages. This shouldn't be happening with patch.

More information can be found in upstream GH issue - https://github.com/corosync/corosync/issues/622

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (corosync bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4787