linux-kernel - Re: mmap: is default non-populating behavior stable?

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: <1225814820.7803.1672.camel@twins>
Date:	Tue, 04 Nov 2008 17:07:00 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Chris Friesen <cfriesen@...tel.com>
Cc:	Rik van Riel <riel@...hat.com>,
	"Eugene V. Lyubimkin" <jackyf.devel@...il.com>,
	linux-kernel@...r.kernel.org, linux-mm <linux-mm@...ck.org>,
	hugh <hugh@...itas.com>
Subject: Re: mmap: is default non-populating behavior stable?

On Tue, 2008-11-04 at 09:56 -0600, Chris Friesen wrote:
> Rik van Riel wrote:
> > Peter Zijlstra wrote:
> 
> >> The exact interaction of mmap() and truncate() I'm not exactly clear on.
> > 
> > Truncate will reduce the size of the mmaps on the file to
> > match the new file size, so processes accessing beyond the
> > end of file will get a segmentation fault (SIGSEGV).
> 
> I suspect Peter was talking about using truncate() to set the initial 
> file size, effectively increasing rather than reducing it.

I was thinking of truncate() on an already mmap()'ed region, either
increasing or decreasing the size so that part of the mmap becomes
(in)valid.

I'm not sure how POSIX speaks of this.

I think Linux does the expected thing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/