* [PATCH] sparc64 compatibility netfilter patches
@ 2003-01-01 16:16 Laszlo Valko
2003-01-01 20:32 ` Laszlo Valko
2003-01-02 8:57 ` Harald Welte
0 siblings, 2 replies; 9+ messages in thread
From: Laszlo Valko @ 2003-01-01 16:16 UTC (permalink / raw)
To: netfilter-devel; +Cc: David S . Miller
[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]
Hi all!
Here are two patches to make netfilter "more" usable on sparc64
platforms with 32-bit user-space.
The first one is a workaround for the not-so-nice idea of passing
a user-space pointer in a structure for setsockopt. The patch makes
the netfilter counters working.
The second one is a workaround for the even-wilder idea of putting
kernel-only variables (including a pointer) into structures used
for communication between user-space and kernel-space, whose sizeof()
is checked at the beginning of the system call. This patch makes
netfilter module "limit" working.
Please review, comment, etc.
Laszlo
email: <valko@linux.karinthy.hu>
PS: the first patch is the best I can imagine without changing the way
of data exchange (maybe putting the counters struct at the end of struct
ipt_replace, after the entries, with offset pointers like struct ipt_entry
uses with target_offset and next_offset?), even though it results in
HORRIBLE amount of copying for EVERY iptables change command.
The second is an ugly workaround. The correct way would be to rip off
everything non-user-space from struct ipt_rateinfo, especially these:
/* Used internally by the kernel */
unsigned long prev;
/* Ugly, ugly fucker. */
struct ipt_rateinfo *master;
[-- Attachment #2: diff-2.4.20-netfilter-sparc64 --]
[-- Type: text/plain, Size: 2720 bytes --]
--- linux-2.4.20/arch/sparc64/kernel/sys_sparc32.c 2002-12-09 16:50:51.000000000 +0100
+++ linux-2.4.20-my/arch/sparc64/kernel/sys_sparc32.c 2003-01-01 15:54:56.000000000 +0100
@@ -50,6 +50,7 @@
#include <linux/icmpv6.h>
#include <linux/sysctl.h>
#include <linux/dnotify.h>
+#include <linux/netfilter_ipv4/ip_tables.h>
#include <asm/types.h>
#include <asm/ipc.h>
@@ -2777,6 +2778,79 @@
extern asmlinkage int sys_setsockopt(int fd, int level, int optname,
char *optval, int optlen);
+static int do_netfilter_replace(int fd, int level, int optname,
+ char *optval, int optlen)
+{
+ struct ipt_replace32 {
+ char name[IPT_TABLE_MAXNAMELEN];
+ __u32 valid_hooks;
+ __u32 num_entries;
+ __u32 size;
+ __u32 hook_entry[NF_IP_NUMHOOKS];
+ __u32 underflow[NF_IP_NUMHOOKS];
+ __u32 num_counters;
+ __u32 counters;
+ struct ipt_entry entries[0];
+ } *repl32 = (struct ipt_replace32 *)optval;
+ struct ipt_replace *krepl;
+ struct ipt_counters *counters32;
+ __u32 origsize;
+ unsigned int kreplsize, kcountersize;
+ mm_segment_t old_fs;
+ int ret;
+
+ if (optlen < sizeof(repl32))
+ return -EINVAL;
+
+ if (copy_from_user(&origsize,
+ &repl32->size,
+ sizeof(origsize)))
+ return -EFAULT;
+
+ kreplsize = sizeof(*krepl) + origsize;
+ kcountersize = krepl->num_counters * sizeof(struct ipt_counters);
+
+ /* Hack: Causes ipchains to give correct error msg --RR */
+ if (optlen != kreplsize)
+ return -ENOPROTOOPT;
+
+ krepl = (struct ipt_replace *)kmalloc(kreplsize, GFP_KERNEL);
+ if (krepl == NULL)
+ return -ENOMEM;
+
+ if (copy_from_user(krepl, optval, kreplsize)) {
+ kfree(krepl);
+ return -EFAULT;
+ }
+
+ counters32 = (struct ipt_counters *)AA(
+ ((struct ipt_replace32 *)krepl)->counters);
+
+ kcountersize = krepl->num_counters * sizeof(struct ipt_counters);
+ krepl->counters = (struct ipt_counters *)kmalloc(
+ kcountersize, GFP_KERNEL);
+ if (krepl->counters == NULL) {
+ kfree(krepl);
+ return -ENOMEM;
+ }
+
+ old_fs = get_fs();
+ set_fs(KERNEL_DS);
+ ret = sys_setsockopt(fd, level, optname,
+ (char *)krepl, kreplsize);
+ set_fs(old_fs);
+
+ if (copy_to_user(counters32, krepl->counters, kcountersize)) {
+ kfree(krepl);
+ return -EFAULT;
+ }
+
+ kfree(krepl->counters);
+ kfree(krepl);
+
+ return ret;
+}
+
static int do_set_attach_filter(int fd, int level, int optname,
char *optval, int optlen)
{
@@ -2870,6 +2944,9 @@
asmlinkage int sys32_setsockopt(int fd, int level, int optname,
char *optval, int optlen)
{
+ if (optname == IPT_SO_SET_REPLACE)
+ return do_netfilter_replace(fd, level, optname,
+ optval, optlen);
if (optname == SO_ATTACH_FILTER)
return do_set_attach_filter(fd, level, optname,
optval, optlen);
[-- Attachment #3: diff-iptables-1.2.7a-sparc64 --]
[-- Type: text/plain, Size: 3075 bytes --]
diff -Naur iptables-1.2.7a/extensions/Makefile iptables-1.2.7a-my/extensions/Makefile
--- iptables-1.2.7a/extensions/Makefile 2002-08-09 09:44:10.000000000 +0200
+++ iptables-1.2.7a-my/extensions/Makefile 2003-01-01 16:04:29.000000000 +0100
@@ -1,5 +1,17 @@
#! /usr/bin/make
+# Sparc64 hack
+ifeq ($(shell uname -m),sparc64)
+# The kernel is 64-bit, even though userspace is 32.
+CFLAGS+=-DIPT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32
+endif
+
+# HPPA hack
+ifeq ($(shell uname -m),parisc64)
+# The kernel is 64-bit, even though userspace is 32.
+CFLAGS+=-DIPT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32
+endif
+
PF_EXT_SLIB:=ah conntrack dscp ecn esp helper icmp length limit mac mark multiport owner pkttype standard state tcp tcpmss tos ttl udp unclean DNAT DSCP ECN LOG MARK MASQUERADE MIRROR REDIRECT REJECT SAME SNAT TCPMSS TOS ULOG
PF6_EXT_SLIB:=eui64 icmpv6 length limit mac mark multiport owner standard tcp udp LOG MARK
diff -Naur iptables-1.2.7a/extensions/libipt_limit.c iptables-1.2.7a-my/extensions/libipt_limit.c
--- iptables-1.2.7a/extensions/libipt_limit.c 2002-05-29 15:08:16.000000000 +0200
+++ iptables-1.2.7a-my/extensions/libipt_limit.c 2003-01-01 16:03:56.000000000 +0100
@@ -13,6 +13,20 @@
#include <linux/netfilter_ipv4/ip_tables.h>
#include <linux/netfilter_ipv4/ipt_limit.h>
+#if defined(KERNEL_64_USERSPACE_32)
+struct ipt_rateinfo_compat {
+ u_int32_t avg; /* Average secs between packets * scale */
+ u_int32_t burst; /* Period multiplier for upper limit. */
+
+ u_int64_t prev;
+ u_int32_t credit;
+ u_int32_t credit_cap, cost;
+ u_int64_t master;
+};
+
+#define ipt_rateinfo ipt_rateinfo_compat
+#endif
+
#define IPT_LIMIT_AVG "3/hour"
#define IPT_LIMIT_BURST 5
diff -Naur iptables-1.2.7a/libiptc/Makefile iptables-1.2.7a-my/libiptc/Makefile
--- iptables-1.2.7a/libiptc/Makefile 2001-03-16 14:40:52.000000000 +0100
+++ iptables-1.2.7a-my/libiptc/Makefile 2003-01-01 16:03:56.000000000 +0100
@@ -1,5 +1,17 @@
#! /usr/bin/make
+# Sparc64 hack
+ifeq ($(shell uname -m),sparc64)
+# The kernel is 64-bit, even though userspace is 32.
+CFLAGS+=-DIPT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32
+endif
+
+# HPPA hack
+ifeq ($(shell uname -m),parisc64)
+# The kernel is 64-bit, even though userspace is 32.
+CFLAGS+=-DIPT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32
+endif
+
EXTRAS+=libiptc/libiptc.a
DEVEL_LIBS+=libiptc/libiptc.a
diff -Naur iptables-1.2.7a/libiptc/libiptc.c iptables-1.2.7a-my/libiptc/libiptc.c
--- iptables-1.2.7a/libiptc/libiptc.c 2002-05-29 15:08:16.000000000 +0200
+++ iptables-1.2.7a-my/libiptc/libiptc.c 2003-01-01 16:03:56.000000000 +0100
@@ -1690,13 +1690,11 @@
/* Kernel will think that pointer should be 64-bits, and get
padding. So we accomodate here (assumption: alignment of
`counters' is on 64-bit boundary). */
- u_int64_t *kernptr = (u_int64_t *)&newcounters->counters;
if ((unsigned long)&newcounters->counters % 8 != 0) {
fprintf(stderr,
"counters alignment incorrect! Mail rusty!\n");
abort();
}
- *kernptr = newcounters->counters;
}
#endif /* KERNEL_64_USERSPACE_32 */
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] sparc64 compatibility netfilter patches
2003-01-01 16:16 [PATCH] sparc64 compatibility netfilter patches Laszlo Valko
@ 2003-01-01 20:32 ` Laszlo Valko
2003-01-02 6:22 ` David S. Miller
2003-01-07 8:47 ` David S. Miller
2003-01-02 8:57 ` Harald Welte
1 sibling, 2 replies; 9+ messages in thread
From: Laszlo Valko @ 2003-01-01 20:32 UTC (permalink / raw)
To: netfilter-devel; +Cc: David S . Miller
[-- Attachment #1: Type: text/plain, Size: 107 bytes --]
Improved version follows.
Both patches had something to improve.
Laszlo
e-mail: <valko@linux.karinthy.hu>
[-- Attachment #2: diff-2.4.20-netfilter-sparc64-2 --]
[-- Type: text/plain, Size: 2712 bytes --]
--- linux-2.4.20/arch/sparc64/kernel/sys_sparc32.c 2002-12-09 16:50:51.000000000 +0100
+++ linux-2.4.20-my/arch/sparc64/kernel/sys_sparc32.c 2003-01-01 20:33:05.000000000 +0100
@@ -50,6 +50,7 @@
#include <linux/icmpv6.h>
#include <linux/sysctl.h>
#include <linux/dnotify.h>
+#include <linux/netfilter_ipv4/ip_tables.h>
#include <asm/types.h>
#include <asm/ipc.h>
@@ -2777,6 +2778,78 @@
extern asmlinkage int sys_setsockopt(int fd, int level, int optname,
char *optval, int optlen);
+static int do_netfilter_replace(int fd, int level, int optname,
+ char *optval, int optlen)
+{
+ struct ipt_replace32 {
+ char name[IPT_TABLE_MAXNAMELEN];
+ __u32 valid_hooks;
+ __u32 num_entries;
+ __u32 size;
+ __u32 hook_entry[NF_IP_NUMHOOKS];
+ __u32 underflow[NF_IP_NUMHOOKS];
+ __u32 num_counters;
+ __u32 counters;
+ struct ipt_entry entries[0];
+ } *repl32 = (struct ipt_replace32 *)optval;
+ struct ipt_replace *krepl;
+ struct ipt_counters *counters32;
+ __u32 origsize;
+ unsigned int kreplsize, kcountersize;
+ mm_segment_t old_fs;
+ int ret;
+
+ if (optlen < sizeof(repl32))
+ return -EINVAL;
+
+ if (copy_from_user(&origsize,
+ &repl32->size,
+ sizeof(origsize)))
+ return -EFAULT;
+
+ kreplsize = sizeof(*krepl) + origsize;
+ kcountersize = krepl->num_counters * sizeof(struct ipt_counters);
+
+ /* Hack: Causes ipchains to give correct error msg --RR */
+ if (optlen != kreplsize)
+ return -ENOPROTOOPT;
+
+ krepl = (struct ipt_replace *)kmalloc(kreplsize, GFP_KERNEL);
+ if (krepl == NULL)
+ return -ENOMEM;
+
+ if (copy_from_user(krepl, optval, kreplsize)) {
+ kfree(krepl);
+ return -EFAULT;
+ }
+
+ counters32 = (struct ipt_counters *)AA(
+ ((struct ipt_replace32 *)krepl)->counters);
+
+ kcountersize = krepl->num_counters * sizeof(struct ipt_counters);
+ krepl->counters = (struct ipt_counters *)kmalloc(
+ kcountersize, GFP_KERNEL);
+ if (krepl->counters == NULL) {
+ kfree(krepl);
+ return -ENOMEM;
+ }
+
+ old_fs = get_fs();
+ set_fs(KERNEL_DS);
+ ret = sys_setsockopt(fd, level, optname,
+ (char *)krepl, kreplsize);
+ set_fs(old_fs);
+
+ if (ret == 0 &&
+ copy_to_user(counters32, krepl->counters, kcountersize))
+ ret = -EFAULT;
+
+ kfree(krepl->counters);
+ kfree(krepl);
+
+ return ret;
+}
+
static int do_set_attach_filter(int fd, int level, int optname,
char *optval, int optlen)
{
@@ -2870,6 +2943,9 @@
asmlinkage int sys32_setsockopt(int fd, int level, int optname,
char *optval, int optlen)
{
+ if (optname == IPT_SO_SET_REPLACE)
+ return do_netfilter_replace(fd, level, optname,
+ optval, optlen);
if (optname == SO_ATTACH_FILTER)
return do_set_attach_filter(fd, level, optname,
optval, optlen);
[-- Attachment #3: diff-iptables-1.2.7a-sparc64-2 --]
[-- Type: text/plain, Size: 2846 bytes --]
diff -Naur iptables-1.2.7a/Makefile iptables-1.2.7a-my/Makefile
--- iptables-1.2.7a/Makefile 2002-08-26 15:04:39.000000000 +0200
+++ iptables-1.2.7a-my/Makefile 2003-01-01 21:16:41.000000000 +0100
@@ -35,6 +35,18 @@
CFLAGS += -DNO_SHARED_LIBS=1
endif
+# Sparc64 hack
+ifeq ($(shell uname -m),sparc64)
+# The kernel is 64-bit, even though userspace is 32.
+CFLAGS+=-DIPT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32
+endif
+
+# HPPA hack
+ifeq ($(shell uname -m),parisc64)
+# The kernel is 64-bit, even though userspace is 32.
+CFLAGS+=-DIPT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32
+endif
+
ifndef NO_SHARED_LIBS
DEPFILES = $(SHARED_LIBS:%.so=%.d)
SH_CFLAGS:=$(CFLAGS) -fPIC
@@ -64,18 +76,6 @@
EXTRA_INSTALLS_EXP+=$(DESTDIR)$(BINDIR)/ip6tables-save $(DESTDIR)$(BINDIR)/ip6tables-restore # $(DESTDIR)$(MANDIR)/man8/iptables-restore.8 $(DESTDIR)$(MANDIR)/man8/iptables-save.8 $(DESTDIR)$(MANDIR)/man8/ip6tables-save.8 $(DESTDIR)$(MANDIR)/man8/ip6tables-restore.8
endif
-# Sparc64 hack
-ifeq ($(shell uname -m),sparc64)
-# The kernel is 64-bit, even though userspace is 32.
-CFLAGS+=-DIPT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32
-endif
-
-# HPPA hack
-ifeq ($(shell uname -m),parisc64)
-# The kernel is 64-bit, even though userspace is 32.
-CFLAGS+=-DIPT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32
-endif
-
ifndef IPT_LIBDIR
IPT_LIBDIR:=$(LIBDIR)/iptables
endif
diff -Naur iptables-1.2.7a/extensions/libipt_limit.c iptables-1.2.7a-my/extensions/libipt_limit.c
--- iptables-1.2.7a/extensions/libipt_limit.c 2002-05-29 15:08:16.000000000 +0200
+++ iptables-1.2.7a-my/extensions/libipt_limit.c 2003-01-01 21:16:25.000000000 +0100
@@ -13,6 +13,20 @@
#include <linux/netfilter_ipv4/ip_tables.h>
#include <linux/netfilter_ipv4/ipt_limit.h>
+#if defined(KERNEL_64_USERSPACE_32)
+struct ipt_rateinfo_compat {
+ u_int32_t avg; /* Average secs between packets * scale */
+ u_int32_t burst; /* Period multiplier for upper limit. */
+
+ u_int64_t prev;
+ u_int32_t credit;
+ u_int32_t credit_cap, cost;
+ u_int64_t master;
+};
+
+#define ipt_rateinfo ipt_rateinfo_compat
+#endif
+
#define IPT_LIMIT_AVG "3/hour"
#define IPT_LIMIT_BURST 5
diff -Naur iptables-1.2.7a/libiptc/libiptc.c iptables-1.2.7a-my/libiptc/libiptc.c
--- iptables-1.2.7a/libiptc/libiptc.c 2002-05-29 15:08:16.000000000 +0200
+++ iptables-1.2.7a-my/libiptc/libiptc.c 2003-01-01 21:16:25.000000000 +0100
@@ -1690,13 +1690,11 @@
/* Kernel will think that pointer should be 64-bits, and get
padding. So we accomodate here (assumption: alignment of
`counters' is on 64-bit boundary). */
- u_int64_t *kernptr = (u_int64_t *)&newcounters->counters;
if ((unsigned long)&newcounters->counters % 8 != 0) {
fprintf(stderr,
"counters alignment incorrect! Mail rusty!\n");
abort();
}
- *kernptr = newcounters->counters;
}
#endif /* KERNEL_64_USERSPACE_32 */
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] sparc64 compatibility netfilter patches
2003-01-01 20:32 ` Laszlo Valko
@ 2003-01-02 6:22 ` David S. Miller
2003-01-02 9:20 ` Laszlo Valko
2003-01-07 8:47 ` David S. Miller
1 sibling, 1 reply; 9+ messages in thread
From: David S. Miller @ 2003-01-02 6:22 UTC (permalink / raw)
To: valko; +Cc: netfilter-devel
The hack for building the tools is wrong, there are 64-bit
compilers and userspace available.
The real fix for that (for when your tools are 32-bit) is
to run "sparc32 /bin/sh" and compile in that environment.
I'll be looking at the kernel side patch next, it should be
ok.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] sparc64 compatibility netfilter patches
2003-01-02 6:22 ` David S. Miller
@ 2003-01-02 9:20 ` Laszlo Valko
0 siblings, 0 replies; 9+ messages in thread
From: Laszlo Valko @ 2003-01-02 9:20 UTC (permalink / raw)
To: David S. Miller; +Cc: netfilter-devel
On Wed, Jan 01, 2003 at 10:22:23PM -0800, David S. Miller wrote:
>
> The hack for building the tools is wrong, there are 64-bit
> compilers and userspace available.
I totally agree that this hack is the wrong way to do it.
It will definitely not work with 64-bit userspace.
> The real fix for that (for when your tools are 32-bit) is
> to run "sparc32 /bin/sh" and compile in that environment.
I don't see how that would solve our problem. It will probably
produce working code with 64-bit userspace, but not in the mixed
bit-length case.
Actually, the hack with KERNEL_64_USERSPACE_32 in the tools had
existed before I even looked at the code. It was too tempting to
extend it to my case even tough I know it's not good :)
There are basically two "good" and a "worse" solution:
1) make the kernel interface saner by excluding longs and pointers
altogether, and cleaning it up by separating "interface" and
"kernel internal" variables/structures (complicated, introducing
incompatible API changes),
2) do kernel side 32-64 bit conversions (ugly, big performance
penalty, looks like a big hack, difficult to maintain),
3) make a similar hack, like there currently is, but with correct
userspace-kernelspace bit-length checking, and do the magic in
the tools (even uglier, but no performance penalty and easier to
maintain).
None of them are simple.
In the long run, I vote for the first one.
If I have a spare week, I might as well try to "sink" into the
netfilter code, and implement something...
> I'll be looking at the kernel side patch next, it should be
> ok.
Thanks.
Laszlo
e-mail: <valko@linux.karinthy.hu>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] sparc64 compatibility netfilter patches
2003-01-01 20:32 ` Laszlo Valko
2003-01-02 6:22 ` David S. Miller
@ 2003-01-07 8:47 ` David S. Miller
1 sibling, 0 replies; 9+ messages in thread
From: David S. Miller @ 2003-01-07 8:47 UTC (permalink / raw)
To: valko; +Cc: netfilter-devel
From: Laszlo Valko <valko@linux.karinthy.hu>
Date: Wed, 1 Jan 2003 21:32:05 +0100
Improved version follows.
Both patches had something to improve.
As mentionted, the first patch is OK and I have applied it to
my tree.
You will need to translate the ipt_rateinfo structure somehow as
it is passed in/out of the kernel, not by putting strange (and
decidedly buggy) hacks into the netfilter tools (consider compiling
with a true 64-bit userland on sparc64, your changes break that).
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] sparc64 compatibility netfilter patches
2003-01-01 16:16 [PATCH] sparc64 compatibility netfilter patches Laszlo Valko
2003-01-01 20:32 ` Laszlo Valko
@ 2003-01-02 8:57 ` Harald Welte
2003-01-02 9:09 ` David S. Miller
1 sibling, 1 reply; 9+ messages in thread
From: Harald Welte @ 2003-01-02 8:57 UTC (permalink / raw)
To: Laszlo Valko; +Cc: netfilter-devel, David S . Miller
[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]
On Wed, Jan 01, 2003 at 05:16:54PM +0100, Laszlo Valko wrote:
> Hi all!
>
> Here are two patches to make netfilter "more" usable on sparc64
> platforms with 32-bit user-space.
Thanks a lot for this valuable contribution!
> The first one is a workaround for the not-so-nice idea of passing
> a user-space pointer in a structure for setsockopt. The patch makes
> the netfilter counters working.
Unfortunately we will never get netfilter-specific code into the
sys_sparc32.c file (and we also really don't want it to be there).
Is there no solution which only touches iptables userspace and kernel
code? (net/ipv4/netfilter/* as well as libiptc.c in userspace)?
> Please review, comment, etc.
>
> Laszlo
> email: <valko@linux.karinthy.hu>
>
>
> PS: the first patch is the best I can imagine without changing the way
> of data exchange (maybe putting the counters struct at the end of struct
> ipt_replace, after the entries, with offset pointers like struct ipt_entry
> uses with target_offset and next_offset?), even though it results in
> HORRIBLE amount of copying for EVERY iptables change command.
I understand... but still... putting netfilter code into the sparc64
architecture dependent syscall code sounds like a bigger hack to me.
btw: I think we can spare DaveM from further discussions on this topic,
I will inform him as soon as we have found a final solution to the
issue.
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] sparc64 compatibility netfilter patches
2003-01-02 8:57 ` Harald Welte
@ 2003-01-02 9:09 ` David S. Miller
2003-01-02 9:31 ` Laszlo Valko
0 siblings, 1 reply; 9+ messages in thread
From: David S. Miller @ 2003-01-02 9:09 UTC (permalink / raw)
To: laforge; +Cc: valko, netfilter-devel
From: Harald Welte <laforge@gnumonks.org>
Date: Thu, 2 Jan 2003 09:57:34 +0100
Unfortunately we will never get netfilter-specific code into the
sys_sparc32.c file (and we also really don't want it to be there).
Is there no solution which only touches iptables userspace and kernel
code? (net/ipv4/netfilter/* as well as libiptc.c in userspace)?
It is the only way to translate socket options that include user
pointers or other types that are not identical in the 32-bit
and 64-bit environment.
It is always a bad idea to pass pointers and other non-hardcoded
types (ie. something other than u8, u16 etc.) via APIs.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] sparc64 compatibility netfilter patches
2003-01-02 9:09 ` David S. Miller
@ 2003-01-02 9:31 ` Laszlo Valko
2003-01-02 9:41 ` David S. Miller
0 siblings, 1 reply; 9+ messages in thread
From: Laszlo Valko @ 2003-01-02 9:31 UTC (permalink / raw)
To: David S. Miller; +Cc: laforge, netfilter-devel
On Thu, Jan 02, 2003 at 01:09:53AM -0800, David S. Miller wrote:
> From: Harald Welte <laforge@gnumonks.org>
> Date: Thu, 2 Jan 2003 09:57:34 +0100
>
> Unfortunately we will never get netfilter-specific code into the
> sys_sparc32.c file (and we also really don't want it to be there).
>
> Is there no solution which only touches iptables userspace and kernel
> code? (net/ipv4/netfilter/* as well as libiptc.c in userspace)?
>
> It is the only way to translate socket options that include user
> pointers or other types that are not identical in the 32-bit
> and 64-bit environment.
>
> It is always a bad idea to pass pointers and other non-hardcoded
> types (ie. something other than u8, u16 etc.) via APIs.
Either we change the way of data exchange, or we have to use similar
thunking functions. We could cosmetically beautify it by moving the
actual implementation from sys_sparc32.c into some other source file
(maybe net/ipv4/netfilter/nf_sparc32.c?) and call it from sys_sparc32.c,
this however provides only a maintenance ease. I see that this is
an important aspect, too.
Laszlo
e-mail: <valko@linux.karinthy.hu>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] sparc64 compatibility netfilter patches
2003-01-02 9:31 ` Laszlo Valko
@ 2003-01-02 9:41 ` David S. Miller
0 siblings, 0 replies; 9+ messages in thread
From: David S. Miller @ 2003-01-02 9:41 UTC (permalink / raw)
To: valko; +Cc: laforge, netfilter-devel
From: Laszlo Valko <valko@linux.karinthy.hu>
Date: Thu, 2 Jan 2003 10:31:26 +0100
We could cosmetically beautify it by moving the
actual implementation from sys_sparc32.c into some other source file
(maybe net/ipv4/netfilter/nf_sparc32.c?) and call it from sys_sparc32.c,
this however provides only a maintenance ease. I see that this is
an important aspect, too.
It isn't even a sparc specific issue, ppc64 mips64 et al. all have
to have a 32-bit translation layer for systemcalls, ioctls, etc.
They basically just copy the sparc64 code in 2.4.x
In 2.5.x we're trying to move this all over into a set of compat.c
files spread over the tree.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-01-07 8:47 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-01 16:16 [PATCH] sparc64 compatibility netfilter patches Laszlo Valko
2003-01-01 20:32 ` Laszlo Valko
2003-01-02 6:22 ` David S. Miller
2003-01-02 9:20 ` Laszlo Valko
2003-01-07 8:47 ` David S. Miller
2003-01-02 8:57 ` Harald Welte
2003-01-02 9:09 ` David S. Miller
2003-01-02 9:31 ` Laszlo Valko
2003-01-02 9:41 ` David S. Miller
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.