From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) (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 C588C21CC5C for ; Thu, 30 Jul 2026 03:50:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785383424; cv=none; b=fjqVq8ZvgZ6a4Jsp3cfv7akCIU04lpCtZP8t/ZmcZjJ6HxvGs5zEUrkP6qyjAG881S7spSoEb4crbdsavWa1wFXTzK4ZGkiJWsy/MQhP/ppKaD23FUbHRvlXj+7BOyx8UXZj1XikrOmH9s6FljvmEUNzAUT7G+JemVH5XGBWTqM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785383424; c=relaxed/simple; bh=+yi6uN5iRBIblyxibTs7ZkXcE1cO2XpCfbfHTAEmp1M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rbMYuZyvkMHK3wUhHgxx2nPM8pi6uROfdsUUm7nhlhHFGxtvBj5VGZre0HUK4wysR3MbcH+/Vp0w13G9qjBs39H6xtcZJ3vone8xztsHdM5pOYdJNQUhwyIiUHMr2xJc3FRHJ0ywBrqs6usSgxzUcR/oXFGzuxKGjwR7g9abVVE= 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=pgIgDB2c; arc=none smtp.client-ip=209.85.216.43 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="pgIgDB2c" Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-38e7109321dso1002922a91.3 for ; Wed, 29 Jul 2026 20:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785383423; x=1785988223; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=bRToeNqXboRrsPp4rN2QXShTZgRCA+alJAy+M1p+bqU=; b=pgIgDB2cBVMsjjHqMGcW2ZYkgIjuZw9KdkoF/21h9PtWIYty4RUkdW2T7hnn4l0xCc KmMqhVxBeHS6ovYjFr/VOUUA0PkDasj99ojUoQ7cXATiPze3AcIHIwX3O+unhLA71HIw 4bpvaUTA0WvbVAdzjRvJVaolF8uixV8GOkaeHtRYCHgEdocqZjN3xiOXbNZHHi13Stcw Q9KjymvQSl1UvYt4MVKsFlm2Ooc7Kzt6qePhZfIEawLs75o/1nKa2gqfmLk3wb7gOdvS UoDGnCtTx7xT1k92g464Ypteqc42ndlpRhQNVCzBh4UYN2czJsIzhqZKgJDG5Ald5Uqk ohvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785383423; x=1785988223; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=bRToeNqXboRrsPp4rN2QXShTZgRCA+alJAy+M1p+bqU=; b=ggmpJl6Bk8yC6IQ+3rOVv94S784f9MAVK/w5yMggNgNw8aKh87MAwTMqACr90FArBS STV7kpnJQ0S3bu6UTRR8FGdgOOtAiL68M3RDO52rwqtgxF3+z+7vByOwqwRuWldBxGYn +cYeDK3LW83Sn5fQ5g55fF3QbcsvKigN/O2woo+nP8ijjioHNoGOFkwdaS+bLKPCi6Dg Wdyio6+bIug0uTMijEUtfG/zWIBRqHOxUvMXAW8o0d9DIU68rhv6s5jlCGfXZHH5Gmwf /glrY7HA7MoyI8TsJDDiN6qwKqqCdYWkhYco+EDos5e504GDHERVWsFV1vgEpHdwcXmV Sy1A== X-Forwarded-Encrypted: i=1; AHgh+RpLLzocWK0AUmCAQIgw62HPATulOJBJW2OInftBrjbI+kdwmGLI26gP1LzeNpfK+oXHJ5iwTw9VHZ2d3Bs=@vger.kernel.org X-Gm-Message-State: AOJu0YzYaXLZptm2CtnfIcSqIwW2iOEW1dbXb5KwjhSlMVEyRflcyuuc BJ9ABrj5xkGIrQ2O+JmRmnCYYe+uHEOzQGLdJNsKCmABxSQrVIVUFnDk X-Gm-Gg: AR+sD13pU85aAiwosMqPlFUj7MXXdB2Fvi/PNS1uCX3k6rXWjjvgZ0sLswMS88COdhI 7UAE1xEM3NY8cX0ZV1RoMEPM13T/X4eAGA1VWm/0B95n33tKBCwczJo/3j3bUBXKjbMe5ALT6vy V2+Zpz/DFFl89uHgHUtZpR5SZ3gI2ZkaUl6QhuBz6JQj0BrvUzIKTic4rIRFtFJAbztWC+NgEy2 oX02qLVGpGbu1VnEFSCCwZfQAcogmjGnFHOVLmq9ISwpuHmCGOVSOkjLjVjOSeJdE8/OaPIMGvq lqpmGMlIK/k7398Ggk+o+GGsevDMsN7hmREQzOHLXzo3bw7iHhVicwENJYeJsfDdj8/P+pxLlP4 uS82JhP38YKxEgDjiojBQYLIOYi6cph7UJMJGzj1maOnG+beKtpMUcrQ2xjsCKgUvE2P5BCkZ2K ww8bdM8clbOWQoF6w5KF9QvcmbtYyEsW3HtIFaKXHGqPKSr5lLHQLYoCo= X-Received: by 2002:a17:90b:4c8b:b0:38e:673:5d18 with SMTP id 98e67ed59e1d1-38f9c035ba8mr772309a91.36.1785383422828; Wed, 29 Jul 2026 20:50:22 -0700 (PDT) Received: from fedora ([203.175.12.240]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38f9b72d243sm301354a91.10.2026.07.29.20.50.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2026 20:50:22 -0700 (PDT) Date: Thu, 30 Jul 2026 11:50:15 +0800 From: Hangbin Liu To: Xiang Mei Cc: Jay Vosburgh , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, AutonomousCodeSecurity@microsoft.com, tgopinath@linux.microsoft.com, kys@microsoft.com Subject: Re: [PATCH net] bonding: fix skb_under_panic in bond_ns_send() over stacked VLANs Message-ID: References: <20260719232153.1405569-1-xmei5@asu.edu> <2820549.1784570299@famine> 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=utf-8; format=flowed Content-Disposition: inline In-Reply-To: Hi Xiang, On 29.07.2026 16:30, Xiang Mei wrote: >> Does adding one or two more nested VLANs move the panic into the >> above call path? >> > >No, for both of the reasons above: there is no room to add more >(-EMLINK at N = 7), and skb_cow_head() would absorb it if there were. What about the scenario that involves nested VLANs? For example: vlan.1 - vlan.1.2 ... vlan.1..6 - bond - bond.1 - bond.1.2 ... bond.1..6? >Both symptoms have the same cause, tags inserted before any header >exists, so the fix is to build the probe in the order the stack uses: > > - push the IPv6 header first, so the reservation is consumed up front > and the later tag inserts grow the head via skb_vlan_push() instead > of eating it; > > - run the probe through NF_INET_LOCAL_OUT as a bare IPv6 packet, > exactly what ndisc_send_skb() feeds the hooks today. This needs a > small export (ndisc_attach_dst()) because ip6_route_me_harder() > dereferences skb_dst() unconditionally; > > - only then push the link-layer header and add the VLAN tags, so they > land at a real Ethernet header and the target address is untouched. > >With that applied the N = 1..6 wire capture is clean throughout. I kept >LOCAL_OUT deliberately so NS monitoring keeps traversing netfilter the >way it does today; dropping it would be simpler, but a silent behaviour >change. > >I am not familiar with the bonding and ndisc internals, so I posted it as >an RFC rather than presenting it as settled: > > https://lore.kernel.org/netdev/20260729230119.2717507-1-xmei5@asu.edu/T/#t I'm not sure if calling NF_INET_LOCAL_OUT in bond code is a good idea. Waiting for other's opinion. Thanks Hangbin