Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Jun 2008 17:52:10 +1000
From:      Peter Jeremy <peterjeremy@optushome.com.au>
To:        Marc =?iso-8859-1?Q?L=F6rner?= <marc.loerner@hob.de>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Probable Bug in tcp.h
Message-ID:  <20080606075210.GD67629@server.vk2pj.dyndns.org>
In-Reply-To: <200806060930.28527.marc.loerner@hob.de>
References:  <200806051712.47048.marc.loerner@hob.de> <20080605155646.GC6864@epsilon.local> <200806060930.28527.marc.loerner@hob.de>

next in thread | previous in thread | raw e-mail | index | archive | help

--RASg3xLB4tUQ4RcS
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-Jun-06 09:30:28 +0200, Marc L=F6rner <marc.loerner@hob.de> wrote:
>th_x2 and th_off are created as a bitfield. But C-Standard says that
>bitfields are accessed as integers =3D> 4-bytes
>
>On itanium integers are read with ld4-command but the address of
>th_x2/th_off may not be aligned to 4-bytes =3D> we get an unaligned
>reference fault.

If the C compiler chooses to implement bitfields as a subset of a
32-bit integers, it is up to it to load an aligned 32-bit integer
and shift/mask the result appropriately to extract the fields.

In this particular case, th_x2/th_off are immediately preceeded by
a tcp_seq (u_int32_t) field and so will have 32-bit alignment.  Note
that the presence of 32-bit fields in the definition for struct tcphdr
means that the struct must be aligned to at least 32 bits.

>If we'd change to 1 byte-accesses =3D> I won't get any misaligned faults=
=20
>anymore.

I gather from this comment that you have some code using struct tcphdr
that is getting alignment errors.  struct tcphdr is extensively used
in the TCP stack within the kernel so it's likely that any layout or
alignment problem with it would show up there.  I suspect you are
dereferencing a mis-aligned struct tcphdr.

--=20
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.

--RASg3xLB4tUQ4RcS
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkhI7KoACgkQ/opHv/APuIccbwCgtGkXwOIifLt4K4DN0V0VQU6H
k6IAn1S0C0soIZdtaesp62Y9g/xVOwN3
=5suD
-----END PGP SIGNATURE-----

--RASg3xLB4tUQ4RcS--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080606075210.GD67629>