VM BUG, set_page_dirty() buggy?

[Jens Axboe]

Hi,

I'm seeing what looks like a bug in set_page_dirty() in 2.5.44 (and
2.5.44-mm5), pages are being dumped. I first discovered this when
playing with the SGIO stuff, reading CD images and writing them to disk.
This works well as long as there is no memory pressure on the box.
However, if I run a fillmem app at the same time, zero filled holes
appear in the output file. After trying to trace a bug in my code, I
decided to test O_DIRECT reads to see if they exhibited the same bug.
And indeed they did.

I wont bore you with the SGIO test case, the O_DIRECT is much smaller.
What I do to reproduce is read a file off an ext2 partition and plain
write the output to another file. The input file is actually generated
from an SGIO read of a CD, and is ~500MiB in length. While I'm doing
this, I run the memfiller app (it just allocs ~180% of physical memory
and memsets it).

bart:~ # while true; do echo "Starting run $TURN"; ./fillmem; ((TURN++)); done

bart:~ # ./oread xpdisc_pio /mnt/xpdisc_sr0

/ is on /dev/sda3, ext2, 4kb block size.
/mnt is on /dev/hda1, ext2, 4kb block size. tried ext3 too.
swap is on /dev/sda1

When oread completes, I kill fillmem and compare the two files. This
typically succeeds the first time. Then umount and mount /mnt, and redo
the compare:

bart:~ # cmp /mnt/xpdisc_sr0 xpdisc_pio
/mnt/xpdisc_sr0 xpdisc_pio differ: char 44433409, line 188432

If you look at /mnt/xpdisc_sr0 from 44433408 and on, there will be a
zero-filled hole ranging from ~500KiB -> ~3000KiB. This varies.

I've attached oread in its simplicity. System being tested here is a
dual P3-800MHz, not using preempt (never do). It doesn't matter if the
input is on /dev/sda or ide disk, scsi cdrom, or atapi cdrom. It behaves
the same way, data is lost.

-- 
Jens Axboe