From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (unknown [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id 61EF680067 for ; Thu, 24 Sep 2026 12:54:51 +0000 (UTC) Received: from mail.openvz.org (localhost [127.0.0.1]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 68OCrVrA016286; Thu, 24 Sep 2026 15:53:32 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68OCrVrA016286 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="VT9wR9kw" Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 68OCrUE0016278 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Thu, 24 Sep 2026 15:53:30 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68OCrUE0016278 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-4870ee5618aso1354205f8f.1 for ; Thu, 24 Sep 2026 05:53:30 -0700 (PDT) X-Forwarded-Encrypted: i=2; AKwUvBzoaS17L75WR6fdjOlwG+NX1lxEcRwvxYWb1LCoz5CnWyUCUL8OvwUQRz6832g0ZYSQAfb58A==@openvz.org X-Gm-Message-State: AFuF++niz8Y86hRyaiydcgqj3sqzW8Qp2t7k30cGTXz2nH/S4TNDUvet YMeXrDMVVoT9QQ9P/HOqRF/4SkarGAPfN9xQnG+TXaRmHLLpuCqgXDzCQVaw0iQON5V2gxNAyoP NgEQ9zKUNhs6qAMUQmzWwfyllkKuojv7HTCqUM+Z1sr+MYhS1EveFvQ== X-Gm-Gg: AYBFou3amx9O8UG9gFu8Y7atjMIXscuJ0JQK/cMD+YfuQgGjGsJb11zAgDLx8PYtc5P PbFaCi11POdE3vT/cevKOoEMCcU5LMN3I8oW4rAQWI8GXRQh9HujwvOWp+R/UtCoiQpQjJhFkMV fgYR4aPbz7AictkpjeZEabljt+fY1LAXw5wdYLT+V3HHs4tC+5Br+jed6+9DzKLcbAOoGe2X+Tm /MSY5mFAXA8+UKgGFKhwKvk8QLIwZmjRF8U6gMdwH/4hJJVvwQnwiI91f+JeMoHXclAeIaTvtvV HkUovYioqO6OZExndn0yc2ZHTaAV2YNDeReX5p4YjfYFL27AKcANMAjVni4C+Cnt79nHXYbUIiJ ecz7/P7wxJgWOgQkz9w== X-Received: by 2002:a05:6000:4a0a:b0:487:27f6:a4d3 with SMTP id ffacd0b85a97d-488716a5e50mr3942109f8f.35.1790254410339; Thu, 24 Sep 2026 05:53:30 -0700 (PDT) X-Received: by 2002:a05:6000:4a0a:b0:487:27f6:a4d3 with SMTP id ffacd0b85a97d-488716a5e50mr3942068f8f.35.1790254409780; Thu, 24 Sep 2026 05:53:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1790254409; cv=none; d=google.com; s=arc-20260327; b=gYCKG356RtTPPnpIm7DRzOnqC6kcbFhrDzGX6U5xfo34dljUfyTutmxKDTK5q8G6er MuJlDezONMirkT6R16NrLMfFGB80QXydX6k2MNTXzrgBsrlIgZovvOby7FZYxEvg6yhi xnFB0VUOWDTsUuXxHISzu4zt9wGq0QlPUp5RaNXuO75HnrZQV9Bvt2P2kmb4FHl8y1qM ror1adQMjvE2t+sv08LtbAa1tTewNEVoaYdbn/2vldw6SHXu3//Pcetk07pvjXd/8Y/n J7CZuTvIA9FO9O1fNVU34kIjD9l/OmT/6VYeZnozxU58pBnk+8yxa7kDEgWKdY9LEmG4 EGWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=message-id:date:references:in-reply-to:cc:to:from:subject :content-transfer-encoding:mime-version:dkim-signature; bh=nwa5phe5SuR6YjzUOT6XXddLIW8eDznpVpXZ4v6L/Jc=; fh=CTF2GHyV+XdzB5TROrdG4fdLri6JSHNOBC+LNuNq5bA=; b=JTMtoFP3Qi5J+VawJU+KkZUQjE5Pp3fi3FRd1wovpsJliBuZ0RRyuht4HrCEMwS65J iBZMJlQcJg884Lup5wmj153WpwF1Y/Bi0RjicYiojVwtE2Mwbdjm5eXS3zeEhBWeXZqd hBbodfQIPTx6g2VQcjG342RpBrfk+LfY1M+4xORwmSrFQUAao42gnVcF2EmL+Jfs9vBx ES7QXqhf6yqOgnSpQDKI3i0f/pUoCEe/JHqVd32Z1dqRY1wbSx8nNZasZHaicF50Erw1 bB1IxUSZH3AkvCo8lcyju6Q6ph5oWPjSlPdYvlU3XVzOzOR541qWAwJdGUYuEb2Ya8sf uTfA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=VT9wR9kw; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from relay.virtuozzo.com (relay.virtuozzo.com. [130.117.225.111]) by mx.google.com with ESMTPS id ffacd0b85a97d-488688e107fsi9506233f8f.394.2026.09.24.05.53.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 05:53:29 -0700 (PDT) Received-SPF: pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) client-ip=130.117.225.111; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=VT9wR9kw; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Message-Id:Date:From:Subject:Content-Type: MIME-Version; bh=nwa5phe5SuR6YjzUOT6XXddLIW8eDznpVpXZ4v6L/Jc=; b=VT9wR9kw247g HoRsqSRW+AtdO2rWJxgmvEi6mZZx/KtLq06OXOhNMQ8TVh8UuWnipn49AV3QKRGZD6ksyNEW4kj3Z R87H4oJunaY6Jd8JFJK8MKZESTEAZHU1xKC2iadtDUTYIngEEZmMXUFxtgtfhuzJyoFESjlBkL3Ce UABF2wP8iAizNEFuFY+P0VceZjPDtCh9eoy5makOpzVHkrSzQuGXv3wH8+Mo7tL3TZPSzi5ttfPND kSe/Qed9uNgYIMElq9Au+EYCEeIRVFRO0QH8wkLClWAiRsb9/TcSEgyWdOfYWFRzMzRQLrT2jCsxw ImcOIf/j74JdcoRS+P1FaQ==; Received: from ch-demo-asa.virtuozzo.com ([130.117.225.8] helo=f0.sw.ru) by relay.virtuozzo.com with esmtp (Exim 4.96) (envelope-from ) id 1x9iuA-00Eiad-2R; Thu, 24 Sep 2026 14:53:27 +0200 MIME-Version: 1.0 From: Konstantin Khorenko To: Eva Kurchatova In-Reply-To: <20260831234036.1649006-3-eva.kurchatova@virtuozzo.com> References: <20260831234036.1649006-1-eva.kurchatova@virtuozzo.com> <20260831234036.1649006-3-eva.kurchatova@virtuozzo.com> Date: Thu, 24 Sep 2026 14:53:23 +0200 Message-Id: <179025440346.3200029.9081508207286680888.b4-review@b4> X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=5583; i=khorenko@virtuozzo.com; h=from:subject:message-id; bh=wFsOy9epRTjJmkguQF0lYyICe7EfTO/6xdOGpnl3XyA=; b=owEBbQKS/ZANAwAKAVGWCkf5YVwqAcsmYgBqtR1I6A+S3y+P+KavzC9PWpkdPtfENPVgpaxG/ omMePpWIYCJAjMEAAEKAB0WIQRWD23IPcXT0GO9CCxRlgpH+WFcKgUCarUdSAAKCRBRlgpH+WFc KpF8EACavCM62OhxFyE+/h6i6enqOV1UblWW8Qqwin3ufjgTV8tATcX9PcmsphjeFL0DWrGYZ9c awl2+gynL3boNshIXp1UfLQ00yIvif60w2VoW5NTHDy6mVRfwPLdQC62FLOWjeVukXH7S2oIIwf LBViZEyPtWvu+8ECjDP1XjB6yFIs+iWNjr/dIargrGWk8S81B9Lo6OzSX1+7zPeIyfuwvz/lTgZ LqUTWTAY87+OAKNxvhR5LwxmwHX38yWjGXQaMyFm4LxdLhFJ0bO52ev7DNZcET+a6MSAOylFUuZ hrVIsTbum3WNFZ3c1lzI3xPsa3zLQInxCWFKrUkUvmvXdptBnOiQGi2XVNwUWUIV5XBbLmyGVOb PnhM2q4za3Bznc96XXJlNUT11d6x0Ak4hOqRc2NpC0oLnTM4gm6d6ceFSdefJPs2r0YR1ZzmHqw Mp5HRP3lqkraVZiBWMCWkMCGPQY3+FmXTDhVnaQ0XLMCi8MfWe2tn09Dv/flYjT2D3o8eR8Tb3S 9/pOwYzuPjcmhORx/ZOb41/Ul3+U4j0kMkUP0Kt3pRIdzErGyxxin9VKYeoqIASOZwP07t0VmM8 Pl064IRcvhbL7SJNkTNuHjniIsAsNHRYErpYFDPbTJsO1nCCnCcNOHcgowiwZuc4IFSXTKz+Dc6 0Uktv3TFst8Y3IQ== X-Developer-Key: i=khorenko@virtuozzo.com; a=openpgp; fpr=560F6DC83DC5D3D063BD082C51960A47F9615C2A X-OZ-Fwd: true Cc: devel@openvz.org Subject: Re: [Devel] [PATCH vz10 3/3] selftests: bonding: do not build on the namespaces of a killed run X-BeenThere: devel@openvz.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OpenVZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org > lag_setup2x2() creates lag_node1 and lag_node2 and then moves a veth > into each with > > ip link set dev lag1 netns lag_node1 down name eth0 > > which asks for the move, the state and the rename in one request. The > namespaces are removed by lag_cleanup() from an exit trap, so a run > that is killed instead, by the timeout of the suite for one, leaves > them behind. The next run then finds them: ip netns add fails, the > veth is moved into a namespace that already has an eth0, the rename > fails after the move has been committed, and the kernel says so: > > A link change request failed with some changes committed already. > Interface lag1 may have been left with an inconsistent configuration, > please check. > > What is left is half a topology, and a bond built on it does not come > back: > > TEST: mode (2) bond recovery [FAIL] > Bond failed to recover > > Only some of the cases fail, which is what makes it look like a timing > problem. With lag_node1 and lag_node2 left over on purpose, one case > of the seven in mode-2-recovery-updelay.sh fails; with them removed > first, three runs of seven pass, and so does > mode-1-recovery-updelay.sh, which uses the same library. Measured numbers do not belong in a commit message, they are true only on the machine they came from. "one case of the seven", "three runs of seven" go to the ticket. Here it is enough to say that the failure is intermittent and goes away once the leftover namespaces are removed. Also the message describes one change, the namespace cleanup, while the patch does two, see the slowwait hunk below. > > https://virtuozzo.atlassian.net/browse/VSTOR-139651 > Feature: fix selftests > Signed-off-by: Eva Kurchatova > > diff --git a/tools/testing/selftests/drivers/net/bonding/lag_lib.sh b/tools/testing/selftests/drivers/net/bonding/lag_lib.sh > index bf9bcd1b5ec04..7ac6c4d055eb2 100644 > --- a/tools/testing/selftests/drivers/net/bonding/lag_lib.sh > +++ b/tools/testing/selftests/drivers/net/bonding/lag_lib.sh > @@ -90,9 +90,18 @@ lag_setup2x2() > local state=${1:-down} > local namespaces="lag_node1 lag_node2" > > - # create namespaces > + # create namespaces. A run of one of these tests that was killed, > + # by the timeout of the suite for one, does not get to its cleanup > + # and leaves these behind; the ip link set below then moves a veth > + # into a namespace that already has an eth0, fails on the rename it > + # is asked for in the same request, and leaves half a topology: > + # A link change request failed with some changes committed already. > + # Interface lag1 may have been left with an inconsistent > + # configuration, please check. > + # Take what is left over before building on top of it. This repeats the commit message. In a test one line is enough, e.g. # a killed run leaves the namespaces behind, start clean Also double space after the period ("namespaces. A run"), single space please, here and below. > for n in ${namespaces}; do > - ip netns add ${n} > + ip netns del ${n} 2>/dev/null > + ip netns add ${n} || return 1 The del before add is fine: the old veths go away with the namespaces and the new pair is created in the root namespace and moved right away, nothing collides. The "|| return 1" does nothing though: lag_setup_network() does not look at the return value and these scripts do not run under set -e. Either drop it or make the caller act on it. > done > > # wire up namespaces > @@ -167,8 +176,12 @@ test_bond_recovery() > ip netns exec ${SWITCH} ip link set eth0 up > ip netns exec ${SWITCH} ip link set eth1 down > > - # re-verify connectivity > - slowwait 2 ip netns exec ${CLIENT} ping ${SWITCHIP} -c 2 -W 0.1 &> /dev/null > + # re-verify connectivity. With no member up the bond is supposed to > + # bring one up at once instead of waiting out updelay, so this must > + # stay below the smallest updelay the callers rely on, 5000ms, while > + # leaving enough room for a busy machine: two seconds is not enough > + # and the case with updelay 1000 fails now and then. > + slowwait 4 ip netns exec ${CLIENT} ping ${SWITCHIP} -c 2 -W 0.1 &> /dev/null This is a separate change and it is not mentioned in the subject or the body, only this comment explains it. Please split it into its own patch with its own justification, or at least describe it in the message. And the justification is what I am missing. bond_miimon_inspect() ignores updelay as soon as there is no active member (usable_slaves->count == 0 for xor, curr_active_slave == NULL for active-backup), so once eth1 goes down eth0 is brought up on the next miimon tick. With miimon 100 that is a few hundred milliseconds, not seconds. If the updelay 1000 case fails at 2 seconds now and then, either the box is heavily loaded or the kernel really waits somewhere, and a longer timeout would hide that. How long did the recovery take in the failed runs? Was that with the leftover namespaces already removed? Side effect to keep in mind: at 4 seconds the updelay 2000 case stops catching a bond that sits out its updelay, it would recover in ~2.1s and pass. Only the 5000 and 10000 cases remain a real check after this. The comment itself is again the commit message pasted into the test, one line at most, e.g. # must stay below the smallest updelay the callers use -- Konstantin Khorenko _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel