From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.173 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792720607; b=TOM+se+cYtncmGxdlhE3OFpA0qBDMHC30RfpZsFEBjA1sLkPkdEOks6DlcBC5TsOgxiR L7uZMJt6ydvXK0YeJBYRUtRSXGFFyfQOsSHN4zlr1Y2hymLBoarPti7VfCq9R9nCXgGMS 0S2/tdSksnuJ6FzI3yHEuCQHXIV8L+wzvBlsGgCdCPU+S2nmW42bFxfdduFmn0ZuQBGF3 gE35Najka4Gka3zPx4c/DMjLesvpzxf7tuUvahkj+A8YzucKW7OdVAaA5EtaA7L6s+Vsd wnmcJfqs0yq5C8P8jhIp4S4vr23I2rhnmwtxHqVLg0sFVkgAqLf1KhpjNPwPUUH8QYg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792720607; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=oJFZy9ViA1hdkCiyEzcB0JcdRGfXjVzuA0WGwLAmCs4=; b=3Tbv6NvZHefNekGQ1MOn5oAiwQYTPsRGW/PAQ1cCPo06CNeCNZgBScppRRMcMLeGQoUC NcAQP0b17ZGzODbBNwBUPPtA8285FrDrsSe7SbNErSklaN/PFNCarFbzx/rZRP6w1NmGA /uJm1x4LSFHrxibXWx77JUYJC5k3vk/YMamj91kAMsza5r2skDVwcTqvOYk68B632cyyI Ppz35Tf3T0Uw5Hs8RqmCf0a/ghbELC1rFWKp00Oo683fFC13aY/zfZudNzdUb7V0btsZK tEueBUCFOwF27ahWhO/+aNRgNewkK7TGDZuC/GhnMa2/yyViQ6VZyfInhExrFQG6WZg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=lFDEReVK; arc=none smtp.remote-ip=95.215.58.173 Received: from mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90358606A31F for ; Fri, 23 Oct 2026 01:56:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 90358606A31F Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=lFDEReVK X-Envelope-To: netdev@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=uX9E3o73V748llMETRdDfpWjDG+k2zeZTW03xJwVkb0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1792720603; v=1; x=1793325403; b=lFDEReVKixlCCV8aln0VUOKnuYSlp8pGFtrke7nXPTicTCunZ0H8IlsIY4l4xMkG6xCOdQub qnGxz1sHC4r301LLvNBrT/Au2ztMkB7/IAGCmIC3V7Ws1h61Pjg4urSiVsPv8Lf/Z/reEb56Vtk q48DpLvM5j1fEAqr7eg9wOq4= X-Envelope-To: netdev@vger.kernel.org Received: by mta12.migadu.com with ESMTPS id 1f1f20d373d9e1ae; Fri, 23 Oct 2026 01:56:43 +0000 X-Mizu-Trace-ID: 1f1f20d373d9e1ae X-Migadu-Flow: FLOW_OUT Date: Fri, 23 Oct 2026 09:56:32 +0800 From: Hangbin Liu To: Xia Yan Cc: netdev@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org, horms@kernel.org, kuba@kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, pabeni@redhat.com, shuah@kernel.org, stable@vger.kernel.org Subject: Re: [PATCH net v3 1/2] veth: keep carrier off when resizing channels with a down peer Message-ID: References: <20261022085842.2527-1-yana06070@163.com> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261022085842.2527-1-yana06070@163.com> On Thu, Oct 22, 2026 at 04:58:41PM +0800, Xia Yan wrote: > veth_set_channels() temporarily turns carrier off while reconfiguring a > running interface. It then turns carrier on for both ends without > checking whether the peer is administratively up. If only one end is up, > changing its channel counts therefore reports LOWER_UP even though the > peer remains down. > > For example, after creating a pair with two RX and TX queues per end: > > ip link set vca up > ethtool -L vca rx 1 tx 1 > > vca incorrectly reports LOWER_UP while vcb is still down. > > Only restore carrier when the peer has IFF_UP, matching veth_open(). > The local interface is already known to be running at this point. > > Found during LLM-assisted source review and reproduced with a veth pair > in network namespaces, without kernel instrumentation or error injection. > With the complete default veth.sh on x86_64 QEMU/KVM (three vCPUs), the > four mixed up/down cases fail before the fix and all six carrier cases > pass after it. All 55 existing checks pass on both kernels. > > Fixes: 4752eeb3d891 ("veth: implement support for set_channel ethtool op") > Cc: stable@vger.kernel.org > Assisted-by: LLM > Signed-off-by: Xia Yan > --- > > Notes: > Changes in v3: > - Driver code is unchanged from v2. > - The companion selftest is now part of veth.sh. > > v2: https://lore.kernel.org/netdev/20261020135544.24441-1-yana06070@163.com/ > > Testing on the v2 baseline 513444cc62e2: > - Complete default veth.sh on x86_64 QEMU/KVM, three vCPUs: > before: 57 checks pass, four mixed up/down carrier checks fail; > after: all 61 checks pass. The 55 existing checks pass on both. > - bash -n and git diff --check pass. > - If creating the veth pair fails, the case is skipped without > masking failures from earlier test cases. > > Both patches also apply to net/main ffdf678dd166 > (application check only, checked on 2026-10-22). > > The QEMU guests failed to power off cleanly (initramfs issue) after > the tests completed; the exit codes above are the veth.sh results. > > > drivers/net/veth.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/veth.c b/drivers/net/veth.c > index 643b97d..4e75830 100644 > --- a/drivers/net/veth.c > +++ b/drivers/net/veth.c > @@ -1372,9 +1372,10 @@ static int veth_set_channels(struct net_device *dev, > * to identify the range we have to disable > */ > veth_disable_range_safe(dev, new_rx_count, old_rx_count); > - netif_carrier_on(dev); > - if (peer) > + if (peer && (peer->flags & IFF_UP)) { > + netif_carrier_on(dev); > netif_carrier_on(peer); > + } > } > > /* update XDP supported features */ > > base-commit: 513444cc62e231a11c9b15ea88de0890da9b2b4f > -- > 2.43.0 > This one looks good to me. I can reproduce the report issue. Reviewed-by: Hangbin Liu