Ext2 lets the stuff get written to disk because it assumes linux won't mark pages from files in a RO filesystem dirty. Since ext2 assumes this, it doesn't bother to check in ext2_writepage(), which is perfectly sensible. It just happens to be wrong in this case.
-Ben On Thu, Jan 30, 2003 at 12:56:30PM -0800, Fargusson.Alan wrote: > 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]
