Re: net: alignment problem in icmp code

2007-10-22 Thread Eric Dumazet
Pierre Ossman a écrit : On Mon, 22 Oct 2007 02:05:38 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: From: Pierre Ossman <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 10:42:08 +0200 This seems like a rather evil layering violation. This has a 10+ year precedence and it's why

Re: net: alignment problem in icmp code

2007-10-22 Thread Pierre Ossman
On Mon, 22 Oct 2007 02:05:38 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: Pierre Ossman <[EMAIL PROTECTED]> > Date: Mon, 22 Oct 2007 10:42:08 +0200 > > > This seems like a rather evil layering violation. > > This has a 10+ year precedence and it's why the Linux networking stack >

Re: net: alignment problem in icmp code

2007-10-22 Thread David Miller
From: Pierre Ossman <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 10:42:08 +0200 > This seems like a rather evil layering violation. This has a 10+ year precedence and it's why the Linux networking stack is so fast. If you read any other driver you would have seen the skb_reserve() call every one o

Re: net: alignment problem in icmp code

2007-10-22 Thread Pierre Ossman
On Mon, 22 Oct 2007 01:31:05 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > > On fast paths we aren't going to add things like get_unaligned() > calls. > > Every architecture should handle unaligned accesses properly, and for > the fast paths the network driver should provide the packet f

Re: net: alignment problem in icmp code

2007-10-22 Thread David Miller
From: Pierre Ossman <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 09:23:50 +0200 > As for other instances of unaligned accesses, is there any active > work on getting rid of those? And would you accept more patches for > fixing them? (Code complexity being the downside) On fast paths we aren't going

Re: net: alignment problem in icmp code

2007-10-22 Thread Pierre Ossman
On Sun, 21 Oct 2007 22:15:24 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > > Sure. But the language defines that the types in question > must be 64-bit aligned, so it is legal for the compiler to > emit this code. > > It's not a GCC bug. > I've confirmed this behaviour on the AVR32 ar

Re: net: alignment problem in icmp code

2007-10-21 Thread David Miller
From: Pierre Ossman <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 06:54:43 +0200 > On Sun, 21 Oct 2007 16:02:15 -0700 (PDT) > David Miller <[EMAIL PROTECTED]> wrote: > > > You will get a 64-bit load and a 64-bit store emitted by > > the compiler. Here is what we get on sparc64: > > I assume those

Re: net: alignment problem in icmp code

2007-10-21 Thread Pierre Ossman
On Sun, 21 Oct 2007 16:02:15 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: Pierre Ossman <[EMAIL PROTECTED]> > Date: Sun, 21 Oct 2007 23:21:13 +0200 > > > Not sure that would be valid. memcpy() is defined as having void* > > arguments, and the compiler cannot just ignore that if it

Re: net: alignment problem in icmp code

2007-10-21 Thread David Miller
From: Pierre Ossman <[EMAIL PROTECTED]> Date: Sun, 21 Oct 2007 23:21:13 +0200 > Not sure that would be valid. memcpy() is defined as having void* > arguments, and the compiler cannot just ignore that if it chooses to > inline it. Yes it can, there are C language rules about the alignment of types

Re: net: alignment problem in icmp code

2007-10-21 Thread Pierre Ossman
On Sun, 21 Oct 2007 12:48:14 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > > You are missing a crucial point. > > The compiler may emit the same exact loads and stores when it inlines > memcpy() if it "knows" the objects are aligned properly. And it very > much will do this. > Not sur

Fw: net: alignment problem in icmp code

2007-10-21 Thread Темерханов Сергей
Пересылаемое сообщение 21.10.07, 23:48, David Miller ([EMAIL PROTECTED]): From: Pierre Ossman <[EMAIL PROTECTED]> Date: Sun, 21 Oct 2007 11:34:05 +0200 > Inlining isn't the problem, but the defined semantics of assignment > versus memcpy(). memcpy() must work on any region of

Fw: net: alignment problem in icmp code

2007-10-21 Thread Темерханов Сергей
Пересылаемое сообщение 21.10.07, 23:48, David Miller ([EMAIL PROTECTED]): From: Pierre Ossman <[EMAIL PROTECTED]> Date: Sun, 21 Oct 2007 11:34:05 +0200 > Inlining isn't the problem, but the defined semantics of assignment > versus memcpy(). memcpy() must work on any region of

Re: net: alignment problem in icmp code

2007-10-21 Thread David Miller
From: Pierre Ossman <[EMAIL PROTECTED]> Date: Sun, 21 Oct 2007 11:34:05 +0200 > 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. You are missing a cru

Re: net: alignment problem in icmp code

2007-10-21 Thread Pierre Ossman
On Sat, 20 Oct 2007 22:12:57 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: Pierre Ossman <[EMAIL PROTECTED]> > 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 rou

Re: net: alignment problem in icmp code

2007-10-20 Thread David Miller
From: Pierre Ossman <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Unfortunately

net: alignment problem in icmp code

2007-10-20 Thread Pierre Ossman
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 <[EMAIL PROTECTED]> --- diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c index 272c69e..a7e2ec9 100644 --- a/net/ipv4/icmp.