mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Harald Welte <laforge@netfilter.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Benoit Boissinot <bboissin@gmail.com>,
	Jiri Slaby <xslaby@fi.muni.cz>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org,
	"David S.Miller" <davem@davemloft.net>
Subject: Re: Iptables error [Was: 2.6.16-rc1-mm2]
Date: Fri, 20 Jan 2006 20:32:01 +0100	[thread overview]
Message-ID: <20060120193201.GP4603@sunbeam.de.gnumonks.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0601201148220.3672@evo.osdl.org>


[-- Attachment #1.1: Type: text/plain, Size: 960 bytes --]

On Fri, Jan 20, 2006 at 11:49:46AM -0500, Linus Torvalds wrote:
> On Fri, 20 Jan 2006, Benoit Boissinot wrote:
> > 
> > On x86 (32bits), i have the same i think:
> 
> Interestingly, __alignof__(unsigned long long) is 8 these days, even 
> though I think historically on x86 it was 4. Is this perhaps different in 
> gcc-3 and gcc-4?

The problem seems to have been accidentially introduced by DaveM's
"simplification" of my original patch.

I've already asked Dave to revert his change and apply my original
patch (see attachment), which _should_ fix the problem.

Thanks,
-- 
- 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 #1.2: 52-x_tables-alignment.patch.patch --]
[-- Type: text/plain, Size: 2031 bytes --]

[NETFILTER] x_tables: Fix XT_ALIGN() macro on [at least] ppc32

To keep backwards compatibility with old iptables userspace programs,
the new XT_ALIGN macro always has to return the same value as IPT_ALIGN,
IP6T_ALIGN or ARPT_ALIGN in previous kernels.

However, in those kernels the macro was defined in dependency to the
respective layer3 specifi data structures, which we can no longer do with
x_tables.

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>

---
commit 470faeb379560fe877b685ca69be6a7e4f0e91ed
tree 5732ecd9bcab28469805752514e5c57ba26189a1
parent 44718bbfa186d58477163418d37df173aa2dd079
author Harald Welte <laforge@netfilter.org> Fri, 20 Jan 2006 01:44:24 +0100
committer Harald Welte <laforge@netfilter.org> Fri, 20 Jan 2006 01:44:24 +0100

 include/linux/netfilter/x_tables.h |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h
index 472f048..65f9cd8 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -19,7 +19,20 @@ struct xt_get_revision
 /* For standard target */
 #define XT_RETURN (-NF_REPEAT - 1)
 
-#define XT_ALIGN(s) (((s) + (__alignof__(void *)-1)) & ~(__alignof__(void *)-1))
+/* this is a dummy structure to find out the alignment requirement for a struct
+ * containing all the fundamental data types that are used in ipt_entry, ip6t_entry
+ * and arpt_entry.  This sucks, and it is a hack.  It will be my personal pleasure
+ * to remove it -HW */
+struct _xt_align
+{
+	u_int8_t u8;
+	u_int16_t u16;
+	u_int32_t u32;
+	u_int64_t u64;
+};
+
+#define XT_ALIGN(s) (((s) + (__alignof__(struct _xt_align)-1)) 	\
+			& ~(__alignof__(struct _xt_align)-1))
 
 /* Standard return verdict, or do jump. */
 #define XT_STANDARD_TARGET ""

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

  parent reply	other threads:[~2006-01-20 19:32 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-20 11:15 2.6.16-rc1-mm2 Andrew Morton
2006-01-20 11:33 ` 2.6.16-rc1-mm2 Pekka Enberg
2006-01-20 11:40   ` 2.6.16-rc1-mm2 Andrew Morton
2006-01-20 11:56     ` 2.6.16-rc1-mm2 Pekka J Enberg
2006-01-20 15:19     ` 2.6.16-rc1-mm2 Valdis.Kletnieks
2006-01-20 13:58 ` [PATCH] zone_reclaim cpus_empty needs a real variable Andy Whitcroft
2006-01-20 16:28   ` Christoph Lameter
2006-01-20 21:34   ` Andrew Morton
2006-01-20 14:05 ` 2.6.16-rc1-mm2 Dave Jones
2006-01-20 16:23 ` Iptables error [Was: 2.6.16-rc1-mm2] Jiri Slaby
2006-01-20 16:36   ` Harald Welte
2006-01-20 16:41     ` Jiri Slaby
2006-01-20 16:43     ` Benoit Boissinot
2006-01-20 16:49       ` Linus Torvalds
2006-01-20 16:58         ` Benoit Boissinot
2006-01-20 17:38           ` Benoit Boissinot
2006-01-20 16:59         ` Jiri Slaby
2006-01-20 17:02           ` Jiri Slaby
2006-01-20 17:11         ` Carlos Silva
2006-01-20 19:32         ` Harald Welte [this message]
2006-01-20 19:46           ` Iptables error David S. Miller
2006-01-21 11:05             ` Harald Welte
2006-01-20 20:02         ` David S. Miller
2006-01-23  2:03         ` Iptables error [Was: 2.6.16-rc1-mm2] Herbert Xu
2006-01-23  2:23           ` Keith Owens
2006-01-23 20:53         ` Eric W. Biederman
2006-01-20 18:13   ` Valdis.Kletnieks
2006-01-20 19:52     ` Iptables error David S. Miller
2006-01-20 21:26 ` 2.6.16-rc1-mm2: arch/arm26/kernel/fiq.c still doesn't compile Adrian Bunk
2006-01-20 21:57   ` Alexey Dobriyan
2006-01-20 23:22 ` 2.6.16-rc1-mm2 Reuben Farrelly
2006-01-21 15:14   ` 2.6.16-rc1-mm2 Ed Tomlinson
2006-01-21 16:39     ` 2.6.16-rc1-mm2 Ed Tomlinson
2006-01-21 18:45       ` 2.6.16-rc1-mm2 Barry K. Nathan
2006-01-21 21:36         ` 2.6.16-rc1-mm2 Ed Tomlinson
2006-01-21 23:57           ` 2.6.16-rc1-mm2 Barry K. Nathan
2006-01-23 12:39           ` 2.6.16-rc1-mm2 Ed Tomlinson
2006-01-27 14:53             ` 2.6.16-rc1-mm2 Jeff Garzik
     [not found]               ` <200601280846.23279.edt@aei.ca>
2006-02-04 23:43                 ` 2.6.16-rc1-mm2 (mm5 too) panics Ed Tomlinson
2006-02-24  1:57                   ` 2.6.16-rc4-mm1 & " Ed Tomlinson
2006-01-24  3:51   ` 2.6.16-rc1-mm2 Neil Brown
2006-01-23 18:41 ` 2.6.16-rc1-mm2 Serge E. Hallyn
2006-01-23 18:47   ` 2.6.16-rc1-mm2 Christoph Lameter
2006-01-23 19:32     ` 2.6.16-rc1-mm2 Serge E. Hallyn
2006-01-23 19:39       ` 2.6.16-rc1-mm2 Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060120193201.GP4603@sunbeam.de.gnumonks.org \
    --to=laforge@netfilter.org \
    --cc=akpm@osdl.org \
    --cc=bboissin@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=xslaby@fi.muni.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®