Kernel 2.6.20.4 Unaligned address

Kernel 2.6.20.4 Unaligned address

[doctor raid]

[1] kernel errors reporting unaligned access of memory
[2]  The following two lines iterate twice a piece, about once every 2 minutes:

      Kernel unaligned access at TPC[79c344] arpt_do_table+0x3cc/0x640
       Kernel unaligned access at TPC[79c33c] arpt_do_table+0x3c4/0x640

[3]  ...

[4] Linux version 2.6.20.4 (root@outland) (gcc version 3.3.5 (Debian
1:3.3.5-13)) #3
 Fri Apr 6 18:08:28 PDT 2007

[7] This is running on a Netra t1 105 (sparc)

/proc/cpu:


cpu             : TI UltraSparc IIi (Sabre)

fpu             : UltraSparc IIi integrated FPU
prom            : OBP 3.10.27 2000/06/22 16:45
type            : sun4u
ncpus probed    : 1
ncpus active    : 1
D$ parity tl1   : 0
I$ parity tl1   : 0
Cpu0Bogo        : 880.43
Cpu0ClkTck      : 000000001a3a605f
MMU Type        : Spitfire

I can attach my .config if necessary, but don't want to clutter this
email with any
unnecessary data.

-brandon

Re: Kernel 2.6.20.4 Unaligned address

[David Miller]

Please report sparc platform bugs to sparclinux@vger.kernel.org next
time, thank you.

Meanwhile I'll take a look at this one.

Re: Kernel 2.6.20.4 Unaligned address

[Mathieu Chouquet-Stringer]

        Hello,

davem@davemloft.net (David Miller) writes:
> Please report sparc platform bugs to sparclinux@vger.kernel.org next
> time, thank you.
> 
> Meanwhile I'll take a look at this one.

I have a similar problem on an U5 [*] running 2.6.21-rc6-gbbef6181 :

Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0
Kernel unaligned access at TPC[6c9950] svc_udp_recvfrom+0x21c/0x3f0


Disassembling vmlinux gives me that:
0x006c993c <svc_udp_recvfrom+512>:      call  0x5999c8 <clear_bit>
0x006c9940 <svc_udp_recvfrom+516>:      clr  %o0
0x006c9944 <svc_udp_recvfrom+520>:      call  0x6c7d4c <svc_sock_enqueue>
0x006c9948 <svc_udp_recvfrom+524>:      mov  %l3, %o0
0x006c994c <svc_udp_recvfrom+528>:      ld  [ %l1 + 0x88 ], %g2
0x006c9950 <svc_udp_recvfrom+532>:      ldx  [ %l5 + 8 ], %g3
0x006c9954 <svc_udp_recvfrom+536>:      mov  0x11, %g1
0x006c9958 <svc_udp_recvfrom+540>:      add  %g2, -8, %i0
0x006c995c <svc_udp_recvfrom+544>:      st  %g1, [ %l4 + 0xdc8 ]
0x006c9960 <svc_udp_recvfrom+548>:      cmp  %g3, 8
0x006c9964 <svc_udp_recvfrom+552>:      be,pn   %xcc, 0x6c999c<svc_udp_recvfrom+608>


The same stuff but using objdump this time:
                        21c4: R_SPARC_WDISP30   clear_bit
    21c8:       90 10 20 00     clr  %o0
    21cc:       7f ff f9 02     call  5d4 <svc_sock_enqueue>
    21d0:       90 10 00 13     mov  %l3, %o0
    21d4:       c4 04 60 88     ld  [ %l1 + 0x88 ], %g2
    21d8:       c6 5d 60 08     ldx  [ %l5 + 8 ], %g3
    21dc:       82 10 20 11     mov  0x11, %g1
    21e0:       b0 00 bf f8     add  %g2, -8, %i0
    21e4:       c2 25 2d c8     st  %g1, [ %l4 + 0xdc8 ]
    21e8:       80 a0 e0 08     cmp  %g3, 8
    21ec:       02 60 00 0e     be,pn   %xcc, 2224 <svc_udp_recvfrom+0x260>
    21f0:       f0 25 21 24     st  %i0, [ %l4 + 0x124 ]
    21f4:       40 00 00 00     call  21f4 <svc_udp_recvfrom+0x230>
                        21f4: R_SPARC_WDISP30   net_ratelimit

Looking at svc_udp_recvfrom, it all comes down to this portion of code (I
believe, unless I got it wrong):

        /*
         * Maybe more packets - kick another thread ASAP.
         */
        svc_sock_received(svsk);

        len  = skb->len - sizeof(struct udphdr);
        rqstp->rq_arg.len = len;    <=====================================

        rqstp->rq_prot = IPPROTO_UDP;

        if (cmh->cmsg_level != IPPROTO_IP ||
            cmh->cmsg_type != IP_PKTINFO) {
                if (net_ratelimit())
                        printk("rpcsvc: received unknown control message:"
                               "%d/%d\n",
                               cmh->cmsg_level, cmh->cmsg_type);
                skb_free_datagram(svsk->sk_sk, skb);
                return 0;
        }

I won't have access to this box for quite some time: I'm just unsure when I
will be able to test again any kind of patches...

I hope I've forwarded enough information though.

Cheers,
Mathieu



[*] : 
cpu             : TI UltraSparc IIi (Sabre)
fpu             : UltraSparc IIi integrated FPU
prom            : OBP 3.31.0 2001/07/25 20:36
type            : sun4u
ncpus probed    : 1
ncpus active    : 1
D$ parity tl1   : 0
I$ parity tl1   : 0
Cpu0Bogo        : 720.40
Cpu0ClkTck      : 0000000015752a00
MMU Type        : Spitfire

Kernel got compiled with:
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-cpu=v8
--enable-checking=release sparc-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)


-- 
Mathieu Chouquet-Stringer
            The sun itself sees not till heaven clears.
	             -- William Shakespeare --

Re: Kernel 2.6.20.4 Unaligned address

[David Miller]

From: "doctor raid" <drraid@gmail.com>
Date: Tue, 10 Apr 2007 16:02:01 -0700

> [1] kernel errors reporting unaligned access of memory
> [2]  The following two lines iterate twice a piece, about once every 2 minutes:
> 
>       Kernel unaligned access at TPC[79c344] arpt_do_table+0x3cc/0x640
>        Kernel unaligned access at TPC[79c33c] arpt_do_table+0x3c4/0x640

This patch below should fix this problem.

Patrick I'm going to push this to Linus.  Even if it doesn't
fix this person's problem, either both the input device loop
and the output device loop should use the "long" casting
optimization or both should not :-)

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
index 5170f5c..57b0221 100644
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -166,13 +166,9 @@ static inline int arp_packet_match(const struct arphdr *arphdr,
 		return 0;
 	}
 
-	for (i = 0, ret = 0; i < IFNAMSIZ/sizeof(unsigned long); i++) {
-		unsigned long odev;
-		memcpy(&odev, outdev + i*sizeof(unsigned long),
-		       sizeof(unsigned long));
-		ret |= (odev
-			^ ((const unsigned long *)arpinfo->outiface)[i])
-			& ((const unsigned long *)arpinfo->outiface_mask)[i];
+	for (i = 0, ret = 0; i < IFNAMSIZ; i++) {
+		ret |= (outdev[i] ^ arpinfo->outiface[i])
+			& arpinfo->outiface_mask[i];
 	}
 
 	if (FWINV(ret != 0, ARPT_INV_VIA_OUT)) {

Re: Kernel 2.6.20.4 Unaligned address

[Patrick McHardy]

David Miller wrote:
> From: "doctor raid" <drraid@gmail.com>
> Date: Tue, 10 Apr 2007 16:02:01 -0700
> 
> 
>>[1] kernel errors reporting unaligned access of memory
>>[2]  The following two lines iterate twice a piece, about once every 2 minutes:
>>
>>      Kernel unaligned access at TPC[79c344] arpt_do_table+0x3cc/0x640
>>       Kernel unaligned access at TPC[79c33c] arpt_do_table+0x3c4/0x640
> 
> 
> This patch below should fix this problem.
> 
> Patrick I'm going to push this to Linus.  Even if it doesn't
> fix this person's problem, either both the input device loop
> and the output device loop should use the "long" casting
> optimization or both should not :-)


Looks good, thanks Dave. On 64 bit both interfaces are unaligned
within struct arpt_arp:

char                       iniface[16];          /*    94    16 */
char                       outiface[16];         /*   110    16 */