Commit Graph

5 Commits

Author SHA1 Message Date
luigi
9f16f6c36d in ip_dn_ctl(), do not allocate a large structure on the stack,
and use malloc() instead if/when it is necessary.

The problem is less relevant in previous versions because
the variable involved (tmp_pipe) is much smaller there.
Still worth fixing though.

Submitted by:	Marta Carbone (GSOC)
MFC after:	3 days
2009-06-10 10:47:31 +00:00
luigi
b465834b3e small simplifications to the code in charge of reaping deleted rules:
- clear the head pointer immediately before using it, so there is
  no chance of mistakes;
- call reap_rules() unconditionally. The function can handle a NULL
  argument just fine, and the cost of the extra call is hardly
  significant given that we do it rarely and outside the lock.

MFC after:	3 days
2009-06-10 10:34:59 +00:00
oleg
1980405dfd Close long existed race with net.inet.ip.fw.one_pass = 0:
If packet leaves ipfw to other kernel subsystem (dummynet, netgraph, etc)
it carries pointer to matching ipfw rule. If this packet then reinjected back
to ipfw, ruleset processing starts from that rule. If rule was deleted
meanwhile, due to existed race condition panic was possible (as well as
other odd effects like parsing rules in 'reap list').

P.S. this commit changes ABI so userland ipfw related binaries should be
recompiled.

MFC after:	1 month
Tested by:	Mikolaj Golub
2009-06-09 21:27:11 +00:00
bz
b7ff2bdc20 After r193232 rt_tables in vnet.h are no longer indirectly dependent on
the ROUTETABLES kernel option thus there is no need to include opt_route.h
anymore in all consumers of vnet.h and no longer depend on it for module
builds.

Remove the hidden include in flowtable.h as well and leave the two
explicit #includes in ip_input.c and ip_output.c.
2009-06-08 19:57:35 +00:00
luigi
82f1e32a7f move kernel ipfw-related sources to a separate directory,
adjust conf/files and modules' Makefiles accordingly.

No code or ABI changes so this and most of previous related
changes can be easily MFC'ed

MFC after:	5 days
2009-06-05 19:22:47 +00:00