From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5E7639282C; Tue, 16 Jun 2026 15:50:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781625006; cv=none; b=YRUeotJKP1AjK9nIvcPgBGYuNF3rQO/4w1qX7m/IwAK+XF2I78W94SKbVrPke6Jebk/E3UBe71bQV49zLIIYaEP1o/xQJPhag4UUknICsaSqs9cD91YMsRba6TzOQkYHjH8Wd4bPrN3BBFH/ONAFHSF4hbm/nBzZSgbs8tAgRMI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781625006; c=relaxed/simple; bh=ZIv/J9+CgWCJCF8qX0SI/MYdLb24wZeIyZPBFCXUhG8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GILwbLn99yRGyR12+3lmwD8t3mr4r2Vq0Ajb9udoGK26fPOpGFdXWAPGz5XDmoBV9yDLzyAwuzHcRSTLjTxY7u6aPqSoKZyTrmOvvcc5UIie0/YwmKorf5KYyjf+zUMQVrjhdagn+YfHTdKBaMob60C9O49GjN6jGL0AuKTgOyY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=rcWkTPVe; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="rcWkTPVe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A85C1F000E9; Tue, 16 Jun 2026 15:50:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1781625005; bh=HNJolk6s+dP58r/nI6MY8QBetNweOs6tO2cZsR8/04s=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=rcWkTPVeKzjV1unBI70k9a3R3kqR1o5dR5Nfs96v6XWPpOjF8c7JC5zZDvY0A+jhn PY4n6FTD2rhmyYqBXAwmBZ/L/91Li/Zd/dNxUjSDtFOa0Ru/VRG390lqZiraHquT3J T7ag8jMy7k8i41qs5EXJL7jyxC4rR6fDxSltx4QQ= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Chirag Shah , Andy Roulin , Petr Machata , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.18 063/325] vxlan: vnifilter: send notification on VNI add Date: Tue, 16 Jun 2026 20:27:39 +0530 Message-ID: <20260616145100.836213319@linuxfoundation.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260616145057.827196531@linuxfoundation.org> References: <20260616145057.827196531@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Andy Roulin [ Upstream commit aa6ca1c5c338907817374b59f7551fd855a88754 ] When a new VNI is added to a vxlan device with vnifilter enabled, no RTM_NEWTUNNEL notification is sent to userspace. This means 'bridge monitor vni' never shows VNI add events, even though VNI delete events are reported correctly. The bug is in vxlan_vni_add(), where the notification is guarded by 'if (changed)'. The 'changed' flag is set by vxlan_vni_update_group() only when the multicast group or remote IP is modified, but for a new VNI added without a group (e.g. in L3 VxLAN interface scenarios), the function returns early without setting changed=true. Since this is a new VNI, the notification should be sent unconditionally. The notification is not guarded by the return value of vxlan_vni_update_group() because, at this point, the VNI has already been inserted into the hash table and list with no rollback on error. The VNI will be visible in 'bridge vni show' regardless, so userspace should be informed. This is consistent with vxlan_vni_del() which also notifies unconditionally. The 'if (changed)' guard remains correct in vxlan_vni_update(), which handles the case where a VNI already exists and is being re-added -- there, we only want to notify if the group/remote actually changed. Reproducer: # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \ nolearning external vnifilter # ip link set vxlan100 up # bridge monitor vni & # bridge vni add vni 1000 dev vxlan100 # no notification # bridge vni delete vni 1000 dev vxlan100 # notification received Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Reported-by: Chirag Shah Signed-off-by: Andy Roulin Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260602185138.253265-2-aroulin@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- drivers/net/vxlan/vxlan_vnifilter.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/vxlan/vxlan_vnifilter.c b/drivers/net/vxlan/vxlan_vnifilter.c index adc89e651e27c8..43c70c395b58e5 100644 --- a/drivers/net/vxlan/vxlan_vnifilter.c +++ b/drivers/net/vxlan/vxlan_vnifilter.c @@ -759,8 +759,7 @@ static int vxlan_vni_add(struct vxlan_dev *vxlan, err = vxlan_vni_update_group(vxlan, vninode, group, true, &changed, extack); - if (changed) - vxlan_vnifilter_notify(vxlan, vninode, RTM_NEWTUNNEL); + vxlan_vnifilter_notify(vxlan, vninode, RTM_NEWTUNNEL); return err; } -- 2.53.0