From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 EFB9424291E for ; Mon, 5 Jan 2026 18:14:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767636858; cv=none; b=U8X814vNlTc9V4TXys3Y2eQ3Vlv8F9Esnc5Cjn0Q4U7AXLEI9eDn5K2+K56/5ZGRw0uxWI1qrCmDv+NJVjeuaUEFtSTqdeMxTSReVwjqHC9abq43yRQ3OP2Y7HbMf4IrebV1TvHTuqDHN2rhF4Zf5Jy+87Nr10Hi0g8mD8hG+TE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767636858; c=relaxed/simple; bh=bqtNUILbm6lJat/9Xu0gpKiAI1RZvgXVDpApnTxDQMU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=phRiL+z5ujClaAAar/q1/oKkx0OzfRoJ8jqMNneFp7bgZHP7lFJATximpuKtLcUGLNPx5gxJNfraQU4jB5mJsEJv53YaNDcwSH2BN7GD8ExAbKcJRHBbX+3o03Dur6UOi2IVekF6mBZ0sXN38Hk+V2CSHvHfU5GgOMWWQu3FZgo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=LMS0fZK+; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org 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="LMS0fZK+" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-430f9ffd4e8so1027122f8f.0 for ; Mon, 05 Jan 2026 10:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767636855; x=1768241655; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:sender:from:to:cc:subject:date:message-id:reply-to; bh=/oP9O+J1jrunuk+Y661pj013SgRFAFyNbhxBfEwCmlA=; b=LMS0fZK+OcvnH2SLJUlfefKr5m2N44kV8AVnzvzSavD+dOeuKvn0xwu6F0AKfW3qCu r3dtXyUjGdpyFV8SvoZ0RU7u05UyCyiMV4BRB2bfaCmpddUGrbgE69Slr562+ULf3FRJ gXc6VFYne2jdZb+1X/fZ/NbSn+b8xRQH5a692xPH2J2PpLt0+bb28Jk01n58fdWnphLv Rpx9rMXDGWlL9q5buhbwk0MlNiIeJSPDNesd1H+6s6wD0l/MIOnIekqr65xF7jOHbp2r 8eWPLNcRX+dPpJUuNSDEf5+Jh6MNMkSAp268mq/MykE/K6P+4gPpOPi0B4NYitH21ekf 9uig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767636855; x=1768241655; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:sender:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/oP9O+J1jrunuk+Y661pj013SgRFAFyNbhxBfEwCmlA=; b=qN/BwNoSdBeUPvUiHQa7zPigBG0d1U6GnDAL2SwvkLZBOX7OKGxNSIvvMNn4TfJzQG l95TYi7KqTJGhuaqBePWl2QRitpfIotakLLu8mBS+GnSOOgmAu8EKbSru62yVFY3W673 eczPh6sslQL4B0CzcKOBYfufDPJrRhu4lZkK0kFkWmbgOnS1QT+mL/hVXAbTGke2IdnE WG5RTgTRn16WdS5VtuRS6reUpw2EupyDFDX+XgBlnnxtWudNxKFSFjVqPlsqwaS4xHqw OcXalcgMJcTMmTLzPjKEQ6OPm+G9xSEdwx+FyhzO1tTTzP80zKRxg/6coojEA4rpoILJ yfKg== X-Forwarded-Encrypted: i=1; AJvYcCX298tjGtZU/KXmJJBeXbQTXB6sQIAHJtljEvvSvIRVea+zqwPxNuTp4/2MxCyXEJn46+4LNTo=@vger.kernel.org X-Gm-Message-State: AOJu0YzwpQK4tqo9bTR1gFdNeUR4rtquT1d+ijBPBdE1jmBtsVjwkoVs YzrXbFwXElPhnVJZd6+FDxhjIXCT4yIG1J/VAiCSiKsEEM0Pd8mC5ovp X-Gm-Gg: AY/fxX6U6NDH+E1acYIRc+FDdlrPZcBTGYHP5M/6Mk2QMvTm62q3ykyeiEXFFM/FWm5 TnsL3/zSV68hFMY4LI+xA2/vUvO2gjEjr/8Xdr0/lpR1pyntSCVwhzyRE+jKTv5xSruLG2jtSTI BNcO9u4nqMkNftxj1Yq56EDcI3loac49K+BoxuYMHPE5Iawu9bRvpsD3ztJNFKvGA/Uq5RZKMOv CKWDoTqXvVZ0RvLPxkwbrNb7c7jOxZp6tjXlkRUJ6ytipX6PWaAYp2Gj8hUWTJrumM0nWTQ00Ok Ay0lP9jx4arpRN32JD3cpbhejY69NCfW/vLlCUUHpKfxF8y6ZgnhErHrXgQhZgEqVcPZLC4ZT2T mKAa+EoaiEvivn1oyMZrFuLLR7J/7NvL/yZfIqWjRtfri1d2bzPKCQjQwig2jmoyhOKeAKchCyi LuykfQCSYG17ZEg7uEZ/LKaqQlKGvVx4tsIwssLcNOEsR4s1HjvEUfHIs= X-Google-Smtp-Source: AGHT+IE/WbbnXt6m79lszz8chS7NFY/jLDyt4rB9ShhndFA1aa1Z8u6f+/lIFkSh4Lfi6OF6YByoxQ== X-Received: by 2002:a05:6000:26ce:b0:430:f3bd:71f8 with SMTP id ffacd0b85a97d-432bcfde915mr70237f8f.25.1767636855046; Mon, 05 Jan 2026 10:14:15 -0800 (PST) Received: from eldamar.lan (c-82-192-244-13.customer.ggaweb.ch. [82.192.244.13]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bca5a132sm688291f8f.39.2026.01.05.10.14.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 10:14:14 -0800 (PST) Sender: Salvatore Bonaccorso Received: by eldamar.lan (Postfix, from userid 1000) id 44C5FBE2EE7; Mon, 05 Jan 2026 19:14:13 +0100 (CET) Date: Mon, 5 Jan 2026 19:14:13 +0100 From: Salvatore Bonaccorso To: Thorsten Leemhuis Cc: Ben Hutchings , Roland Schwarzkopf , Nikolay Aleksandrov , David Ahern , "David S. Miller" , Sasha Levin , debian-kernel@lists.debian.org, Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Greg KH , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, regressions@lists.linux.dev, 1124549@bugs.debian.org Subject: Re: [regression 5.10.y] Libvirt can no longer delete macvtap devices after backport of a6cec0bcd342 ("net: rtnetlink: add bulk delete support flag") to 5.10.y series (Debian 11) Message-ID: Mail-Followup-To: Thorsten Leemhuis , Ben Hutchings , Roland Schwarzkopf , Nikolay Aleksandrov , David Ahern , "David S. Miller" , Sasha Levin , debian-kernel@lists.debian.org, Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Greg KH , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, regressions@lists.linux.dev, 1124549@bugs.debian.org References: <0b06eb09-b1a9-41f9-8655-67397be72b22@mathematik.uni-marburg.de> <176608738558.457059.16166844651150713799@eldamar.lan> <27c249d80c346a258cfbf32f1d131ad4fe64e77c.camel@debian.org> <6498cffd-5bf9-490a-910d-f64ab9b7f330@leemhuis.info> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6498cffd-5bf9-490a-910d-f64ab9b7f330@leemhuis.info> Hi, On Mon, Jan 05, 2026 at 01:30:59PM +0100, Thorsten Leemhuis wrote: > @stable team and/or @net maintainers: this imho needs a judgement call > from your side. See below for details. > > On 1/2/26 21:18, Ben Hutchings wrote: > > On Fri, 2025-12-19 at 10:19 +0100, Thorsten Leemhuis wrote: > >> On 12/18/25 20:50, Salvatore Bonaccorso wrote: > >>> > >>> Is there soemthing missing? > >>> > >>> Roland I think it would be helpful if you can test as well more recent > >>> stable series versions to confirm if the issue is present there as > >>> well or not, which might indicate a 5.10.y specific backporting > >>> problem. > >> > >> FWIW, it (as usual) would be very important to know if this happens with > >> mainline as well, as that determines if it's a general problem or a > >> backporting problem > > [...] > > > > The bug is this: > > > > - libvirtd wrongly used to use NLM_F_CREATE (0x400) and NLM_F_EXCL > > (0x200) flags on an RTM_DELLINK operation. These flags are only > > semantically valid for NEW-type operations. > > > > - rtnetlink is rather lax about checking the flags on operations, so > > these unsupported flags had no effect. > > > > - rtnetlink can now support NLM_F_BULK (0x200) on some DEL-type > > operations. If the flag is used but is not valid for the specific > > operation then the operation now fails with EOPNOTSUPP. Since > > NLM_F_EXCL == NLM_F_BULK and RTM_DELLINK does not support bulk > > operations, libvirtd now hits this error case. > > > > I have not tested with mainline, but in principle the same issue should > > occur with any other kernel version that has commit a6cec0bcd342 "net: > > rtnetlink: add bulk delete support flag" > > FWIW, merged for v5.19-rc1 and backported to v5.10.246 as 1550f3673972c5 > End of October 2025 in parallel with 5b22f62724a0a0 ("net: rtnetlink: > fix module reference count leak issue in rtnetlink_rcv_msg") [v6.0-rc2], > which is a fix for the former. > > > together with an older version of libvirt. > > > > This was fixed in libvirt commit 1334002340b, which appears to have gone > > into version 7.1.0, > > Could not find that commit when looking briefly, but that version was > released 2021-03-01. For reference it is this one I think: https://gitlab.com/libvirt/libvirt/-/commit/81334002340be6bd3a1a34c6584a85fe25cc049c Regards, Salvatore