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]
Date:	Mon, 03 Nov 2008 17:49:41 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	"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?

Peter Zijlstra wrote:
> On Mon, 2008-11-03 at 23:57 +0200, Eugene V. Lyubimkin wrote:
>> Hello kernel hackers!
>>
>> The current implementation of mmap() in kernel is very convenient.
>> It allows to mmap(fd) very big amount of memory having small file as back-end.
>> So one can mmap() 100 MiB on empty file, use first 10 KiB of memory, munmap() and have
>> only 10 KiB of file at the end. And while working with memory, file will automatically be
>> grown by read/write memory requests.
>>
>> Question is: can user-space application rely on this behavior (I failed to find any
>> documentation about this)?
>>
>> TIA and please CC me in replies.
> 
> mmap() writes past the end of the file should not grow the file if I
> understand things write, but produce a sigbus (after the first page size
> alignment).

Indeed, faulting beyond the end of file returns a SIGBUS,
see these lines in mm/filemap.c:filemap_fault():

         size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) >> 
PAGE_CACHE_SHIFT;
         if (vmf->pgoff >= size)
                 return VM_FAULT_SIGBUS;

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

> The safe way to do things is to first create your file of at least the
> size you mmap, using truncate. This will create a sparse file, and will
> on any sane filesystem not take more space than its meta data.
> 
> Thereafter you can fill it with writes to the mmap.

Agreed.

-- 
All Rights Reversed
--
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/

Powered by blists - more mailing lists