10.07.2012 03:25, Ryan Stone пишет: > On Mon, Jul 9, 2012 at 4:12 AM, Gleb Smirnoff <gleb...@freebsd.org> wrote: >> This looks very much related to a known race in ARP code. >> >> See this email and related thread: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031865.html >> >> Ryan didn't check in any patches since, and I failed to follow on this >> problem due to ENOTIME. >> >> I've added Ryan to Cc. Ryan, what's the status of the problem at your >> side? Did you come to any solution? > > Unfortunately I was never able to come to a satisfactory solution. As > I recall, in the end I ran headlong into problems with making the > locking sane. The big problem was with arpresolve. At one point it > calls callout_reset to schedule the LLE's la_timer. In my patch this > would have to be done with a write lock help on the afdata lock. > However, this acquisition would have to be done before taking the > LLE_LOCK to prevent a LOR, and in the end you conclude that you have > to take a write lock on the ifnet's afdata lock for every packet that > goes through arpresolve, which was a non-starter. That's the point > that I reached before I got distracted by other things at $WORK. > > As I recall, the in6 case was even worse, as the in6 equivalent of > arptimer is significantly more complicated and likes to do crazy > things like dropping locks.
It seems, Przemyslaw Frasunek uses proxyarp? I have no such problems but I do not use proxyarp. Could you get rid of it, Przemyslaw? Eugene Grosbein _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
