On 24/04/14(Thu) 18:17, Alexander Bluhm wrote: > On Thu, Apr 24, 2014 at 01:43:16PM +0200, Henning Brauer wrote: > > * Martin Pieuchot <mpieuc...@nolizard.org> [2014-04-24 13:24]: > > > This ifp pointer is only needed by rt_getifa() to find an address, so > > > make it a local variable. > > > > > > The rtrequest1(9) change might introduce a negligible slowdown since > > > I remove the already known ifp pointer. But this only happens in the > > > case described in the comment just before and I would bet because of > > > carp_setroute(), still nobody to fix this? It's not better than > > > OpenSSL... > > > > > > In the rtsock chunk, the two pointers are equivalent. > > > > > > Ok? > > > > yup. > > > > the carp route fiddling is pretty damn mad, and with the route > > priorities and the ability to mark routes as down there should be a > > much cleaner way to do this these days. > > heck, the entire carp route fiddling needs to be reassesed. things > > changed, i can\t even fully remeber why it is there (i think it was > > about backup nodes still being able to reach a network only present on > > the carp if or the like), and i seem to remember it doesn't quite work > > as expected anyway, but don't take my word for it, memory REALLY fuzzy > > on that front. > > Years ago mpf@ told me, that the purpose of this function is to ssh > from a carp master to a carp slave via the carp address. Or was > it the other way around? > > The carp_setroute() function starts with the encouraging comment > /* XXX this mess needs fixing */. When switching carp states fast, > the routing table gets messed up. In our product we removed all > calls to carp_setroute(sc, RTM_DELETE). There is one carp_setroute(sc, > RTM_ADD) left. I don't know wether it is needed. I would recommend > to try to delete the whole function and fix fallout if any.
I totally support this idea. I even briefly tried that some months ago without seeing any breakage for *my* use case of carp.
