Jon Masters [off-list ref] writes:
Hi everyone,
On 10/05/2012 10:33 AM, Rob Herring wrote:
quoted
On 10/05/2012 09:05 AM, Russell King - ARM Linux wrote:
quoted
On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
quoted
On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
quoted
Does it matter? I'm just relaying the argument against adding __packed
which was used before we were forced (by the networking folk) to implement
the alignment fault handler.
It doesn't really matter what will be accepted or not as adding __packed
to struct iphdr doesn't fix the problem anyway. gcc still emits a ldm.
The only way I've found to eliminate the alignment fault is adding a
barrier between the 2 loads. That seems like a compiler issue to me if
there is not a better fix.
This turns out to be caused by pointers being typecast to normal
(aligned) types.
quoted
quoted
Even so, please test the patch I've sent you in the sub-thread - that
needs testing whether or not GCC is at fault. Will's patch to add the
warnings _has_ uncovered a potential issue with the use of __get_user()
in some parts of the ARM specific kernel, and I really need you to test
that while you're experiencing this problem.
I've tested your patch and it appears to fix things. Thanks!
[...]
quoted
Now on to getting rid of faults on practically every single received IP
packet:
Multi: 9871002
RX packets:9872010 errors:0 dropped:0 overruns:0 frame:0
This will still be a problem, indeed. At least we can be aware we're
taking a large number of faults and hope for a netdev solution.
There are exactly two possible solutions:
1. Change the networking code so those structs are always aligned. This
might not be (easily) possible.
2. Mark the structs __packed and fix any typecasts like the ones seen in
this thread. This will have an adverse effect in cases where the
structs are in fact aligned.
Both solutions lie squarely in the networking code. It's time to
involve that list, or we'll never get anywhere.
--
Måns Rullgård
mans@mansr.com
On 10/10/2012 10:27 PM, Måns Rullgård wrote:
There are exactly two possible solutions:
1. Change the networking code so those structs are always aligned. This
might not be (easily) possible.
2. Mark the structs __packed and fix any typecasts like the ones seen in
this thread. This will have an adverse effect in cases where the
structs are in fact aligned.
Both solutions lie squarely in the networking code. It's time to
involve that list, or we'll never get anywhere.
Sure, please do let's figure out the plan. But my question is tangential
- I am after input from rmk on whether that patch he posted to fix the
atomicity of missaligned faults is going to be something we should plan
to be pulling into 3.6 for Fedora (after there's an official version) to
correct the might_fault warnings, etc.
Meanwhile, a separate fix of some kind is still likely to be needed
because we don't want to take a large number of alignment traps.
Jon.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Måns Rullgård
Sent: 11 October 2012 03:27
To: Jon Masters
Cc: linux-arm-kernel@lists.infradead.org; netdev@vger.kernel.org
Subject: Re: alignment faults in 3.6
Jon Masters [off-list ref] writes:
quoted
Hi everyone,
On 10/05/2012 10:33 AM, Rob Herring wrote:
quoted
On 10/05/2012 09:05 AM, Russell King - ARM Linux wrote:
quoted
On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
quoted
On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
quoted
Does it matter? I'm just relaying the argument against adding __packed
which was used before we were forced (by the networking folk) to implement
the alignment fault handler.
It doesn't really matter what will be accepted or not as adding __packed
to struct iphdr doesn't fix the problem anyway.
...
There are exactly two possible solutions:
1. Change the networking code so those structs are always aligned. This
might not be (easily) possible.
2. Mark the structs __packed and fix any typecasts like the ones seen in
this thread. This will have an adverse effect in cases where the
structs are in fact aligned.
Both solutions lie squarely in the networking code. It's time to
involve that list, or we'll never get anywhere.
It might be enough to use __attribute__((aligned(2))) on some structure
members (actually does 'ldm' need 8 byte alignment?? - in which case
aligned(4) is enough).
One on my bugbears is hardware that will once receive ethernet frames
onto a 4n boundary - it needs to be 4n+2. two bytes of 'junk' will do.
David
On Thu, Oct 11, 2012 at 09:21:35AM +0100, David Laight wrote:
It might be enough to use __attribute__((aligned(2))) on some structure
members (actually does 'ldm' need 8 byte alignment?? - in which case
aligned(4) is enough).
No, ldm just needs 4 byte alignment, the same as normal word loads/stores
not to fault. The only instructions which needs 8 byte alignment not to
fault are the double-word load/stores.
One on my bugbears is hardware that will once receive ethernet frames
onto a 4n boundary - it needs to be 4n+2. two bytes of 'junk' will do.
Indeed, but remember that is just a mere optimisation for IPv4. What
may be true of IPv4 is not necessarily true of other protocols, though
IPv4 is currently the dominant protocol today. IPv6 follows the same
alignment rules as IPv4, so it's unlikely to change.