[Bug 227450] [patch] Should not all packets processed by gif_output be deleted, when an running instance of if_gif(4) is member of an instance of if_bridge(4)?
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 25 Jul 2025 04:58:55 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227450 --- Comment #15 from Koichiro Iwao <meta@FreeBSD.org> --- Just for the record, here's the minimal setup to reproduce. rc.conf is not modified from the default setup of FreeBSD-15.0-CURRENT-amd64-BASIC-CLOUDINIT-20250724-01c587521dd8-279004-ufs.qcow2.xz. hostname="freebsd" firstboot_freebsd_update_enable=YES growfs_enable=YES sshd_enable=YES nuageinit_enable=YES dumpdev="AUTO" ifconfig_DEFAULT="SYNCDHCP accept_rtadv" # RSA host keys are obsolete and also very slow to generate sshd_rsa_enable="NO" Set up minimal Ethernet over IPv6. ifconfig bridge0 create ifconfig epair0 create ifconfig gif0 create mtu 1500 ifconfig gif0 inet6 tunnel 2001:db8::1 3fff::1 ifconfig bridge0 addm gif0 addm epair0a 1753415597 (Wait around 5 minutes, kernel will panic) panic: gif_output: unexpectedly called with bridge attached cpuid = 2 time = 1753415820 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe008c2ac950 vpanic() at vpanic+0x136/frame 0xfffffe008c2aca80 panic() at panic+0x43/frame 0xfffffe008c2acae0 gif_output() at gif_output+0x5b/frame 0xfffffe008c2acaf0 ip6_output() at ip6_output+0x1ca5/frame 0xfffffe008c2accb0 mld_dispatch_packet() at mld_dispatch_packet+0x325/frame 0xfffffe008c2acd30 mld_fasttimo() at mld_fasttimo+0x520/frame 0xfffffe008c2ace10 softclock_call_cc() at softclock_call_cc+0x19b/frame 0xfffffe008c2acec0 softclock_thread() at softclock_thread+0xc6/frame 0xfffffe008c2acef0 fork_exit() at fork_exit+0x82/frame 0xfffffe008c2acf30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe008c2acf30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 2 tid 100039 ] Stopped at kdb_enter+0x33: movq $0,0x1235072(%rip) If an IPv6 (link-local) address is assigned to epair0a, it cannot be added to a bridge member, and IPv6 addresses cannot be assigned if the interface is a bridge member (invalid argument). However, even if the interface is a bridge member, a link-local address may still be assigned to it. The default rc.conf setup of the VM-IMAGE is the case. Kernel will panic when it tries to send traffic from the IPv6 address, as zlei mentioned. zlei's patch works fine for me. Shall we move forward? -- You are receiving this mail because: You are the assignee for the bug.