linux-ext4 - Re: OpenPosix test case mmap_11-4 fails in ext4 filesystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140521150619.GA5459@rei.suse.cz>
Date:	Wed, 21 May 2014 17:06:19 +0200
From:	chrubis@...e.cz
To:	Theodore Ts'o <tytso@....edu>
Cc:	Luk???? Czerner <lczerner@...hat.com>,
	Xiaoguang Wang <wangxg.fnst@...fujitsu.com>,
	linux-ext4@...r.kernel.org
Subject: Re: OpenPosix test case mmap_11-4 fails in ext4 filesystem

Hi!
> This is a valid bug report which applies to upstream ext4.  It also
> applies to tmpfs, by the way.
> 
> It would be good to get this test case (thank you very much for
> writing it!) imported into xfstests, since the lack of this test is
> why we didn't notice the bug when we added the fs/ext4/page_io.c code
> paths.

It has been in LTP for ages. Maybe it's a time developers should start
to use LTP :) (We managed to fix most of the problems that are credible
for the bad LTP reputation...)

> BTW, there is one interesting thing about that changed when we moved
> to page based I/O (years and years ago).  The requirement in mmap is
> as Xiaoguang stated:
> 
>        A file is mapped in multiples of the page size.  For a file
>        that is not a multi??? ple of the page size, the remaining memory
>        is zeroed when mapped, and writes to that region are not
>        written out to the file.  The effect of changing the size of
>        the underlying file of a mapping on the pages that correspond
>        to added or removed regions of the file is unspecified.
> 
> Previously in Linux 2.2 (or was it 2.0; my memory is a bit fuzzy about
> when we unified the buffer and page caches), when we copied the data
> from the page cache to the buffer cache, we stopped at EOF.  This
> implies that if the program modified the portion of the page mapped
> beyond EOF, it would remain modified until the page was released and
> the page was dropped from the page cache.
> 
> Now, when we call writepage() --- assuming the file system wasn't
> buggy --- the bytes after EOF will get cleared.  If the user doesn't
> call msync(), when this happens is unpredictable to the userspace
> program, since it happens when writeback daemons decide to write back
> the data.

This is exacly what we concluded when we were fixing the testacase (I
talked about this I think with Jan Kara and Michal Hocko). And the
result was to add the msync() to the testcase. We also agreed that
fixing this for tmpfs is not worth the effort although when interpreting
POSIX strictly it should work with shm memory as well.

-- 
Cyril Hrubis
chrubis@...e.cz
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html