Date: Thu, 6 Jun 2013 16:28:55 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Mikolaj Golub <trociny@FreeBSD.org> Cc: freebsd-jail@freebsd.org, "Bjoern A. Zeeb" <bz@FreeBSD.org>, freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf + vimage patch Message-ID: <20130606122855.GC14667@glebius.int.ru> In-Reply-To: <20130606122409.GA10459@gmail.com> References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> <51B065F5.4080209@gmx.com> <20130606122409.GA10459@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 06, 2013 at 03:24:10PM +0300, Mikolaj Golub wrote: M> > >> -VNET_DEFINE(u_long, pf_srchashsize); M> > >> -#define V_pf_srchashsize VNET(pf_srchashsize) M> > >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, M> > >> - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); M> > >> +u_long pf_srchashsize; M> > >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, M> > >> + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); M> > >> M> > > M> > > Why do you have to devirtualize these variables? Are per vnet M> > > hashtables sizes not useful or do they cause issues? M> > M> > Per VNET variables are not useful for pf_hashsize and pf_srchashsize M> > since these values are RO and cannot be modified at runtime. M> M> Indeed. I missed RDTUN flag. M> M> > module unload is broken:( Maybe it can be fixed at a (bit) later date? M> M> I don't think Gleb will be happy with this. Some time ago he removed M> some vimage related stuff to prevent crashing on module unload (see M> r229849). Actually your patch looks like a partial revert of that M> commit. So I think you need to think about this issue from start. At M> least it should not crash non-vimage kernel and there should be M> understanding how to fix it for vimage kernel. Your approach with M> keeping only one purge thread might make it simpler. True. It is very much appreciated that you are working on vimage + pf, but breaking module unload isn't an option. When hacking on a part of kernel, having a possibility to avoid a reboot after each compile is very important. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130606122855.GC14667>