Bug#394392: msync() in recent kernels fails LSB

[Martin Michlmayr <tbm@cyrius.com>]

* Jeff Licquia <licquia@debian.org> [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/