Regression in xfstests generic/263 is quite real - what happens is
that e.g.
ltp/fsx -F -H -N 10000 -o 128000 -l 500000 -r 4096 -t 512 -w 512 -Z /mnt/junk
where /mnt is on xfs ends up with a very odd file. mmap() of its last
page has garbage in the page tail when observed on *any* kernel. Copying
that file (with cp -a) yields a copy that doesn't trigger that behaviour.
What's more, xfs_repair doesn't notice anything fishy with that sucker.
This had been introduced (or, more likely, exposed) by the commit in
question. As far as I can see, it's an on-disk corruption of some sort;
it *might* be triggered by some kind of dio-related race, but I would be
rather surprised if that had been the case - fsx is single-threaded,
after all, and making it fsync() *and* mmap/msync/munmap after each write
still produces such a file. The file contents per se is fine, it's the
page tail on mmap() that is bogus.
Filesystem image after that crap is on ftp.linux.org.uk/pub/people/viro/img.bz2;
with that image mounted on /mnt we have
; ls -l /mnt/junk
-rw-r--r-- 1 root root 444928 Mar 15 16:26 /mnt/junk
; echo $((0x6ca00))
444928
; cat >foo.c <<'EOF'
#include <unistd.h>
#include <sys/mman.h>
main(int argc, char **argv)
{
int fd = open(argv[1], 0);
char *p = (char *)mmap(0, 0xa00, PROT_READ, MAP_SHARED, fd, (off_t)0x6c000);
if (p != (char *)-1)
write(1, p + 0xa00, 4096 - 0xa00);
}
EOF
; gcc foo.c
; ./a.out /mnt/junk | od -c
<lots of garbage>
; cp -a /mnt/junk /mnt/junk1
; ./a.out /mnt/junk1 | od -c
0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0003000
And that's essentially what makes generic/263 complain. Note, BTW, that
fallocate and hole-punching is irrelevant - test in generic/263 steps into
those, but the same thing happens with these operations disabled (by -F -H).
I've found the thread from last June where you've mentioned generic/263
regression; AFAICS, Dave's comments there had been wrong...
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
