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