Re: [PATCH net] ip6_gre: let collect_md ip6gretap send from the unspecified address

[Anton Danilov <littlesmilingcloud@gmail.com>]

On Mon, Oct 05, 2026 at 07:20:34PM +0000, netdev-bot+sinfo@kernel.org wrote:
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.

Hit during development of the net-next series that annotates these
drivers with drop reasons. An LLM-assisted review of that series
flagged the misleading "dead loop" reason this check gives to frames
sent from :: when raddr is ::. Following that up with code inspection
and testing showed that for L2 collect_md devices the drop itself is
wrong, not just the label. The review of that series on the list asked
about the same case, and this fix was promised in the reply:

  https://lore.kernel.org/netdev/20261005174649.853236-1-littlesmilingcloud@gmail.com/

>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.

Triggered deliberately in a test VM; this is not a production report.
There is no stack trace or log message: the frames are dropped
silently, and the loss only shows up in counters. With frames bridged
from a veth into a collect_md ip6gretap device by tc (flower +
tunnel_key set + mirred) over a dummy underlay, five DAD-style
Neighbor Solicitations sent from :: give tx_errors +5 and tx_dropped
+5 on the tunnel device, zero packets on the underlay, and five
kfree_skb events in ip6gre_tunnel_xmit() (reason NOT_SPECIFIED). The
same frames sent from a link-local address are transmitted. With the
patch applied the frames from :: are transmitted as well, while the
check still fires for native ip6gretap with a configured remote and
for L3 collect_md ip6gre; each half of the new condition was verified
by removing it in turn and watching the case it protects start passing
frames it must not.

---

Anton Danilov