Re: cramfs corruption after BLKFLSBUF on loop device

[Olaf Hering <olh@suse.de>]

 On Mon, May 29, Olaf Hering wrote:

> This script will cause cramfs decompression errors, on SMP at least:
> 
> #!/bin/bash
> while :;do blockdev --flushbufs /dev/loop0;done </dev/null &>/dev/null&
> while :;do ps faxs  </dev/null &>/dev/null&done </dev/null &>/dev/null&
> while :;do dmesg    </dev/null &>/dev/null&done </dev/null &>/dev/null&
> while :;do find /mounts/instsys -type f -print0|xargs -0 cat &>/dev/null;done
> 
> ...
> Error -3 while decompressing!
> c0000000009592a2(2649)->c0000000edf87000(4096)
> Error -3 while decompressing!
> c000000000959298(2520)->c0000000edbc7000(4096)
> Error -3 while decompressing!
> c000000000959c70(2489)->c0000000f1482000(4096)
> Error -3 while decompressing!
> c00000000095a629(2355)->c0000000edaff000(4096)
> Error -3 while decompressing!
> ...
> 
> evms_access does the ioctl (lots of them) on the loop device.
> Its a long standing bug, 2.6.5 fails as well. cramfs_read() clears parts
> of the src buffer because the page is not uptodate. invalidate_bdev()
> touched the page last.
> cramfs_read() was called from line 480 or 490 when the
> PageUptodate(page) test fails.

Al, you added the PageUptodate check for 2.6.2.

http://linux.bkbits.net:8080/linux-2.6/gnupatch@400c1cddyzRoKomOj57xxUAmKnMbZQ

Should there be some locking for blockdev --flushbufs, or is the check
just bogus?