* Jeff Licquia <[EMAIL PROTECTED]> [2006-10-20 19:17]: > >From a recent run of the LSB 3.1 tests: > > 10|852 /tset/LSB.os/mfiles/msync_P/T.msync_P 22:58:49|TC Start, scenario ref > 858-0 > > FSG internal testing showed that Fedora Core 5's 2.6.18 kernel does not > fail in the same way. I believe I've traced it to a backported change > from 2.6.19 development. The specific commit touching msync() is > 204ec841fbea3e5138168edbc3a76d46747cc987 in git; it relies on several > commits immediately preceding it. I've built Linus's tree on amd64, and > it passes the test. I have not, however, built a 2.6.18 kernel with > this patch and tested it, though it's the only patch in the Fedora > kernel which touches the msync() code.
So it seems that the patches needed for msync() conformance we applied from 2.6.19 to our 2.6.18 cause filesystem corruption, see the current discussion on this on lkml. From what I understand it, plain 2.6.18 is not LSB 3.1 conform and you need some fixes which are associated with filesystem corruption. While Andrew, Linus and co are currently trying to come up with a patch, I think it might be better for us to simply back out these patches. What doe it take to get an exception for this LSB test? Surely the reasons cited above (fails with 2.6.18, a fairly current kernel and the patches to fix it are associated with fs corruption) are pretty good arguments for an exception... -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
