Re: [PATCH] x_tables: fix alignment on [at least] ppc32

[Harald Welte <laforge@netfilter.org>]

On Thu, Jan 19, 2006 at 04:56:35PM -0800, David S. Miller wrote:
> > [NETFILTER] x_tables: Fix XT_ALIGN() macro on [at least] ppc32
> > [...]
> > The fix is an ugly kludge, but it has been tested to solve the problem. Yet
> > another reason to move away from the current {ip,ip6,arp,eb}tables like
> > data structures.
> > 
> > Signed-off-by: Harald Welte <laforge@netfilter.org>
> 
> Harald, I'm going to modify this to just use u_int64_t as that
> should be totally sufficient.
>
> It is the largest type, and will produce the desired results without
> the silly structure.

Sorry dave, as I just learned, it isn't.   As reported by Jiri Slaby
<xslaby@fi.muni.cz>, Linus' tree now breaks on i386 :(

Interestingly, on i386:

__alignof__(struct _xt_align)	4
__alignof__(u_int64_t)		8
__alignof__(void *)		4

whereas on ppc:

__alignof__(struct _xt_align)	8
__alignof__(u_int64_t)		8
__alignof__(void *)		4

So your assumption that __alignof__(u_int64_t) == __alignof__(struct xt_align)
doesn't hold true for all archs.

I would therefore recommend applying my unmodified patch, and hope that
it then works on all archs simultaneously.

> Some malloc() implementations use "long double" to figure out the
> largest type size and alignment requirements any C type might have
> on the machine.  But there is no reason to use that here.

Our main problem is that we have to stay compatible with old userspace
programs that had a different definition for what has now become
XT_ALIGN().  So independent what might be the best solution from an
alignment point of view, we must match what old userspace thinks.

Yes, this all sucks.  And yes, we will see a new interface this year.
Promised.

Cheers,
	Harald.

-- 
- Harald Welte <laforge@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

Attachment: pgpmOjoDCYySU.pgp
Description: PGP signature