All of lore.kernel.org
 help / color / mirror / Atom feed
* unaligned access in ipt_ULOG
@ 2007-03-30 21:48 Joerg Friedrich
  2007-03-30 22:05   ` David Miller
  0 siblings, 1 reply; 7+ messages in thread
From: Joerg Friedrich @ 2007-03-30 21:48 UTC (permalink / raw)
  To: sparclinux

Hi!

I wanted to use the iptables ULOG target, but I ran into these error
messages. can anyone explain howto read this messge.

Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e36c] ipt_ulog_packet+0x224/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e374] ipt_ulog_packet+0x22c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e384] ipt_ulog_packet+0x23c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e36c] ipt_ulog_packet+0x224/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e374] ipt_ulog_packet+0x22c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e384] ipt_ulog_packet+0x23c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e36c] ipt_ulog_packet+0x224/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e374] ipt_ulog_packet+0x22c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e384] ipt_ulog_packet+0x23c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e36c] ipt_ulog_packet+0x224/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e374] ipt_ulog_packet+0x22c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e384] ipt_ulog_packet+0x23c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e36c] ipt_ulog_packet+0x224/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e374] ipt_ulog_packet+0x22c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e384] ipt_ulog_packet+0x23c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e36c] ipt_ulog_packet+0x224/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e374] ipt_ulog_packet+0x22c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[1029e384] ipt_ulog_packet+0x23c/0x3fc [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286360] ipt_ulog_packet+0x1c8/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286368] ipt_ulog_packet+0x1d0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286378] ipt_ulog_packet+0x1e0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286360] ipt_ulog_packet+0x1c8/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286368] ipt_ulog_packet+0x1d0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286378] ipt_ulog_packet+0x1e0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286360] ipt_ulog_packet+0x1c8/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286368] ipt_ulog_packet+0x1d0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286378] ipt_ulog_packet+0x1e0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286360] ipt_ulog_packet+0x1c8/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286368] ipt_ulog_packet+0x1d0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286378] ipt_ulog_packet+0x1e0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286360] ipt_ulog_packet+0x1c8/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286368] ipt_ulog_packet+0x1d0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286378] ipt_ulog_packet+0x1e0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286360] ipt_ulog_packet+0x1c8/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286368] ipt_ulog_packet+0x1d0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286378] ipt_ulog_packet+0x1e0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286360] ipt_ulog_packet+0x1c8/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286368] ipt_ulog_packet+0x1d0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286378] ipt_ulog_packet+0x1e0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286360] ipt_ulog_packet+0x1c8/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286368] ipt_ulog_packet+0x1d0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286378] ipt_ulog_packet+0x1e0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286360] ipt_ulog_packet+0x1c8/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286368] ipt_ulog_packet+0x1d0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[10286378] ipt_ulog_packet+0x1e0/0x4c0 [ipt_ULOG]
Kernel unaligned access at TPC[102865b4] ipt_ulog_packet+0x41c/0x4c0 [ipt_ULOG]

-- 
Jörg Friedrich

There are only 10 types of people:
Those who understand binary and those who don't.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: unaligned access in ipt_ULOG
  2007-03-30 21:48 unaligned access in ipt_ULOG Joerg Friedrich
@ 2007-03-30 22:05   ` David Miller
  0 siblings, 0 replies; 7+ messages in thread
From: David Miller @ 2007-03-30 22:05 UTC (permalink / raw)
  To: Joerg.Friedrich; +Cc: kaber, netfilter-devel, sparclinux

From: Joerg Friedrich <Joerg.Friedrich@friedrich-kn.de>
Date: Fri, 30 Mar 2007 23:48:57 +0200

> I wanted to use the iptables ULOG target, but I ran into these error
> messages. can anyone explain howto read this messge.
> 
> Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]

It just means that unaligned accesses are occuring in the ipt_ulog
module.  Things usually work fine when this happens, just very slowly,
which is why the warning is printed.

Patrick, this is on sparc64, it appears to be this code:

	pm->timestamp_sec = skb->tstamp.off_sec;
	pm->timestamp_usec = skb->tstamp.off_usec;

and the NLMSG_DATA() (and thus 'pm') is not 8-byte aligned.

I bet this is a 32-bit sparc binary, has the idea of a compat
layer for the ULOG bits ever been discussed?

Thanks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: unaligned access in ipt_ULOG
@ 2007-03-30 22:05   ` David Miller
  0 siblings, 0 replies; 7+ messages in thread
From: David Miller @ 2007-03-30 22:05 UTC (permalink / raw)
  To: Joerg.Friedrich; +Cc: kaber, netfilter-devel, sparclinux

From: Joerg Friedrich <Joerg.Friedrich@friedrich-kn.de>
Date: Fri, 30 Mar 2007 23:48:57 +0200

> I wanted to use the iptables ULOG target, but I ran into these error
> messages. can anyone explain howto read this messge.
> 
> Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]

It just means that unaligned accesses are occuring in the ipt_ulog
module.  Things usually work fine when this happens, just very slowly,
which is why the warning is printed.

Patrick, this is on sparc64, it appears to be this code:

	pm->timestamp_sec = skb->tstamp.off_sec;
	pm->timestamp_usec = skb->tstamp.off_usec;

and the NLMSG_DATA() (and thus 'pm') is not 8-byte aligned.

I bet this is a 32-bit sparc binary, has the idea of a compat
layer for the ULOG bits ever been discussed?

Thanks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: unaligned access in ipt_ULOG
  2007-03-30 22:05   ` David Miller
@ 2007-04-02 11:55     ` Patrick McHardy
  -1 siblings, 0 replies; 7+ messages in thread
From: Patrick McHardy @ 2007-04-02 11:55 UTC (permalink / raw)
  To: David Miller; +Cc: sparclinux, netfilter-devel, Joerg.Friedrich

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

David Miller wrote:
> From: Joerg Friedrich <Joerg.Friedrich@friedrich-kn.de>
> Date: Fri, 30 Mar 2007 23:48:57 +0200
> 
> 
>>I wanted to use the iptables ULOG target, but I ran into these error
>>messages. can anyone explain howto read this messge.
>>
>>Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
> 
> 
> It just means that unaligned accesses are occuring in the ipt_ulog
> module.  Things usually work fine when this happens, just very slowly,
> which is why the warning is printed.
> 
> Patrick, this is on sparc64, it appears to be this code:
> 
> 	pm->timestamp_sec = skb->tstamp.off_sec;
> 	pm->timestamp_usec = skb->tstamp.off_usec;
> 
> and the NLMSG_DATA() (and thus 'pm') is not 8-byte aligned.
> 
> I bet this is a 32-bit sparc binary, has the idea of a compat
> layer for the ULOG bits ever been discussed?


No, I can't imagine how to do this since we don't have any compat
infrastructure for netlink, so we would have to know whether the
receiving process is a 32 bit binary in ipt_ULOG itself. We have
some compat code in userspace to deal with the different structure
layout, so besides the unaligned accesses, it should already work
fine. Since ULOG is obsolete and nfnetlink_log shouldn't have
these issues, I think the best way to fix this is to use
put_unaligned in ipt_ULOG.

How does this look?


[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1460 bytes --]

[NETFILTER]: ipt_ULOG: use put_unaligned

Use put_unaligned to fix warnings about unaligned accesses.

Signed-off-by: Patrick McHardy <kaber@trash.net>

---
commit fea42a5760325392653d556b1087f8274adcfb2e
tree c4c32f0feb2f947fb4d4f747c39935b535aa29cf
parent 2e175a90047a2dbc76fde169c990164895b25dfc
author Patrick McHardy <kaber@trash.net> Mon, 02 Apr 2007 13:54:14 +0200
committer Patrick McHardy <kaber@trash.net> Mon, 02 Apr 2007 13:54:14 +0200

 net/ipv4/netfilter/ipt_ULOG.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/netfilter/ipt_ULOG.c b/net/ipv4/netfilter/ipt_ULOG.c
index a26404d..9acc018 100644
--- a/net/ipv4/netfilter/ipt_ULOG.c
+++ b/net/ipv4/netfilter/ipt_ULOG.c
@@ -61,6 +61,7 @@
 #include <linux/netfilter_ipv4/ipt_ULOG.h>
 #include <net/sock.h>
 #include <linux/bitops.h>
+#include <asm/unaligned.h>
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Harald Welte <laforge@gnumonks.org>");
@@ -236,9 +237,9 @@ static void ipt_ulog_packet(unsigned int hooknum,
 
 	/* copy hook, prefix, timestamp, payload, etc. */
 	pm->data_len = copy_len;
-	pm->timestamp_sec = skb->tstamp.off_sec;
-	pm->timestamp_usec = skb->tstamp.off_usec;
-	pm->mark = skb->mark;
+	put_unaligned(skb->tstamp.off_sec, &pm->timestamp_sec);
+	put_unaligned(skb->tstamp.off_usec, &pm->timestamp_usec);
+	put_unaligned(skb->mark, &pm->mark);
 	pm->hook = hooknum;
 	if (prefix != NULL)
 		strncpy(pm->prefix, prefix, sizeof(pm->prefix));

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: unaligned access in ipt_ULOG
@ 2007-04-02 11:55     ` Patrick McHardy
  0 siblings, 0 replies; 7+ messages in thread
From: Patrick McHardy @ 2007-04-02 11:55 UTC (permalink / raw)
  To: David Miller; +Cc: sparclinux, netfilter-devel, Joerg.Friedrich

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

David Miller wrote:
> From: Joerg Friedrich <Joerg.Friedrich@friedrich-kn.de>
> Date: Fri, 30 Mar 2007 23:48:57 +0200
> 
> 
>>I wanted to use the iptables ULOG target, but I ran into these error
>>messages. can anyone explain howto read this messge.
>>
>>Kernel unaligned access at TPC[1029e35c] ipt_ulog_packet+0x214/0x3fc [ipt_ULOG]
> 
> 
> It just means that unaligned accesses are occuring in the ipt_ulog
> module.  Things usually work fine when this happens, just very slowly,
> which is why the warning is printed.
> 
> Patrick, this is on sparc64, it appears to be this code:
> 
> 	pm->timestamp_sec = skb->tstamp.off_sec;
> 	pm->timestamp_usec = skb->tstamp.off_usec;
> 
> and the NLMSG_DATA() (and thus 'pm') is not 8-byte aligned.
> 
> I bet this is a 32-bit sparc binary, has the idea of a compat
> layer for the ULOG bits ever been discussed?


No, I can't imagine how to do this since we don't have any compat
infrastructure for netlink, so we would have to know whether the
receiving process is a 32 bit binary in ipt_ULOG itself. We have
some compat code in userspace to deal with the different structure
layout, so besides the unaligned accesses, it should already work
fine. Since ULOG is obsolete and nfnetlink_log shouldn't have
these issues, I think the best way to fix this is to use
put_unaligned in ipt_ULOG.

How does this look?


[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1460 bytes --]

[NETFILTER]: ipt_ULOG: use put_unaligned

Use put_unaligned to fix warnings about unaligned accesses.

Signed-off-by: Patrick McHardy <kaber@trash.net>

---
commit fea42a5760325392653d556b1087f8274adcfb2e
tree c4c32f0feb2f947fb4d4f747c39935b535aa29cf
parent 2e175a90047a2dbc76fde169c990164895b25dfc
author Patrick McHardy <kaber@trash.net> Mon, 02 Apr 2007 13:54:14 +0200
committer Patrick McHardy <kaber@trash.net> Mon, 02 Apr 2007 13:54:14 +0200

 net/ipv4/netfilter/ipt_ULOG.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/netfilter/ipt_ULOG.c b/net/ipv4/netfilter/ipt_ULOG.c
index a26404d..9acc018 100644
--- a/net/ipv4/netfilter/ipt_ULOG.c
+++ b/net/ipv4/netfilter/ipt_ULOG.c
@@ -61,6 +61,7 @@
 #include <linux/netfilter_ipv4/ipt_ULOG.h>
 #include <net/sock.h>
 #include <linux/bitops.h>
+#include <asm/unaligned.h>
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Harald Welte <laforge@gnumonks.org>");
@@ -236,9 +237,9 @@ static void ipt_ulog_packet(unsigned int hooknum,
 
 	/* copy hook, prefix, timestamp, payload, etc. */
 	pm->data_len = copy_len;
-	pm->timestamp_sec = skb->tstamp.off_sec;
-	pm->timestamp_usec = skb->tstamp.off_usec;
-	pm->mark = skb->mark;
+	put_unaligned(skb->tstamp.off_sec, &pm->timestamp_sec);
+	put_unaligned(skb->tstamp.off_usec, &pm->timestamp_usec);
+	put_unaligned(skb->mark, &pm->mark);
 	pm->hook = hooknum;
 	if (prefix != NULL)
 		strncpy(pm->prefix, prefix, sizeof(pm->prefix));

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: unaligned access in ipt_ULOG
  2007-04-02 11:55     ` Patrick McHardy
@ 2007-04-12 21:27       ` David Miller
  -1 siblings, 0 replies; 7+ messages in thread
From: David Miller @ 2007-04-12 21:27 UTC (permalink / raw)
  To: kaber; +Cc: Joerg.Friedrich, netfilter-devel, sparclinux

From: Patrick McHardy <kaber@trash.net>
Date: Mon, 02 Apr 2007 13:55:56 +0200

> David Miller wrote:
> > Patrick, this is on sparc64, it appears to be this code:
> > 
> > 	pm->timestamp_sec = skb->tstamp.off_sec;
> > 	pm->timestamp_usec = skb->tstamp.off_usec;
> > 
> > and the NLMSG_DATA() (and thus 'pm') is not 8-byte aligned.
> > 
> > I bet this is a 32-bit sparc binary, has the idea of a compat
> > layer for the ULOG bits ever been discussed?
> 
> 
> No, I can't imagine how to do this since we don't have any compat
> infrastructure for netlink, so we would have to know whether the
> receiving process is a 32 bit binary in ipt_ULOG itself. We have
> some compat code in userspace to deal with the different structure
> layout, so besides the unaligned accesses, it should already work
> fine. Since ULOG is obsolete and nfnetlink_log shouldn't have
> these issues, I think the best way to fix this is to use
> put_unaligned in ipt_ULOG.
> 
> How does this look?

Thanks for the explanation, the patch looks fine, applied.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: unaligned access in ipt_ULOG
@ 2007-04-12 21:27       ` David Miller
  0 siblings, 0 replies; 7+ messages in thread
From: David Miller @ 2007-04-12 21:27 UTC (permalink / raw)
  To: kaber; +Cc: Joerg.Friedrich, netfilter-devel, sparclinux

From: Patrick McHardy <kaber@trash.net>
Date: Mon, 02 Apr 2007 13:55:56 +0200

> David Miller wrote:
> > Patrick, this is on sparc64, it appears to be this code:
> > 
> > 	pm->timestamp_sec = skb->tstamp.off_sec;
> > 	pm->timestamp_usec = skb->tstamp.off_usec;
> > 
> > and the NLMSG_DATA() (and thus 'pm') is not 8-byte aligned.
> > 
> > I bet this is a 32-bit sparc binary, has the idea of a compat
> > layer for the ULOG bits ever been discussed?
> 
> 
> No, I can't imagine how to do this since we don't have any compat
> infrastructure for netlink, so we would have to know whether the
> receiving process is a 32 bit binary in ipt_ULOG itself. We have
> some compat code in userspace to deal with the different structure
> layout, so besides the unaligned accesses, it should already work
> fine. Since ULOG is obsolete and nfnetlink_log shouldn't have
> these issues, I think the best way to fix this is to use
> put_unaligned in ipt_ULOG.
> 
> How does this look?

Thanks for the explanation, the patch looks fine, applied.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2007-04-12 21:27 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-30 21:48 unaligned access in ipt_ULOG Joerg Friedrich
2007-03-30 22:05 ` David Miller
2007-03-30 22:05   ` David Miller
2007-04-02 11:55   ` Patrick McHardy
2007-04-02 11:55     ` Patrick McHardy
2007-04-12 21:27     ` David Miller
2007-04-12 21:27       ` David 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.