On Fri, Oct 12, 2012 at 12:00:03PM +0100, Måns Rullgård wrote:
quoted
Russell King - ARM Linux [off-list ref] writes:
quoted
On Fri, Oct 12, 2012 at 08:11:42AM +0000, Arnd Bergmann wrote:
quoted
On Thursday 11 October 2012, Måns Rullgård wrote:
quoted
quoted
But, the IP header is expected to be aligned.
Everything tells the compiler the struct is perfectly aligned. When the
buggy driver passes a misaligned pointer, bad things happen.
Would it be appropriate to add a WARN_ON_ONCE() in the alignment
fault path then?
I think that's an excellent idea.
Well, I get the last word here and it's no.
Sadly, yes.
quoted
quoted
quoted
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?
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.
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?
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.
--
Måns Rullgård
mans@mansr.com
From: Russell King - ARM Linux <hidden> Date: 2012-10-12 11:44:43
On Fri, Oct 12, 2012 at 12:18:08PM +0100, Måns Rullgård wrote:
Russell King - ARM Linux [off-list ref] writes:
quoted
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.
quoted
quoted
quoted
quoted
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.
quoted
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 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.
I said that networking people wouldn't allow it either, and that's
also been proven correct.
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.
quoted
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.
See the thread http://lists.arm.linux.org.uk/lurker/thread/20021204.191632.4473796b.en.html
See: http://lists.arm.linux.org.uk/lurker/message/20020225.195925.02bdbd47.en.html
and: http://lists.arm.linux.org.uk/lurker/message/20020313.150932.081a7592.en.html
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
with.
quoted
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.
From: Eric Dumazet <hidden> Date: 2012-10-12 12:08:12
On Fri, 2012-10-12 at 12:44 +0100, Russell King - ARM Linux wrote:
- You were demanding that the ipv4 header structure should be packed.
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.
I said that networking people wouldn't allow it either, and that's
also been proven correct.
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.
It seems we agree then, but your words were a bit misleading (at least
for me)
So yes, we built network stack with the prereq that IP headers are
aligned, but unfortunately many developers use x86 which doesnt care, so
its possible some bugs are added.
But its not by intent, only by accident.
Thanks
On Fri, Oct 12, 2012 at 02:08:12PM +0200, Eric Dumazet wrote:
So yes, we built network stack with the prereq that IP headers are
aligned, but unfortunately many developers use x86 which doesnt care, so
its possible some bugs are added.
x86 does have an alignment check flag that can be set in the flags register.
Somehow, I doubt anyone would be willing to walk through all the noise the
faults would likely trigger.
-ben
--
"Thought is the essence of where you are now."
From: David Laight <hidden> Date: 2012-10-12 14:36:13
x86 does have an alignment check flag that can be set in the flags register.
Somehow, I doubt anyone would be willing to walk through all the noise the
faults would likely trigger.
Someone has tried to set that (in userspace) on NetBSD.
The fault reporting has been fixed, but really nothing
works since optimised parts of libc deliberately do
misaligned transfers.
David
From: Eric Dumazet <hidden> Date: 2012-10-12 14:48:20
On Fri, 2012-10-12 at 10:22 -0400, Benjamin LaHaise wrote:
On Fri, Oct 12, 2012 at 02:08:12PM +0200, Eric Dumazet wrote:
quoted
So yes, we built network stack with the prereq that IP headers are
aligned, but unfortunately many developers use x86 which doesnt care, so
its possible some bugs are added.
x86 does have an alignment check flag that can be set in the flags register.
Somehow, I doubt anyone would be willing to walk through all the noise the
faults would likely trigger.
If this can be mapped to an event that can be used by perf tool, that
might be useful ?
On Fri, Oct 12, 2012 at 04:48:20PM +0200, Eric Dumazet wrote:
quoted
Somehow, I doubt anyone would be willing to walk through all the noise the
faults would likely trigger.
If this can be mapped to an event that can be used by perf tool, that
might be useful ?
There are performance counters for the various different types of alignment
faults supported by perf. Modern x86 makes the vast majority of unaligned
accesses very low overhead -- the only ones that really hurt are those
straddling different vm pages, but even those have little cost compared to
obsolete microarchitectures (*cough* P4 *cough*).
-ben
--
"Thought is the essence of where you are now."
From: Ben Hutchings <hidden> Date: 2012-10-12 15:04:14
On Fri, 2012-10-12 at 16:48 +0200, Eric Dumazet wrote:
On Fri, 2012-10-12 at 10:22 -0400, Benjamin LaHaise wrote:
quoted
On Fri, Oct 12, 2012 at 02:08:12PM +0200, Eric Dumazet wrote:
quoted
So yes, we built network stack with the prereq that IP headers are
aligned, but unfortunately many developers use x86 which doesnt care, so
its possible some bugs are added.
x86 does have an alignment check flag that can be set in the flags register.
Somehow, I doubt anyone would be willing to walk through all the noise the
faults would likely trigger.
If this can be mapped to an event that can be used by perf tool, that
might be useful ?
AC was so useless that it has now been reallocated to use by SMAP
<https://lwn.net/Articles/517251/>.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
That is a long time coming!
Wonder when it will appear in any cpus.
How am I going to get root access when I can't get the kernel
to execute code at address 0 any more :-)
That is a long time coming!
Wonder when it will appear in any cpus.
How am I going to get root access when I can't get the kernel
to execute code at address 0 any more :-)
Moving further off the topic: that is supposed to be prevented by a
separate feature, SMEP, which I think is available in current Intel CPUs
(Ivy Bridge). Also, unprivileged users are generally not permitted to
mmap() at address 0.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.