[Bug 247647] vmxnet3(4): Page fault when opening netmap port (IFLIB/DMA)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247647 Kubilay Kocak changed: What|Removed |Added Keywords|needs-qa| Assignee|n...@freebsd.org |vmaffi...@freebsd.org CC||n...@freebsd.org URL||https://reviews.freebsd.org ||/D25541 Summary|panic: page fault when |vmxnet3(4): Page fault when |opening netmap port |opening netmap port |(vmxnet3) |(IFLIB/DMA) Flags|maintainer-feedback?(pkelse |mfc-stable12? |y...@freebsd.org) | --- Comment #13 from Kubilay Kocak --- ^Triage: Assign to committer resolving, set URL to related review, track pending merge (stable/12) flag Thank you Vincenzo! -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 247647] panic: page fault when opening netmap port (vmxnet3)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247647 --- Comment #12 from Zhenlei Huang --- (In reply to Vincenzo Maffione from comment #11) Thx :) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: somewhat reproducable vimage panic
Kristof Provost wrote this message on Thu, Jul 23, 2020 at 11:02 +0200: > On 23 Jul 2020, at 11:00, Bjoern A. Zeeb wrote: > > On 23 Jul 2020, at 8:09, Kristof Provost wrote: > > > >> On 23 Jul 2020, at 9:19, Kristof Provost wrote: > >>> On 23 Jul 2020, at 0:15, John-Mark Gurney wrote: > So, it's pretty easy to trigger, just attach a couple USB ethernet > adapters, in my case, they were ure, but likely any two spare > ethernet > interfaces will work, and wire them back to back.. > > >>> I???ve been able to trigger it using epair as well: > >>> > >>> `sudo sh testinterfaces.txt epair0a epair0b` > >>> > >>> I did have to comment out the waitcarrier() check. > >>> > >> I???ve done a little bit of digging, and I think I???m starting to > >> see how this breaks. > >> > >> This always affects the jailed vlan interfaces. They???re getting > >> deleted, but the ifp doesn???t go away just yet because it???s still > >> in use by the multicast code. > >> The multicast code does its cleanup in task queues, > > > > Wow, did I miss that back then? Did I review a change and not notice? > > Sorry if that was the case. > > > > Vnet teardown is blocking and forceful. > > Doing deferred cleanup work isn???t a good idea at all. > > I think that is the real problem here. > > > > I???d rather have us fix this than putting more bandaids into the > > code. > > > Yeah, agreed. I think hselasky has a better fix: > https://reviews.freebsd.org/D24914 > > I just saw his e-mail in a different thread. I'm testing out this patch now, and let people know how it goes.. It'll be nice to not have to worry about these panics.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248213] TCP BBR - Two FINs with same seq number are seen in simultaneous close
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248213 Michael Tuexen changed: What|Removed |Added Assignee|n...@freebsd.org |tue...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248213] TCP BBR - Two FINs with same seq number are seen in simultaneous close
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248213 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: somewhat reproducable vimage panic
On 23 Jul 2020, at 9:02, Kristof Provost wrote: On 23 Jul 2020, at 11:00, Bjoern A. Zeeb wrote: On 23 Jul 2020, at 8:09, Kristof Provost wrote: On 23 Jul 2020, at 9:19, Kristof Provost wrote: On 23 Jul 2020, at 0:15, John-Mark Gurney wrote: So, it's pretty easy to trigger, just attach a couple USB ethernet adapters, in my case, they were ure, but likely any two spare ethernet interfaces will work, and wire them back to back.. I’ve been able to trigger it using epair as well: `sudo sh testinterfaces.txt epair0a epair0b` I did have to comment out the waitcarrier() check. I’ve done a little bit of digging, and I think I’m starting to see how this breaks. This always affects the jailed vlan interfaces. They’re getting deleted, but the ifp doesn’t go away just yet because it’s still in use by the multicast code. The multicast code does its cleanup in task queues, Wow, did I miss that back then? Did I review a change and not notice? Sorry if that was the case. Vnet teardown is blocking and forceful. Doing deferred cleanup work isn’t a good idea at all. I think that is the real problem here. I’d rather have us fix this than putting more bandaids into the code. Yeah, agreed. I think hselasky has a better fix: https://reviews.freebsd.org/D24914 I just saw his e-mail in a different thread. That’ll probably work; still, the deferred teardown work seems wrong to me; I haven’t investigated; the patch kind-of says exactly that as well: if “wait until deferred stuff is done” is all we are doing, why can we not do it on the spot then? /bz ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 247647] panic: page fault when opening netmap port (vmxnet3)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247647 --- Comment #11 from Vincenzo Maffione --- Once a commit hits master, we wait for a settling period (e.g. 2 weeks) to give other developers and users the chance to hit possible regressions and problems. If nothing shows up, the commit can be merged to the stable/12 branch (and it will be in this case). Once merged to stable/12, you will be able to get it if you download the FreeBSD-12-STABLE iso. Finally, the commit will be automatically included in the next 12.x release. In this case (https://www.freebsd.org/releng/), this is going to be FreeBSD 12.2 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248046] if_bridge(4): Panic when creating an interface: malloc(M_WAITOK) in epoch context
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248046 Mark Johnston changed: What|Removed |Added Flags|mfc-stable12? |mfc-stable12+ Assignee|n...@freebsd.org |k...@freebsd.org CC||ma...@freebsd.org Resolution|--- |FIXED Status|Open|Closed -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 242406] mpd & 3G USB modem: Fatal trap 12: page fault while in kernel mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242406 Mark Johnston changed: What|Removed |Added Assignee|n...@freebsd.org |ma...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 242406] mpd & 3G USB modem: Fatal trap 12: page fault while in kernel mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242406 Mark Johnston changed: What|Removed |Added Status|Open|In Progress --- Comment #13 from Mark Johnston --- https://reviews.freebsd.org/D25788 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 242406] mpd & 3G USB modem: Fatal trap 12: page fault while in kernel mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242406 --- Comment #12 from Mark Johnston --- (In reply to Michael Muenz from comment #11) Thanks. Do you happen to use VNET jails at all? If so it would be useful to know that ng_tty still works as expected if you pass the associated interface into a jail. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172
--- Comment #20 from Gert Doering ---
Just for the record: if I insert a "sleep(1)" in the tester.c between the
open() call to /dev/tun0 and the ifconfig statement, *and* insert a "sleep 1"
in pccard_ether between "`ifconfig -ul` and if [ "${uif}" = "${ifn}" ] - then
the time window for the race is wide enough that "it always happens".
Of course it would be great to find a non-racy solution that does not involve
telling users "you must change your rc.conf to make openvpn+ipv6 work reliably
for you" (they might actually have "on all interfaces" disabled on purpose).
But I can already say: thanks for all your help!
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Abandoning ifnet work
On Thu, Jul 23, 2020 at 3:38 AM Hans Petter Selasky wrote: > > On 2020-07-23 05:45, Kyle Evans wrote: > > abandoning because the review process for this area is simply not > > Are you looking for this: > > https://reviews.freebsd.org/D24914 > No, not at all. The race I was reliably hitting is more like: 1. epair sets its vnet 'to the other half' in epair_clone_destroy 2. destroys that 3. goes to CURVNET_RESTORE(), but the vnet we were in has been destroyed out from underneath us and we die in a fire trying to check saved_vnet->vnet_magic_n Thanks, Kyle Evans ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172
--- Comment #19 from Gert Doering ---
(In reply to Andrey V. Elsukov from comment #17)
Thanks for the explanation.
I wonder if there is an easy way to trace these scripts, to see when exactly
something was ifconfig'ed?
I've sprinkled the pccard_ether script with "logger" commands now, and I can
see that it will not touch the tun0 interface "if it is already up" (in
pccard_ether_start()). In that case, I have no IFDISABLE.
If I do "ifconfig tun0 create" by hand, I see it enters quietstart, and I do
get IFDISABLE.
The added "logger" commands do modify the timing, so it's indeed a race
condition. If I have no loggers in the script *before* the decisions about "is
this interface already up or not" are made, I can see it go to quietstart, and
OpenVPN and the kernel message confirm "now it's IFDISABLED".
Jul 23 12:50:09 fbsd-tc root[74575]: pccard_ether_start, ifn=tun0
Jul 23 12:50:09 fbsd-tc root[74579]: pccard_ether_start, quietstart
Jul 23 12:50:10 fbsd-tc kernel: nd6_dad_timer: cancel DAD on tun0 because of
ND6_IFF_IFDISABLED.
This is good news, actually, because it turns out to be "very likely not a
kernel bug". Apologies for jumping to a conclusion here.
On the other hand it's bad news, because I do not know how to fix this "for
good". If an OpenVPN user does not have IPv6 enabled on his regular LAN
interfaces, he might not have ipv6_activate_all_interfaces="YES" set.
Even for someone who *has* IPv6 active (like, me, on that test box) that
setting might not be set - because having "ifconfig_em0_ipv6" and
"ipv6_defaultrouter" are perfectly fine to get what I want ("a static v6
address + default route").
But they want IPv6 to work inside the tunnel, if their VPN server has working
v6 (it might be their only way to reach the IPv6 Internet).
So what should I do? Stick to "sleep(1); ifconfig tun0 inet6 -ifdisabled"?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172 --- Comment #18 from Eugene Grosbein --- This depends on devd(8) daemon being enabled/running or not running at the moment of creation of network interface. If devd is running (and modern FreeBSD tends to require this), it is notified by the kernel about creation of new network interface. devd with default /etc/devd.conf responds with invoking "/etc/pccard_ether $subsystem start", and it processes all interfaces, not "pccard" only. The script does multiple actions on new interface and it acts according to settings from /etc/rc.conf. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172 --- Comment #17 from Andrey V. Elsukov --- When you create tun/tap interface, the kernel generates LINK_UP event, then devd handles this event and invokes /etc/pccard_ether script, that uses routines from network.subr script. You may have some races with this script. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172 --- Comment #16 from Gert Doering --- (In reply to Andrey V. Elsukov from comment #15) This is still missing the point. If having ipv6_activate_all_interfaces="YES" is a hard requirement now, the interface should *always* come up with IFDISABLED, not "just sometimes". This needs to be deterministic: behave the same on every instanciation. No dependency on timing or other random factors. My tun/tap interfaces are not brought up by /etc/rc.*, so I'm not sure if rc.subr should play a role here - maybe it does, due to some dynamic invocation on interface creation that I am not aware of - pointers welcome. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: somewhat reproducable vimage panic
On Thu, 23 Jul 2020 11:02:01 +0200 "Kristof Provost" wrote: > Yeah, agreed. I think hselasky has a better fix: > https://reviews.freebsd.org/D24914 Yup, that should be it. > > I just saw his e-mail in a different thread. > > Best regards, > Kristof > ___ > freebsd-curr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172 --- Comment #15 from Andrey V. Elsukov --- (In reply to Gert Doering from comment #14) Presence of this flag is under control of /etc/network.subr script. And this always worked via rc.conf. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172 --- Comment #14 from Gert Doering --- (In reply to Andrey V. Elsukov from comment #12) rc.conf settings can not be the correct answer for spurious and timing-dependent differences in behaviour. Also, I can not control what our users will do (and they might not have IPv6 on the LAN side, so might not have turned it on in rc.conf) - so I need a reliable and robust way to bring up a tunnel interface with IPv6, independent of rc.conf settings. Adding some argument to our ifconfig call (or adding some extra ioctl()s or whatever) is not a problem, but right now I need an extra "sleep(1)" before the "ifconfig $dev inet6 -ifdisable", which looks race'y and probably is... -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172 --- Comment #13 from Gert Doering --- New test program coming, so please ignore this one. There is something else needed to make this trigger more often, like "packets in queue for this interface" or an actual reader on the tunfd. (OpenVPN test suite triggers this 90% for some cases, openvpn itself triggers in like 20% of all cases *with the same options* as if called by the test suite, test script in the version uploaded so far triggers in 1%...) -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172 Andrey V. Elsukov changed: What|Removed |Added CC||a...@freebsd.org --- Comment #12 from Andrey V. Elsukov --- You just need to enable IPv6 in rc.conf. ipv6_activate_all_interfaces="YES" When it is enabled, all new interfaces will be created without IFDISABLED flag. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: somewhat reproducable vimage panic
On 23 Jul 2020, at 11:00, Bjoern A. Zeeb wrote: On 23 Jul 2020, at 8:09, Kristof Provost wrote: On 23 Jul 2020, at 9:19, Kristof Provost wrote: On 23 Jul 2020, at 0:15, John-Mark Gurney wrote: So, it's pretty easy to trigger, just attach a couple USB ethernet adapters, in my case, they were ure, but likely any two spare ethernet interfaces will work, and wire them back to back.. I’ve been able to trigger it using epair as well: `sudo sh testinterfaces.txt epair0a epair0b` I did have to comment out the waitcarrier() check. I’ve done a little bit of digging, and I think I’m starting to see how this breaks. This always affects the jailed vlan interfaces. They’re getting deleted, but the ifp doesn’t go away just yet because it’s still in use by the multicast code. The multicast code does its cleanup in task queues, Wow, did I miss that back then? Did I review a change and not notice? Sorry if that was the case. Vnet teardown is blocking and forceful. Doing deferred cleanup work isn’t a good idea at all. I think that is the real problem here. I’d rather have us fix this than putting more bandaids into the code. Yeah, agreed. I think hselasky has a better fix: https://reviews.freebsd.org/D24914 I just saw his e-mail in a different thread. Best regards, Kristof ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: somewhat reproducable vimage panic
On 23 Jul 2020, at 8:09, Kristof Provost wrote:
On 23 Jul 2020, at 9:19, Kristof Provost wrote:
On 23 Jul 2020, at 0:15, John-Mark Gurney wrote:
So, it's pretty easy to trigger, just attach a couple USB ethernet
adapters, in my case, they were ure, but likely any two spare
ethernet
interfaces will work, and wire them back to back..
I’ve been able to trigger it using epair as well:
`sudo sh testinterfaces.txt epair0a epair0b`
I did have to comment out the waitcarrier() check.
I’ve done a little bit of digging, and I think I’m starting to see
how this breaks.
This always affects the jailed vlan interfaces. They’re getting
deleted, but the ifp doesn’t go away just yet because it’s still
in use by the multicast code.
The multicast code does its cleanup in task queues,
Wow, did I miss that back then? Did I review a change and not notice?
Sorry if that was the case.
Vnet teardown is blocking and forceful.
Doing deferred cleanup work isn’t a good idea at all.
I think that is the real problem here.
I’d rather have us fix this than putting more bandaids into the code.
/bz
PS: I love that you can repro this with epairs, means we can write a
generic test code piece for this and commit it.
so by the time it gets around to doing that the ifp is already marked
as dying and the vnet is gone.
There are still references to the ifp though, and when the multicast
code tries to do its cleanup we get the panic.
This hack stops the panic for me, but I don’t know if this is the
best solution:
diff --git a/sys/net/if.c b/sys/net/if.c
index 59dd38267cf..bd0c87eddf1 100644
--- a/sys/net/if.c
+++ b/sys/net/if.c
@@ -3681,6 +3685,10 @@ if_delmulti_ifma_flags(struct ifmultiaddr
*ifma, int flags)
ifp = NULL;
}
#endif
+
+ if (ifp && ifp->if_flags & IFF_DYING)
+ return;
+
/*
* If and only if the ifnet instance exists: Acquire the address
lock.
*/
diff --git a/sys/netinet/in_mcast.c b/sys/netinet/in_mcast.c
index 39fc82c5372..6493e2a5bfb 100644
--- a/sys/netinet/in_mcast.c
+++ b/sys/netinet/in_mcast.c
@@ -623,7 +623,7 @@ inm_release(struct in_multi *inm)
/* XXX this access is not covered by IF_ADDR_LOCK */
CTR2(KTR_IGMPV3, "%s: purging ifma %p", __func__, ifma);
- if (ifp != NULL) {
+ if (ifp != NULL && (ifp->if_flags & IFF_DYING) == 0) {
CURVNET_SET(ifp->if_vnet);
inm_purge(inm);
free(inm, M_IPMADDR);
Best regards,
Kristof
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Abandoning ifnet work
On 2020-07-23 05:45, Kyle Evans wrote: abandoning because the review process for this area is simply not Are you looking for this: https://reviews.freebsd.org/D24914 --HPS ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172
--- Comment #11 from Gert Doering ---
This is driving me totally insane.
The first 4 times I ran the tester, it had IFDISABLED.
The next like 50 times, nothing... not sure what else is need to trigger it -
I ran a few openvpn instances in between ("if it's related to additional
configs, like routing changes") but that doesn't trigger it either.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: somewhat reproducable vimage panic
On 23 Jul 2020, at 9:19, Kristof Provost wrote:
On 23 Jul 2020, at 0:15, John-Mark Gurney wrote:
So, it's pretty easy to trigger, just attach a couple USB ethernet
adapters, in my case, they were ure, but likely any two spare
ethernet
interfaces will work, and wire them back to back..
I’ve been able to trigger it using epair as well:
`sudo sh testinterfaces.txt epair0a epair0b`
I did have to comment out the waitcarrier() check.
I’ve done a little bit of digging, and I think I’m starting to see
how this breaks.
This always affects the jailed vlan interfaces. They’re getting
deleted, but the ifp doesn’t go away just yet because it’s still in
use by the multicast code.
The multicast code does its cleanup in task queues, so by the time it
gets around to doing that the ifp is already marked as dying and the
vnet is gone.
There are still references to the ifp though, and when the multicast
code tries to do its cleanup we get the panic.
This hack stops the panic for me, but I don’t know if this is the best
solution:
diff --git a/sys/net/if.c b/sys/net/if.c
index 59dd38267cf..bd0c87eddf1 100644
--- a/sys/net/if.c
+++ b/sys/net/if.c
@@ -3681,6 +3685,10 @@ if_delmulti_ifma_flags(struct ifmultiaddr *ifma,
int flags)
ifp = NULL;
}
#endif
+
+ if (ifp && ifp->if_flags & IFF_DYING)
+ return;
+
/*
* If and only if the ifnet instance exists: Acquire the address
lock.
*/
diff --git a/sys/netinet/in_mcast.c b/sys/netinet/in_mcast.c
index 39fc82c5372..6493e2a5bfb 100644
--- a/sys/netinet/in_mcast.c
+++ b/sys/netinet/in_mcast.c
@@ -623,7 +623,7 @@ inm_release(struct in_multi *inm)
/* XXX this access is not covered by IF_ADDR_LOCK */
CTR2(KTR_IGMPV3, "%s: purging ifma %p", __func__, ifma);
- if (ifp != NULL) {
+ if (ifp != NULL && (ifp->if_flags & IFF_DYING) == 0) {
CURVNET_SET(ifp->if_vnet);
inm_purge(inm);
free(inm, M_IPMADDR);
Best regards,
Kristof
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172 --- Comment #10 from Gert Doering --- Created attachment 216689 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=216689=edit test program to reproduce behaviour -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172 --- Comment #9 from Gert Doering --- So. I have a nice test program now which can be run in a loop and then looked at later. As I said it's somewhat spurious on my system - sometimes it triggers 10 times in a row, then 20 times not at all. If it triggers, the output looks like this: cc -o tester -Wall tester.c sudo ./tester tun0 /dev/tun0 open ok, fd=3 run cmd: 'ifconfig tun0 inet6 fd00:abcd:204:4::1001/64 mtu 1500 up' read 296 bytes, time since start=0s tun0: flags=8051 metric 0 mtu 1500 options=8 inet6 fe80::250:56ff:fe9c:dffb%tun0 prefixlen 64 tentative scopeid 0x3 inet6 fd00:abcd:204:4::1001 prefixlen 64 tentative groups: tun nd6 options=21 Opened by PID 62433 read 307 bytes, time since start=1s tun0: flags=8051 metric 0 mtu 1500 options=8 inet6 fe80::250:56ff:fe9c:dffb%tun0 prefixlen 64 tentative scopeid 0x3 inet6 fd00:abcd:204:4::1001 prefixlen 64 tentative groups: tun nd6 options=29 Opened by PID 62433 *** FOUND *** (the tester program will loop for 10 seconds, run "ifconfig $dev" in a pipe, and print "FOUND!" if it found IFDISABLED in the output - which could be extended to do something else on-trigger) Attachment coming. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: somewhat reproducable vimage panic
On 23 Jul 2020, at 0:15, John-Mark Gurney wrote: > So, it's pretty easy to trigger, just attach a couple USB ethernet > adapters, in my case, they were ure, but likely any two spare ethernet > interfaces will work, and wire them back to back.. > I’ve been able to trigger it using epair as well: `sudo sh testinterfaces.txt epair0a epair0b` I did have to comment out the waitcarrier() check. Best regards, Kristof ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
