On Sun, 19 Aug 2012, Randall Stewart wrote:
Though I disagree, I conceed to jhb & Rui. Note that we still have a problem with this whole structure of locks and in_input.c [it does not lock which it should not, but this *can* lead to crashes]. (I have seen it in our SQA testbed.. besides the one with a refcnt issue that I will have SQA work on next week ;-)
I agree with John here -- these are seperate issues, and we need to get each part correct in isolation, not just in composition.
Bjoern and I have been plotting a lock reduction exercise in the network stack for some time, based on a model Jeff Roberson and the Nokia guys used -- a global "config" lock, which would use our rmlock primitive. This would make address list synchronisation sufficiently affordable to use in ip_input(). However, it comes with a number of other issues that we need to consider, such as potential latency impacts of reconfiguration events, which have to be characterised before we commit to it, as well as potential issues with lock order. Recent rmlock improvements (e.g., with respect to WITNESS) make doing this work much more plausible. Hopefully this is something we'll get to in September.
Robert _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
