[PATCH mptcp-net 2/5] selftests: mptcp: simult flows: define missing vars

Geliang Tang posted 5 patches 1 year, 12 months ago
There is a newer version of this series
[PATCH mptcp-net 2/5] selftests: mptcp: simult flows: define missing vars
Posted by Geliang Tang 1 year, 12 months ago
From: Geliang Tang <tanggeliang@kylinos.cn>

The variables 'large', 'small', 'sout', 'cout', 'capout' and 'size' are
used in multiple functions, so they should be defined as global variables.
This patch redefines them at the beginning of simult_flows.sh.

Fixes: 1a418cb8e888 ("mptcp: simult flow self-tests")
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
 tools/testing/selftests/net/mptcp/simult_flows.sh | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/testing/selftests/net/mptcp/simult_flows.sh b/tools/testing/selftests/net/mptcp/simult_flows.sh
index 619be0e1acf5..3a003d47fccb 100755
--- a/tools/testing/selftests/net/mptcp/simult_flows.sh
+++ b/tools/testing/selftests/net/mptcp/simult_flows.sh
@@ -16,6 +16,12 @@ test_cnt=1
 ret=0
 bail=0
 slack=50
+large=""
+small=""
+sout=""
+cout=""
+capout=""
+size=0
 
 usage() {
 	echo "Usage: $0 [ -b ] [ -c ] [ -d ]"
-- 
2.40.1
Re: [PATCH mptcp-net 2/5] selftests: mptcp: simult flows: define missing vars
Posted by Matthieu Baerts 1 year, 12 months ago
Hi Geliang,

On 13/02/2024 05:14, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
> 
> The variables 'large', 'small', 'sout', 'cout', 'capout' and 'size' are
> used in multiple functions, so they should be defined as global variables.
> This patch redefines them at the beginning of simult_flows.sh.
> 
> Fixes: 1a418cb8e888 ("mptcp: simult flow self-tests")

Even if I agree it is better to clearly define global variables at the
beginning, it is not a mistake to define them in a function.

My main point is that it is maybe easier not to consider this as a fix:
it looks like backporting this to stable will create conflicts. They
will be easy to resolve, but still, it will take a bit of time to a few
people. If it doesn't fix an issue, isn't a preparation patch or doesn't
ease the backport of other patches, maybe better to target -next
(without the "Fixes" tag). WDYT?

If there are no other modifications in the series and no objections, no
need to send a new version, I can apply the patch 2 in -next. If you
need to send a v2, please move this patch after all the other fixes of
the series (or as part of a new series).

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.