Bob: Did you test this with one process accessing the file? In your description of the problem I got the impression that you didn't.
What version is your kernel? In case you didn't know: the truncate will not cause any space to be allocated to the file. There must be more going on here then just marking the page dirty, otherwise there would be no place to write the dirty page. The more I think about this, the more I think this may be intentional. The mmap data may need to be backed someplace. Anyone: I would be interested in knowing if this problem can be reproduced on another architecture. Can anyone test this on a PC with the same version of the Linux kernel? Unfortunately I don't have Linux running on anything right now, or I would test it. -----Original Message----- From: Ben Marzinski [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: SLES7 mmap problem on s390 There is a reproducible memory mapping problem with the s390 SuSE linux setup we have. The bug occurs when two processes have private, read-only mappings of the same file and both processes page in the same page at the same time. The PTE for that page gets incorrectly marked dirty, which causes the page to be marked dirty, and the writepage() address space operation to be called. Nothing that the processes have done should have caused the page to be written back to the file. The file is modified even if the whole filesystem is mounted Read-Only. Our setup is: A 31-bit s390 A 2-processor virtual machine with 128MB of RAM SuSE SLES7 with the timer-patched kernel. A 2.5 GB dasd The problem can be reproduced by doing the following: 1) Make an Ext2 filesystem on a spare device. Mount it. 2) On the new filesystem, create a file that is larger than the available memory and nothing but a hole. # touch file; perl -e 'truncate("file", 209715200);' 3) Remount the filesystem Read-Only 4) Run a program that mmaps the file, and then forks a couple processes that keep on printing out random parts of the mmaped file. 5) watch the number of Used blocks in the filesystem grow with df. We also wrote a patch to ext2_writepage to prove that it was getting called. Has anyone else seen this? Does anyone know of any patches to deal with this? If anyone wants to see if they can reproduce this, I can send them a copy of the program that we wrote to do Step 4 from above. It's less than 100 lines of C code. Thanks -Ben Marzinski [EMAIL PROTECTED]
