From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D43552248AF for ; Fri, 16 Jan 2026 21:01:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768597288; cv=none; b=Id9rFJNsZCBEjCkIHnlHg9IwKH1gvVwSlxWRbQ+n10JZR616EHGQEzUjy1YaSdDaGNIJYnH1UhWt83SOT/UAYz/IkCmjAIrflB57jOAW5nn07TYS0hh2vuQFHWEmj3ona19GAcvbOAz+da/1zL2bBgu7Br6fYNbj3PiEA6liY6c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768597288; c=relaxed/simple; bh=/Xh071rFobUifp9vg+391OtG1/GHsYcuoKH5i8JyjOg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZQLzeYKMwwjmQQA+rRd4fY+7Kxs3wY2x+5XMbKh68K2cpu5XoKwxFeTvy/QRzb1beRRozovylNlLEGxnb6++oCNMiln7HQk227W1F9CYVdBgy4e7OtLBKKgjv8iLvpLwguqadmVcpjOGiPmoGorno57S4o5rXNHhJabwzZccZeQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=S2jeg763; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="S2jeg763" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-430f3ef2d37so1844084f8f.3 for ; Fri, 16 Jan 2026 13:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768597285; x=1769202085; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=aXlyykM87bz8EPPmErTX2/nMizjLMi1IDXeb9kqCDiE=; b=S2jeg763oGMvOb2mBNJhei7xpYnLP7JJO66GgwHTeN85bumqS2b4dc894XOOzLYvqg gPRydq+IVVHDlLMhM5iqlwbYJXKnagmyqvhdgJkwVtZ+rnh163dPCKuWvnrQ7fbdvpFH 2gKrou1g7aEL96c1vqsUZH0opdGQr8GQePf9PB6cuoUl6NF7Vrvp7xfCH7DTaXqlbBmX GB5Jii7QHPgdQaYb8mjfNaxIpHfOxJ1GViFgE639IhwyfHnotfSjAy+4NDKFYlp4oakA 8FRQcMZrI9Qrw5f9IPO8G+tNKYOcA/0S+FTCZhliTfvsGiP23Ao7HLPvusxldDgsGkY2 QAug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768597285; x=1769202085; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aXlyykM87bz8EPPmErTX2/nMizjLMi1IDXeb9kqCDiE=; b=vtt3izSM1Fi5PlvnUNuFt4T5XnUO4Iqiy9Jfc3SZvqaItGOtBkVWwkxJJiWXkRgJMF DpCqdlFuTbdzznYRs0djEzGjDYyenYSNAjdJYuQwWOYk8E24k1UKw0bfHVZYuQZlOLbG 4H4u1NpASP/AkyUpXamU56kT8cK1AH9H8cQSv7DEIG5LCipdZvaYKtqywoBEG2oeNjVS 5OiS+g4sfIy/NSTtgyQc8Fe81zkYSFSD+DUiEDbOvDnpstV+JDxmREOJpqRTWYPnBNdw ab2QrZBa8GWi5yg3zSfZo59tNiXpe8gJJHkFmjIwDxvdq99JJ86w4dxorzbrF2CC5bbU kVnw== X-Forwarded-Encrypted: i=1; AJvYcCXuWbHRz6yrBNgWt9W0adUh7lXQgMKXeIFQSXETJPhoZ7ES1npvBVGpx7wclO9QQPUA8R+UHsZNR1Yt7v8=@vger.kernel.org X-Gm-Message-State: AOJu0YwqhOcf+C/PT7MQrAzuWKYdOILsdCSZYGKN0ly2IRvXOdg7KLKL yViSbA1A82rRKd+LnaI1HiDvM8ZT0VHCd39RjUthXKx5SsXjSI6gcbUxBb7T/6ghr0M= X-Gm-Gg: AY/fxX7r5IS+SEnp0fKLexo5y96u6SvVhd+eF/UNcVuvDPPHgyly+CYwkwWgqmDU8Sg h5bdknc9SOT+vNSs7bmeG2VlYV8iaCWBKnUihULmUGAczRp1Q0/jIZS8WarZAXu+V75HvPKuvwV Le2d3HtZMirRdOldepd2S+l3UMsvDBTRY8qH5mxP4kaXgcjPdPKQQgL8OUXAf08VwG3xiBu/DOh 2mHGHf/W/OX4c5RnngkCnnPjCJgEbfkhmntPvIz7RidUoGWBZUmLCOwwMVPviqk3pzZoN0vVWwR K2QheUMooetBEC3D2+MtePCuA82cp9sGwcZT19YPULpqFHhS8EsHutyuakTpTLm6b9I6ap60jt5 n7OkckfxtLkVV20t2ZaIHvHccnblRCCsik6YSijjBpHeioJoUY3UesE+bqSA1R+nKOpmOTHINBL qC2vE2gQ== X-Received: by 2002:a05:6000:4387:b0:431:1ae:a3d0 with SMTP id ffacd0b85a97d-435699810a1mr5156199f8f.25.1768597284962; Fri, 16 Jan 2026 13:01:24 -0800 (PST) Received: from archlinux ([143.58.192.3]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435699982aasm7545219f8f.42.2026.01.16.13.01.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jan 2026 13:01:24 -0800 (PST) Date: Fri, 16 Jan 2026 21:01:22 +0000 From: Andre Carvalho To: Jakub Kicinski Cc: Breno Leitao , Andrew Lunn , "David S. Miller" , Eric Dumazet , Paolo Abeni , Shuah Khan , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH net-next v10 7/7] selftests: netconsole: validate target resume Message-ID: References: <20260112-netcons-retrigger-v10-0-d82ebfc2503e@gmail.com> <20260112-netcons-retrigger-v10-7-d82ebfc2503e@gmail.com> <20260112061642.7092437c@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260112061642.7092437c@kernel.org> On Mon, Jan 12, 2026 at 06:16:42AM -0800, Jakub Kicinski wrote: > On Mon, 12 Jan 2026 09:40:58 +0000 Andre Carvalho wrote: > > Introduce a new netconsole selftest to validate that netconsole is able > > to resume a deactivated target when the low level interface comes back. > > > > The test setups the network using netdevsim, creates a netconsole target > > and then remove/add netdevsim in order to bring the same interfaces > > back. Afterwards, the test validates that the target works as expected. > > > > Targets are created via cmdline parameters to the module to ensure that > > we are able to resume targets that were bound by mac and interface name. > > The new test seems to be failing in netdev CI: > > TAP version 13 > 1..1 > # timeout set to 180 > # selftests: drivers/net: netcons_resume.sh > # Running with bind mode: ifname > not ok 1 selftests: drivers/net: netcons_resume.sh # exit=1 > -- > pw-bot: cr I've finally been able to reproduce this locally. The issue is caused by the fact that the test currently expects that mac addresses for netdevsim devices are deterministic. This is the case on my setup as systemd enforces it (MACAddressPolicy=persistent). I was able to disable this behaviour by setting up /etc/systemd/network/50-netdevsim.link, with: [Match] Driver=netdevsim [Link] MACAddressPolicy=none I'm assuming this is also the behaviour on CI hosts. I have started working on a fix for this test and will submit v11 once that is ready. The approach I'm taking is saving and restoring the mac addresses once I reload netdevsim module. Example code below (needs more testing): function deactivate() { # Start by storing mac addresses so we can be restored in reactivate SAVED_DSTMAC=$(ip netns exec "${NAMESPACE}" \ cat /sys/class/net/"$DSTIF"/address) SAVED_SRCMAC=$(mac_get "${SRCIF}") # Remove low level module rmmod netdevsim } function reactivate() { # Add back low level module modprobe netdevsim # Recreate namespace and two interfaces set_network # Restore MACs ip netns exec "${NAMESPACE}" ip link set "${DSTIF}" \ address "${SAVED_DSTMAC}" if [ "${BINDMODE}" == "mac" ]; then ip link set dev "${SRCIF}" down ip link set dev "${SRCIF}" address "${SAVED_SRCMAC}" # Rename device in order to trigger target resume, as initial # when device was recreated it didnt have correct mac address. ip link set dev "${SRCIF}" name "${TARGET}" fi } The main annoyance is that to test resuming when a device was bound by mac I actually need to change the name of the device after restoring the mac address (since when the device is registered after deactivation the mac won't match). -- Andre Carvalho