linux-kernel - Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 27 Dec 2006 21:32:27 +0900
From:	"Jari Sundell" <sundell.software@...il.com>
To:	"Linus Torvalds" <torvalds@...l.org>
Cc:	"Nick Piggin" <nickpiggin@...oo.com.au>,
	"Andrei Popa" <andrei.popa@...eo.ro>,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	"David S. Miller" <davem@...emloft.net>,
	"Andrew Morton" <akpm@...l.org>,
	"Gordon Farquharson" <gordonfarquharson@...il.com>,
	"Martin Michlmayr" <tbm@...ius.com>,
	"Hugh Dickins" <hugh@...itas.com>,
	"Arjan van de Ven" <arjan@...radead.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

On 12/27/06, Linus Torvalds <torvalds@...l.org> wrote:
<snip>
>  - It never uses mprotect on the shared mappings, but it _does_ do:
>         "mincore()" - but the return values don't much matter (it's used
>                       as a heuristic on which parts to hash, apparently)
>
>                       I double- and triple-checked this one, because I
>                       did make changes to "mincore()", but those didn't go
>                       into the affected kernels anyway (ie they are not in
>                       plain 2.6.19, nor in 2.6.18.3 either)

Correct, mincore is only used to check if it should delay the hash checking.

>         "madvise(MADV_WILLNEED)"
>         "msync(MS_ASYNC)" (or MS_SYNC if you use a command line flag)
>         "munmap()" of course
>
>  - it never seems to mix mmap() and write() - it does _only_ mmap.
>
>  - it seems to mmap/munmap the shared files in nice 64-page chunks, all
>    64-page aligned in the file (ie it does NOT create one big mapping, it
>    has some kind of LRU of thse 64-page chunks). The only exception being
>    the last chunk, which it maps byte-accurate to the size.

The length of the chunks is only page aligned on single file torrents,
not so on multi-file torrents. I've attached a patch for rtorrent that
will extend the length to the page boundary.

>  - I haven't checked whether it only ever has the same chunk mapped once
>    at a time.

This should be the case, but two mapped chunks may share a page,
sometimes with different r/w permissions.

Jari Sundell

Download attachment "extend_mapping.diff" of type "application/octet-stream" (1887 bytes)