Re: [netfilter-core] strict rejection of init -> core references causes problems

[Harald Welte <laforge@netfilter.org>]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

On Fri, Jul 09, 2004 at 12:02:26AM -0700, David Mosberger wrote:
> Tony,
> 
> To recap, with that patch applied, calls from the core section of a
> module to an init section are rejected because that's in general a
> dangerous thing to do (the called code may be gone by the time the
> call gets executed).

This breaks almost all netfilter modules, indeed.

> I'm not terribly familiar with the netfilter code, but I think the
> problem there comes from the fact that some code is shared between
> init and exit handlers and that shared code ends up in the module
> core.

that's exactly the case.  Since we have fairly long initialization
functions (allocating/initializing dozens of ressources, where each one
can fail), we share the code for partial and full de-initialization
between the failing module_init() routine and the module_exit() routine.

Initially Rusty wrote the modules like this, and I very much agree with
this decision to not replicate the same code in module_init() and
_exit() functions. (which would have to be kept in sync every time some
item is added to the initialization chain).

> it's common practice, I suppose we don't have much choice but to allow
> calls from core to init sections again.  Perhaps someone from the
> netfilter team could comment?

I wuold very much appreciate if this was still possible in the future.

> 	--david

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]