| |||||||||||||
|
| |||||||||||||
The source of the e1000e corruption bugThe source of the e1000e corruption bugPosted Oct 23, 2008 9:03 UTC (Thu) by alonz (subscriber, #815)In reply to: The source of the e1000e corruption bug by modernjazz 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?
(Log in to post comments)
The source of the e1000e corruption bug Posted Oct 23, 2008 12:11 UTC (Thu) by nevets (subscriber, #11875) [Link] 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.
|
|
||||||||||||