[Bug 240609] iflib: Panic with INVARIANTS: sleeping in an epoch section (12.1-pre-QA) (vlan + lagg involved)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240609 Gleb Smirnoff changed: What|Removed |Added Assignee|n...@freebsd.org |gleb...@freebsd.org -- 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"
Dropping the type argument from the mtod macro
Hi all, (net@ is BCC'd to keep discussion on arch@.) In the past we've moved away from macros with explicit types as parameters, in favor of casting void* results as needed (e.g., MALLOC()). I'd like to do the same with mtod. The refactoring is easy enough to do safely with a Coccinelle semantic patch. The semantic patch converts instances of "mtod(m, t)" to "(t)mtod(m)". markj@ and rrs@ both point out that the network stack uses the type argument as a visual tool in large functions where the declaration of the lvariable isn't necessarily nearby its use. I think the "(t)mtod(m)" preserves that utility as a visual tool; I may be mistaken. Currently, the semantic patch drops the explicit "(t)" in two limited cases: "t" is "void *", or the "mtod()" invocation is used during initial variable declaration and assignment. The reasoning is that in both cases, the "t" isn't giving you any additional information. Neither of these exceptions is core to the idea, and either could be removed. What do you think? A rough draft of the proposal is sketched out here: https://reviews.freebsd.org/D21669 Best, Conrad P.S., On an earlier version of this revision, markj@ and emaste@ both expressed concern for downstream consumers. There are two aspects of the current differential that should smooth that experience. First, a backwards-compatible two-argument mtod(m, t) is retained using an ugly macro hack. (Existing code compiles without modification.) Second, the coccinelle semantic patch will be checked in to the tree somewhere for use by downstream consumers that want to convert their code. ___ 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: [SOLVED] Re: FRR on FreeBSD 12 - problems with OSPFv3
> > > > On 10/11/19 4:14 PM, BulkMailForRudy wrote: > > > > Thanks for the questions, good for me to think about it some more.? > > Short response: > > > > ?I don't think it is the FRR config, but the routes received that are > > crashing it or ospf6d has some other issue. > > > > > Got it running!? I tested the theory that 'bad routes' were crashing > ospf6d.? This did it.? I have some odd,legacy,test /124 blocks in the > network (will ferret them out), but filtering the routes fixes this. > > router ospf6 > ?auto-cost reference-bandwidth 1 > ?area 0.0.0.0 filter-list prefix IN-OSPF6 in > ?interface cxl1 area 0.0.0.0 > ?interface cxl2 area 0.0.0.0 > ?interface cxl3 area 0.0.0.0 > ! > ipv6 prefix-list IN-OSPF6 seq 3 permit 2607:f598::/32 le 64 > ipv6 prefix-list IN-OSPF6 seq 99 deny ::/0 le 128 > > > Rudy Great, Would you still please open an issue as pointed out in another email at the FRR site, this helps them track and close the underlying problem. No route received from any peer should *crash* a daemon. Including this additional data may help them to identify the problem. Regards, -- Rod Grimes rgri...@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"
Re: FRR on FreeBSD 12 - problems with OSPFv3
> > Thanks for the questions, good for me to think about it some more.? > Short response: > > ?I don't think it is the FRR config, but the routes received that are > crashing it or ospf6d has some other issue. > > > On 10/11/19 2:12 PM, Rodney W. Grimes wrote: > >> I just upgraded from FreeBSD 11 to 12 and upgrade from quagga to FRR at > >> the same time. I've tried frr6 and frr7 and get the same errors. > >> > >> bgpd and ospfd work fine, but ospf6 doesn't work.? Not sure what I'm > >> going wrong. > >> > >> If I commend out all the interfaces EXCEPT lo0, ospf6d does not crash. > > What if you comment out just lo0? Running OSPF on a loopback > > interface makes no since, your not going to be able to establish > > a DR/BDR pair so OSPF can never really come up on that interface, > > and if it did injecting any route from 127/8 into the OSPF lsdb > > would be very bad! > > > > Though I doubt this is the source of the illegal instuction trap > > it is none the less a configuration issue. > > > Personally, I always put a 172.17.x.x IP on my lo0 and then advertise > that into my network.? I don't make it part of the router config, but I > wanted a 'test device' to boot ospf6d and see it crash.? Also, the docs > on FRR have an lo0. Putting an IP on lo0 and injecting it into OSPF via a redistribution is quiet normal, but actually RUNNING ospf on lo0 is not needed, nor even functional as you have no peer to speak to on that interface and ospf can never form an adjacency. I'll ask the FRR folks about why they are showing ospf on lo0, unless I am missing some this makes no since to me at all. > I do advertise my 172.17.x.x IP on the loobpback:? This is how I verify > OSPF is up -- the IPwill ping from other devices on the network when > OSPF is up.? For IPv6, I put a whole /64 on the lo0. So many IPs in v6.? :) Again, valid, but that does not require the ospf link layer protocol to actually be running on lo0, just a redistribute of a static into ospf as an Type 1 or 2 ASE route. > >> *** LOGS *** > >> > >> 2019/10/10 23:19:31 OSPF6: Scheduling cxl1 for sso > >> 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 0 msec > >> 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 5 usec, Reason: L+ > >> > >> 2019/10/10 23:19:31 OSPF6: Scheduling cxl2 for sso > >> 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 50 msec > >> 2019/10/10 23:19:31 OSPF6: Scheduling cxl3 for sso > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [Down]->[Init] (HelloReceived) > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [Init]->[ExStart] (2-WayReceived) > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [ExStart]->[ExChange] (NegotiationDone) > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [ExChange]->[Loading] (ExchangeDone) > >> 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 109 usec, Reason: R+, R-, L+ > >> > >> 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 83 msec > >> 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 116 usec, Reason: R+, N+, L+ > >> > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [Down]->[Init] (HelloReceived) > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [Init]->[ExStart] (2-WayReceived) > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [ExStart]->[ExChange] (NegotiationDone) > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [ExChange]->[Loading] (ExchangeDone) > >> 2019/10/10 23:19:33 OSPF6: SPF: Scheduled in 0 msec > >> 2019/10/10 23:19:33 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 99 usec, Reason: R+, R- > >> > >> 2019/10/10 23:19:36 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [Loading]->[Full] (LoadingDone) > >> 2019/10/10 23:19:36 OSPF6: SPF: Scheduled in 0 msec > >> 2019/10/10 23:19:31 ZEBRA: client 32 says hello and bids fair to > >> announce only ospf6 routes vrf=0 > >> 2019/10/10 23:19:38 ZEBRA: [EC 4043309117] Client 'ospf6' encountered an > >> error and is shutting down. > >> 2019/10/10 23:19:38 ZEBRA: release_daemon_table_chunks: Released 0 table > >> chunks > >> 2019/10/10 23:19:38 ZEBRA: release_daemon_label_chunks: Released 0 label > >> chunks > >> 2019/10/10 23:19:39 ZEBRA: client 32 disconnected. 100 ospf6 routes > >> removed from the rib > >> > >> *** CRASH *** > > Zebra process crashes after the ospf6 process has encountered some error > > and shut down or are you indicatong that the OSPF6D process has crashed? > OSPF6d crashes, zebra just notes the client #32, the ospf6 process, > saying hello and goodbye. Ok, thanks for clarifing that. > >> If I run on the command line and don't background, it bombs after 7 > >> seconds: > >> # ospf6d > >> Illegal instruction > ... > >> What happens if you remove this lo0 section? > > > Still crashes,
[Bug 240608] iflib: Panic with INVARIANTS: Memory modified after free (12.1-pre-QA)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240608 --- Comment #4 from Harald Schmalzbauer --- tested with RC1: Still same panic as soon as if_vmx(4) get's load _and_ jumbo frames are in use (mtu 9000). Unfortunately, solid vmxnet3 support is crucial to my setups. I managed to patch the vmware vmxnet3 guest driver to work with FreeBSD 12, but it also suffers from panics… The vmware vmxnet3 driver provides doubled transfer rates compared to if_vmx(3), but my skills and time don't last to fix any of both myself. In case anyone is interested in the vmxnet3 patch I'll provide on request of course, but won't pollute this bug report with anything completely different. -harry -- 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"
Re: FRR on FreeBSD 12 - problems with OSPFv3
On Fri, 2019-10-11 at 16:14 -0700, BulkMailForRudy wrote: Hello, > Thanks for the questions, good for me to think about it some more. > Short response: > > I don't think it is the FRR config, but the routes received that > are > crashing it or ospf6d has some other issue. FRR 7.1, the last release have a lot of ospf6d issues making it very unreliable. The only way to have reliable ospf6d is to keep quagga unfortunately. I have troubles in routes exchanges with ospf6d but never get daemon crash. On my loopback, I have an IPv4 address with /32 netmask and an IPv6 address with /64 netmask. If your configuration work fine with Quagga, and you add a router-id statement at the root of configuration (FRR have moved router-id statement outside of 'router ospf6' statement), it should work with FRR. If it didn't works, open a bug: https://github.com/FRRouting/frr/issues -- Nicolas DEFFAYET ___ 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 240609] iflib: Panic with INVARIANTS: sleeping in an epoch section (12.1-pre-QA) (vlan + lagg involved)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240609 --- Comment #4 from Harald Schmalzbauer --- (In reply to Hans Petter Selasky from comment #3) Happy to confirm that your patch prevents the machine from panicking during vlan(4) child setup. Haven't done further tests, but to my very limited understanding of the change, any side effects are very unlikely. Thanks, -harry -- 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"
[SOLVED] Re: FRR on FreeBSD 12 - problems with OSPFv3
On 10/11/19 4:14 PM, BulkMailForRudy wrote: Thanks for the questions, good for me to think about it some more. Short response: I don't think it is the FRR config, but the routes received that are crashing it or ospf6d has some other issue. Got it running! I tested the theory that 'bad routes' were crashing ospf6d. This did it. I have some odd,legacy,test /124 blocks in the network (will ferret them out), but filtering the routes fixes this. router ospf6 auto-cost reference-bandwidth 1 area 0.0.0.0 filter-list prefix IN-OSPF6 in interface cxl1 area 0.0.0.0 interface cxl2 area 0.0.0.0 interface cxl3 area 0.0.0.0 ! ipv6 prefix-list IN-OSPF6 seq 3 permit 2607:f598::/32 le 64 ipv6 prefix-list IN-OSPF6 seq 99 deny ::/0 le 128 Rudy ___ 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: DHCPv6 client in base
On 12/10/2019 03:04, Hiroki Sato wrote: I emphasize again here that people who want to use dhcpcd are still able to install net/dhcpcd and override a combination of utilities such as rtsold. Ditto for ISC's IPv6-capable dhclient. My opinion about the import is that if we adopt dhcpcd in the base system, we should replace all of the current dhclient for IPv4 and rtsold together. Of course we should consider it will need Capsicum or privsep for sandboxing and involve a bigger impact for IPv4 users at least. I agree with what you say entirely - and I would imagine similar work would be needed for any DHCP6 client. I have no idea how privsep or Capsicum should work under dhcpcd (I have zero knowledge in these areas) and would welcome any discussion to move this forwards. For privsep, would it be enough to open ports, drop privs, read the message, validate the message and then send it to the root process? Or is there something more expected? Roy ___ 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 210726] tcp connect() can return invalid EADDRINUSE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210726 --- Comment #18 from a...@playground.ru --- This bug is very easy to fix, why not to do it? -- 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 241162] Panic in closefp() triggered by nginx
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241162 --- Comment #3 from Christos Chatzaras --- rlwestl...@gmail.com : I had some crashes in the past with servers running Nginx, but I am not sure if it's the same panic as 2 of them had bad RAM modules so possibly some crashes were related to hardware. The fix described in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239893 is in stable/12 and 12.1. Can you upgrade your system to 12.1-RC1 to see if it fixes the issue? Also, do you have sendfile enabled in Nginx? -- 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"
Re: DHCPv6 client in base
Roy Marples wrote in : ro> On 11/10/2019 20:40, Hiroki Sato wrote: ro> > I do not have a strong objection on dhcpcd (I am using it on some of ro> > my FreeBSD boxes actually) but let me explain the reason why I chose ro> > wide-dhcp as the candidate. That is because it is a small, ro> > functional DHCPv6-only implementation. I am planning to rewrite it ro> > to add the missing bits and adjust it for a tighter integration with ro> > kernel, ifconfig, rtsold, rtadvd, and sandboxing with Capsicum. I ro> > feel dhcpcd (or others) is too big for that purpose. ro> ro> How are you measuring that dhcpcd is too big? .. ro> I don't consider dhcpcd to be big at all, and would love to know your ro> rationale for calling it so. I did not mean the binary size. Again, what I need for the base system import is source code just for core DHCPv6 procotol for further FreeBSD-specific changes. dhcpcd contains source code for the other protocols than DHCPv6 and non-FreeBSD platforms though it is possible to compile a part of them, and applying changes to it would not be FreeBSD-only thing because you are maintaining it in a portable manner actively. Importing involves those kind of aspects. I expressed them as "big" than importing wide-dhcp, which is no longer maintained by the original authors. Yes, FreeBSD can have a DHCPv6-only version of dhcpcd even at the source code level, which will be much smaller. But if doing so and applying FreeBSD-specific changes which cannot be upstreamed to it, we need additional steps to adjust a partial set of the dhcpcd source code and the contents will be diverged from the origial distribution. Although it is still possible, I think it is not good for both FreeBSD and dhcpcd. That is because if one uses dhcpcd, rtsold in the base system should not be used and relying solely on dhcpcd for handling incoming RAs would be much better. And probably IPv4 DHCP should also be handled by dhcpcd for consistency on the system. Thus, the question is: which is worth doing, maintaining a stripped version of dhcpcd or a client part of wide-dhcp, both with FreeBSD-specific changes applied? Adding IPC between rtsold, ifconfig, and DHCPv6 client is planned for better control and user experience, for example. I simply thought a no-longer-actively-maintained one with smaller code base is easier for that purpose, assuming there is no big difference in the core protocol coverage. I do not insist that this is based on inferiority of dhcpcd in terms of quality or absolute size. My apologies if my previous (and/or this) email sounds offending. How easier we can chop and cook it matters. I emphasize again here that people who want to use dhcpcd are still able to install net/dhcpcd and override a combination of utilities such as rtsold. Ditto for ISC's IPv6-capable dhclient. My opinion about the import is that if we adopt dhcpcd in the base system, we should replace all of the current dhclient for IPv4 and rtsold together. Of course we should consider it will need Capsicum or privsep for sandboxing and involve a bigger impact for IPv4 users at least. If there is no option except for dhcpcd I will go ahead with it regarless of my ealier mentioned concerns. So that is why I would like to know if wide-dhcp has a critical issue which cannot be fixed easily or missing feature at this moment. ro> This isn't a question about wide-dhcp specifically, but I feel it's a ro> good question. ro> ro> Do you plan on supporting a multihomed system with hotpluggable ro> interfaces all auto configured? ro> I'm looking at the BUGS section for rtsold and these bugs ro> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138547 For multiple sources of RDNSS information, FreeBSD currently handles them by resolvconf(8) (yes, one of your works has been already imported) in the base system. The default configuration does not behave very well, so for a good user experience, one needs to configure resolvconf.conf to control ordering and overrides. The dhclient processes do not work collaboratively across multiple interfaces because they are just invoked independently, on a per-interface basis. rtsold does not, either. That is one of the reasons why I would like to add IPC between rtsold and DHCPv6 client. If they work, it can be implemented in dhclient in a similar way. ro> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218191 I could not understand what prevented dhclient from working at the first glance of this PR, but the cause may also be the fact that multiple dhcients work independently and override the default router, RDNSS, and/or etc. These scenarios are in my goals because IPv6 multihoming is more likey to happen than IPv4 while I am still not sure it will be a complete solution. If IPC between the per-interface daemons is not sufficient, we should have another "parent" daemon which monitors the per-IF worker processes or
