[PATCH] fix iptables on systems with discontiguous processor ids

[Harald Welte]

On Tue, Oct 11, 2005 at 12:39:20PM -0700, David S. Miller wrote:
> From: Harald Welte <laforge at netfilter.org>
> Date: Tue, 11 Oct 2005 16:23:04 +0200
> 
> > given that discontiguous processor id's seem to be very rare, I think
> > it's fine to waste some memory on those few systems by ussing this
> > "allocate array from 0 to max smp processor id" approach.
> 
> Let's get your patch working first :-)  The original reporter
> said that your patch still OOPSes when he tries to start
> using iptables.  Didn't you see that?

Yes, I did.  Please note my emails are heavily delayed, since I'm almost
every day travelling (either plane or train).

> On thinking about this some more, the duplication of _all_ of this
> information per-cpu is quite questionable, at least the "read mostly"
> parts that just describe the rules.  The counters make tons of sense,
> per cpu, but that's the majority of it.

Yes, it makes no sense. I never questioned that.  I really dislike a lot
of these strange things in ip_tables.  Unfortunately a change of
something fundamental like this will require lots of code auditing
(basically all match/target extensions).  At the moment a match/target
can modify it's cpu-local matchinfo, and maybe it's not suposed to
change global state.  Also, anything that writes to target/matchinfo
would then require additional (write)locking.

It definitely is a design mistake, I think Rusty admitted to that even
someyears ago.  But now we have to live with the legacy, and now we need
a quick fix, not a complete redesign :)

-- 
- Harald Welte <laforge at netfilter.org>                 http://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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/netfilter-devel/attachments/20051012/056b41b0/attachment-0001.pgp