From: Andi Kleen <ak@suse.de>
To: Mishin Dmitry <dim@openvz.org>
Cc: linux-kernel@vger.kernel.org,
netfilter-devel@lists.netfilter.org, rusty@rustcorp.com.au,
akpm@osdl.org, devel@openvz.org
Subject: Re: [PATCH 1/2] iptables 32bit compat layer
Date: 20 Feb 2006 22:23:25 +0100 [thread overview]
Message-ID: <p73slqd4tde.fsf@verdi.suse.de> (raw)
In-Reply-To: <200602201110.39092.dim@openvz.org>
Mishin Dmitry <dim@openvz.org> writes:
> Hello,
>
> This patch set extends current iptables compatibility layer in order to get
> 32bit iptables to work on 64bit kernel. Current layer is insufficient
> due to alignment checks both in kernel and user space tools.
>
> This patch introduces base compatibility interface for other ip_tables modules
Nice. But some issues with the implementation
+#if defined(CONFIG_X86_64)
+#define is_current_32bits() (current_thread_info()->flags & _TIF_IA32)
This should be is_compat_task(). And we don't do such ifdefs
in generic code. And what you actually need here is a
is_compat_task_with_funny_u64_alignment() (better name sought)
So I would suggest you add macros for that to the ia64 and x86-64
asm/compat.hs and perhaps a ARCH_HAS_FUNNY_U64_ALIGNMENT #define in there.
+ ret = 0;
+ switch (convert) {
+ case COMPAT_TO_USER:
+ pt = (struct ipt_entry_target *)target;
etc. that looks ugly. why can't you just define different functions
for that? We don't really need in kernel ioctl
+#ifdef CONFIG_COMPAT
+ down(&compat_ipt_mutex);
+#endif
Why does it need an own lock?
Overall the implementation looks very complicated. Are you sure
it wasn't possible to do this simpler?
-Andi
next prev parent reply other threads:[~2006-02-20 21:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-20 8:10 [PATCH 1/2] iptables 32bit compat layer Mishin Dmitry
2006-02-20 8:14 ` [PATCH 2/2] " Mishin Dmitry
2006-02-20 8:31 ` [PATCH 1/2] " David S. Miller
2006-02-20 15:55 ` Arnd Bergmann
2006-02-21 9:04 ` [Devel] " Dmitry Mishin
2006-02-21 11:56 ` Arnd Bergmann
2006-03-07 14:07 ` {get|set}sockopt " Dmitry Mishin
2006-03-07 15:05 ` Arnd Bergmann
2006-03-09 10:23 ` Dmitry Mishin
2006-03-09 23:29 ` David S. Miller
2006-03-10 11:21 ` [PATCH] {get|set}sockopt compatibility layer Dmitry Mishin
2006-03-10 11:34 ` David S. Miller
2006-03-10 11:34 ` David S. Miller
2006-02-20 21:23 ` Andi Kleen [this message]
2006-02-21 9:24 ` [Devel] Re: [PATCH 1/2] iptables 32bit compat layer Dmitry Mishin
2006-03-23 10:24 ` [PATCH] " Dmitry Mishin
2006-03-29 9:28 ` Patrick McHardy
2006-03-29 11:36 ` Dmitry Mishin
2006-03-29 12:32 ` Patrick McHardy
2006-03-29 12:38 ` Dmitry Mishin
2006-03-29 12:47 ` Patrick McHardy
2006-03-29 19:04 ` Martin Josefsson
2006-03-29 21:53 ` David S. Miller
2006-03-29 23:01 ` Patrick McHardy
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=p73slqd4tde.fsf@verdi.suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=devel@openvz.org \
--cc=dim@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=rusty@rustcorp.com.au \
/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 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.