Date: Mon, 10 Jun 2013 18:52:01 +0200 From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: freebsd-net <freebsd-net@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) Message-ID: <CAPBZQG32LBXx2LTwPzwdY-fBZH9C8mZvj8b%2BWK183xTixa2XOQ@mail.gmail.com> In-Reply-To: <CA%2BhQ2%2BgnY64x_2uk0FUD%2BLL7Wm9i%2BUtQU-pxhW5KsEkb44mfeQ@mail.gmail.com> References: <CAPBZQG32iyzkec4PG%2Bqay9bKfd0GiffKyRBapLkATKvHr7cVww@mail.gmail.com> <20120131110204.GA95472@onelab2.iet.unipi.it> <20120208133559.GK13554@FreeBSD.org> <CAPBZQG0edS3sru=D_iGMsNDC5EA8H=A=wwRUDOGZi9DtU5-CkQ@mail.gmail.com> <20120208140921.GM13554@glebius.int.ru> <4F344CE4.301@freebsd.org> <CAPBZQG3X4da93rvORyF169yWUokS5V_HhazN-wMeiJEDvDB-4Q@mail.gmail.com> <CA%2BhQ2%2BgnY64x_2uk0FUD%2BLL7Wm9i%2BUtQU-pxhW5KsEkb44mfeQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 10, 2013 at 5:01 PM, Luigi Rizzo <rizzo@iet.unipi.it> wrote: > > > > On Mon, Jun 10, 2013 at 3:30 PM, Ermal Lu=E7i <eri@freebsd.org> wrote: > >> Hello, >> >> reviving this old thread since i had time to bring the patch to FreeBSD = 10 >> and unified the whole controlling under ipfw(8) binary. >> >> For reminder, the patch located at [1] provides multiple instances for >> ipfw(4). >> Basically you can control which interfaces belong to which context/rules= et >> to make maintaining easier. >> >> > ... > > > >> Any objections on pushing this into FreeBSD? >> >> >> [1] >> >> https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0= /CP_multi_instance_ipfw.diff >> >> >> > > if i understand well, this has no runtime overhead as the ifp has > the index of the context it refers to ? > Or you need an additional IPFW_CTX_RLOCK() ? > Theoretically you would need for correctness the read lock. It has never been hit in pfSense hence no further investigation on it has been done. It can be made even a read mostly lock or to prevent the race the write lock of the pfil hooks so no packets are passed through?! > > Comments on the control/config path: > - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might > overflow the temporary buffer when building the list. You compute > the length under rlock, release the lock, malloc(), then fill the > list without checking if the total size is still correct. > This kind of code is terribly boring to write, but essentially > you need a bound check in the second loop and possibly > retry if you notice that you need more memory. > "ipfw show" addresses the problem by failing and requesting the > user application to pass a larger buffer. > Yeah that probably can be fixed. During implementation it was considered enough rare operation to not justify further thought. > > - similarly, how do you guarantee that deleting a context while > a packet is under processing does not cause dereferencing a > NULL pointer ? > Presently, none, but as i said during instance/context operation a write lock on the pfil hook can be taken? That should prevent the issue altogether and remove the requirement of having to read lock the fast path. If you agree with the above i can redo the patch again with the above changes for review? > cheers > luigi > > while >> -- >> Ermal >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > --=20 Ermal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPBZQG32LBXx2LTwPzwdY-fBZH9C8mZvj8b%2BWK183xTixa2XOQ>