Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Jun 2013 17:01:28 +0200
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org>
Cc:        freebsd-net <freebsd-net@freebsd.org>, freebsd-hackers@freebsd.org
Subject:   Re: [PATCH] multiple instances of ipfw(4)
Message-ID:  <CA%2BhQ2%2BgnY64x_2uk0FUD%2BLL7Wm9i%2BUtQU-pxhW5KsEkb44mfeQ@mail.gmail.com>
In-Reply-To: <CAPBZQG3X4da93rvORyF169yWUokS5V_HhazN-wMeiJEDvDB-4Q@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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 1=
0
> 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/rulese=
t
> 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() ?

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.

- similarly, how do you guarantee that deleting a context while
  a packet is under processing does not cause dereferencing a
  NULL pointer ?

cheers
luigi

while=20
> --
> 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"
>



--=20
-----------------------------------------+-------------------------------
 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)
-----------------------------------------+-------------------------------



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2BgnY64x_2uk0FUD%2BLL7Wm9i%2BUtQU-pxhW5KsEkb44mfeQ>