This is very curious. I bet that there is some problem in the VM subsystem having to do with pages that are mapped to more than one process. I am also wondering why the filesystem allowed the write to a disk that is mounted read only.
-----Original Message----- From: Ben Marzinski [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 12:17 PM To: [EMAIL PROTECTED] Subject: Re: SLES7 mmap problem on s390 > 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. > The problem occurs when multiple processes have the file mmaped. > What version is your kernel? > 2.4.7-SuSE-53 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. It is definitely the incorrect calling of writepage that is causing us problems. Like I said, we made a patch to ext2_writepage() and even without a file with a hole, linux writes to it when it shouldn't.. > The more I think about this, the more I think this may be intentional. The mmap >data may need to be backed someplace. When it's mmapped PRIVATE READONLY, it shouldn't. It doesn't on other kernels. > 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? I know it doesn't happen on a kernel.org 2.4.7 kernel on a PC. I haven't tried it with this specific kernel on a PC though... That would give me a clue if it's in the architecture dependent code or not. Good Idea. Thanks. -Ben [EMAIL PROTECTED] > 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]
