On 8 Oct 2019, at 12:50, Hans Petter Selasky wrote:
On 2019-10-08 14:48, Bjoern A. Zeeb wrote:
On 7 Oct 2019, at 14:15, Hans Petter Selasky wrote:
Author: hselasky
Date: Mon Oct 7 14:15:41 2019
New Revision: 353274
URL: https://svnweb.freebsd.org/changeset/base/353274
Log:
Factor out VNET shutdown check into an own vnet structure field.
Remove the now obsolete vnet_state field. This greatly simplifies
the
detection of VNET shutdown and avoids code duplication.
I think I tried to say that the vnet_state is extremely helpful for
debugging as you know where each of the stacks is during
initialisation/shutdown, especially with loadable modules and that
it should stay and I cannot remember that I removed it in the patch
that I suggested.
I didn’t re-used a field but extended the structure. What you did
means you cannot MFC this easily. Also it means that all previous
vnet consumers got invalidated and the VNET_MAGIC_N should have been
bumped and all modules need a re-compile.
OK I can fix that, but should VNET_MAGIC_N be bumped when adding the
new vnet_shutdown boolean to this structure?
Thanks!
Yes, I guess it should be though it is technically not needed.
But also see my other follow-up email to the bool flag. I think we are
back to the point of “is the vnet in a stable state or not?”
whereas for your further frag6 change your question only is “is the
vnet shutting down or not because resources might be freed already
otherwise?”.
For your https://reviews.freebsd.org/D19622 the boolean shutdown flag as
it was originally in my patch should be fine. The fact that if_vmove()
and related are not happy is my fault. Sorry.
There’s yet another problem by the fact that the interfaces go away
first, as that doesn’t allow us to properly shutdown connections
anymore. However if they do not go first packets will continue to come
in and a clean shutdown without any packet processing will be even
harder. I think (in a quite moment of a day or two, maybe with a
whiteboard) we should re-hash that decision I had to make a few years
ago in the light of epoch(9) now. Probably that will almost be the same
problem as the mbuf carrying the ifp along. (for another day…).
/bz
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
