On Sat, Mar 15, 2014 at 09:02:16PM +0000, Al Viro wrote:
> 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...
BTW, experimenting with that thing shows that junk in the tail of the page
actually comes from some unused sectors on the same device. So it's an
information leak at the very least - I have seen it pick bits and pieces of
previously removed files that way.
While we are at it, the following creates such a buggered file in about
a half of runs:
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/mman.h>
#define O_DIRECT 00040000
main()
{
int n = 0x5cf2e - 0x47000;
int fd = open("/mnt/junk", O_RDWR|O_CREAT|O_TRUNC|O_DIRECT, 0666);
char *p;
ftruncate(fd, 0x5cf2e);
p = mmap(NULL, n, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x47000);
memset(p, 'x', n);
msync(p, n, MS_SYNC);
munmap(p, n);
lseek(fd, 0x59000, SEEK_SET);
p = malloc(0x13a00 + 512);
memset(p, 'z', 0x13a00 + 512);
write(fd, p + 512 - ((unsigned long)p & 511), 0x13a00);
}
The frequency depends on the fraction of unused sectors with non-zero
contents - for all I know it might hit that bug in 100% of runs, but
I can only detect that if the junk it picks contains non-zero data.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
