Subject: Re: kern/34751: regular panics in tcp_sack_option on NetBSD/alpha 3.0_STABLE
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Christian Biere <christianbiere@gmx.de>
List: netbsd-bugs
Date: 10/08/2006 02:50:02
The following reply was made to PR kern/34751; it has been noted by GNATS.

From: Christian Biere <christianbiere@gmx.de>
To: netbsd-bugs@netbsd.org
Cc: 
Subject: Re: kern/34751: regular panics in tcp_sack_option on NetBSD/alpha 3.0_STABLE
Date: Sun, 8 Oct 2006 04:39:43 +0200

 Eric Schnoebelen wrote:
 > Simon Burge says:
 > 
 > This looks like it happened in netinet/tcp_sack.c at:
 > 
 >         for (i = 0; i < num_sack_blks; i++, lp += 2) {
 >                 memcpy(&left, lp, sizeof(*lp));
 >                 memcpy(&right, lp + 1, sizeof(*lp));
 > --->            left = ntohl(left);
 >                 right = ntohl(right);
 
 > I think that it looks like gcc is optimising the memcpy out and doing an
 > unaligned load directly.  We probably need some sort of qualifier on a
 > variable somewhere?
 
 What about replacing memcpy() + ntohl() with endian-independent code? Does
 this generate proper assembler code?
 
 static inline u_int32_t
 peek_be32(const void *p)
 {
    const u_int8_t *u8 = p;
    return ((u_int32_t) p[0] << 24) |
 	  ((u_int32_t) p[1] << 16) |
 	  ((u_int32_t) p[2] << 8) |
 	  ((u_int32_t) p[3]);
 }
 
 left = peek_be32(lp);
 right = peek_be32(lp + 1);
  
 -- 
 Christian