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




> 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.
> Thanks
> -Ben Marzinski

Reply via email to