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

Harald Welte
2004-07-09T08:01:27Z

[-- 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 --]