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.

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
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.


-Ben Marzinski


Reply via email to