[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071021113405.37fa0bc5@poseidon.drzeus.cx>
Date: Sun, 21 Oct 2007 11:34:05 +0200
From: Pierre Ossman <drzeus@...eus.cx>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org
Subject: Re: net: alignment problem in icmp code
On Sat, 20 Oct 2007 22:12:57 -0700 (PDT)
David Miller <davem@...emloft.net> wrote:
> From: Pierre Ossman <drzeus@...eus.cx>
> Date: Sat, 20 Oct 2007 23:35:40 +0200
>
> > Structure assignment have to be aligned just like any assignment, and the skb could point to anything. So take the safe route and use a memcpy().
> >
> > Signed-off-by: Pierre Ossman <drzeus@...eus.cx>
>
> Unfortunately this doesn't work, GCC can inline the memcpy just like
> the assignment.
>
> I tried to use a similar trick in the net/xfrm/xfrm_user.c code
> but in the end it doesn't work at all.
Inlining isn't the problem, but the defined semantics of assignment versus memcpy(). memcpy() must work on any region of memory, whilst assignment must only work on a properly aligned object. Since icmphdr contains a u32, the compiler "knows" the object will always be 32-bit aligned and generates assembly based on this assumption. Of course this is incorrect if the lower layers didn't have a multiple of 4 bytes of headers.
Anyway, I discovered the hard way that there are lots and lots of places in the IP code that assumes alignment, so this seems to be a rather daunting task to fix. So this patch will just be one very small piece of the puzzle. :/
(Perhaps something for kernel newbies, to track down and fix all the alignment assumptions in the IP stack?)
Rgds
Pierre
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists