[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090405.025621.262216979.davem@davemloft.net>
Date: Sun, 05 Apr 2009 02:56:21 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: herbert@...dor.apana.org.au
Cc: kaber@...sh.net, nhorman@...driver.com, zbr@...emap.net,
netdev@...r.kernel.org, kuznet@....inr.ac.ru, pekkas@...core.fi,
jmorris@...ei.org, yoshfuji@...ux-ipv6.org
Subject: Re: [Patch 4/5] Network Drop Monitor: Adding drop monitor
implementation & Netlink protocol
From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Thu, 2 Apr 2009 22:45:49 +0800
> On Thu, Apr 02, 2009 at 04:42:18PM +0200, Patrick McHardy wrote:
> >
> > Actually we should be fine since the current netlink helpers only do
> > bytewise copying anyways. And I think we've pretty much gotten rid of
> > all the raw attribute accesses.
>
> What about stuff like xfrm_userpolicy_info? I suppose if *everything*
> is copied then it wouldn't matter.
You were saying?
[ 6400.609361] Kernel unaligned access at TPC[10258734] copy_to_user_state+0x54/0x9c [xfrm_user]
[ 6400.609498] Kernel unaligned access at TPC[10258734] copy_to_user_state+0x54/0x9c [xfrm_user]
[ 6400.667575] Kernel unaligned access at TPC[10258734] copy_to_user_state+0x54/0x9c [xfrm_user]
[ 6400.667707] Kernel unaligned access at TPC[10258734] copy_to_user_state+0x54/0x9c [xfrm_user]
This problem has existed for a long time. In this specific case even
if you use memcpy() (in fact memcpy() is being used here) GCC sees the
types and says it can do aligned 64-bit loads and stores to do the
memcpy() inline.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists