The source of the e1000e corruption bug
Posted Oct 23, 2008 12:11 UTC (Thu) by nevets
In reply to: The source of the e1000e corruption bug
Parent article: The source of the e1000e corruption bug
Wouldn't it be better to simply dump the entire contents of the mcount buffer whenever any code is unmapped, instead of just disabling this (useful) optimization in a kernel that is likely to have a long life?
From a safety point of view, no. Anything other than disabling it was unacceptable in the stable release. If we found a simple bug (off by one, or array out of bounds) then we could have fixed it. But the bug was a design issue (which has changed in 2.6.28).
How would we know for sure that we got every place that kernel text was freed? How do we know that we don't add more bugs with this "dump the mcount on release".
Now if you would like to have dynamic ftrace in 2.6.27, it would not be hard for me to port the new design. I've already ported it to 2.6.24-rt. Just do not expect this backport to show up in the stable branch.
to post comments)