alignment faults in 3.6
mans at mansr.com
Fri Oct 12 08:16:28 EDT 2012
Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> On Fri, Oct 12, 2012 at 12:18:08PM +0100, Måns Rullgård wrote:
>> Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
>> > Well, I get the last word here and it's no.
>> Sadly, yes.
> It's not "sadly" - it's a matter of fact that the kernel does from time
> to time generate misaligned accesses and they are _not_ bugs. If they
> were bugs, then the code to fix up misaligned accesses would not have
> been developed, and we'd instead take the fault and panic or something
> like that.
>> >> >> If all alignment faults in the kernel are caused by broken drivers,
>> >> >> that would at least give us some hope of finding those drivers while
>> >> >> at the same time not causing much overhead in the case where we need
>> >> >> to do the fixup in the meantime.
>> >> >
>> >> > No. It is my understanding that various IP option processing can also
>> >> > cause the alignment fault handler to be invoked, even when the packet is
>> >> > properly aligned, and then there's jffs2/mtd which also relies upon
>> >> > alignment faults being fixed up.
>> >> As far as I'm concerned, this is all hearsay, and I've only ever heard
>> >> it from you. Why can't you let those who care fix these bugs instead?
>> > You know, I'm giving you the benefit of my _knowledge_ which has been
>> > built over the course of the last 20 years.
>> How proud you sound. Now could you say something of substance instead?
> You're proving yourself to be idiot? There, that's substance.
>> > I've been in these discussions with networking people before. I ended
>> > up having to develop the alignment fault handler because of those
>> > discussions. And oh look, Eric confirmed that the networking code
>> > isn't going to get "fixed" as you were demanding, which is exactly
>> > what I said.
>> Funny, I saw him say the exact opposite:
>> So if you find an offender, please report a bug, because I can
>> guarantee you we will _fix_ it.
> No, let's go back.
> - You were demanding that the ipv4 header structure should be packed.
I demanded no such thing.
> I said that wasn't going to happen because the networking people
> wouldn't allow it, and it seems that's been proven correct.
> - You were demanding that the ipv4 code used the unaligned accessors.
Again, I made no such demand.
> I said that networking people wouldn't allow it either, and that's
> also been proven correct.
I did not, in fact, _demand_ anything at all. What I did say was that
to fix the problem of unaligned access traps the OP was having, the
(driver) code supplying the unaligned pointer should be fixed, or *if
that is not possible* mark the structs __packed. As it turns out,
fixing the driver is easy, so there is no need to change the structs or
how they are accessed.
> Both these points have been proven correct because Eric has said that the
> core networking code is _not_ going to be changed to suit this.
> What Eric _has_ said is that networking people consider packets supplied
> to the networking layer where the IPv4 header is not aligned on architectures
> where misaligned accesses are a problem to be a bug in the network driver,
> not the network code, and proposed a solution.
> That's entirely different from all your claims that the core networking
> code needs fixing to avoid these misaligned accesses.
I never said that. I said whatever code is responsible for the pointer
should be fixed. That code turns out to be the driver.
>> > I've been in discussions with MTD people over these issues before, I've
>> > discussed this with David Woodhouse when it came up in JFFS2. I *KNOW*
>> > these things.
>> In the same way you "know" the networking people won't fix their code,
>> despite them _clearly_ stating the opposite?
> I'll tell you exactly how I *KNOW* this. The issue came up because of
> noMMU, which does not have any way to fix up alignment faults. JFFS2
> passes randomly aligned buffers to the MTD drivers, and the MTD drivers
> assume that they're aligned and they do word accesses on them.
So jffs2 is broken. Why can't it be fixed?
> See the thread http://lists.arm.linux.org.uk/lurker/thread/20021204.191632.4473796b.en.html
That thread is about detecting misaligned accesses and what to do with
them if they do occur. I don't see anyone successfully arguing against
fixing the code causing them.
> See: http://lists.arm.linux.org.uk/lurker/message/20020225.195925.02bdbd47.en.html
Yes, there seems to be a problem in jffs2. Or at least there was one 10
> and: http://lists.arm.linux.org.uk/lurker/message/20020313.150932.081a7592.en.html
Yes, disabling the alignment trap on armv5 is a bad idea. Nobody has
> There's several other threads where it's also discussed.
> And while you're there, note the date. There is nothing recent about this
> issue. It's well known, and well understood by those who have a grasp of
> the issues that alignment faults are a part of normal operation by the
> ARM kernel - and is one of the penalties of being tied into architecture
> independent code.
> Compromises have to be sought, and that's the compromise we get to live
So because of some ancient history with jffs2, we should deny
present-day developers the tools to quickly identify problems in their
code? I just _love_ such compromises.
>> > You can call it hearsay if you wish, but it seems to be more accurate
>> > than your wild outlandish and pathetic statements.
>> So you're resorting to name-calling. Not taking that bait.
> Sorry? So what you're saying is that it's fine for you to call my
> comments hearsay, but I'm not allowed to express a view on your comments.
> How arrogant of you.
Go ahead, pile it on. I'm not falling into this trap.
mans at mansr.com
More information about the linux-arm-kernel