linux-kernel - Re: [PATCHv2 0/2] remap_file

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: <20140508160205.A0EC7E009B@blue.fi.intel.com>
Date:	Thu,  8 May 2014 19:02:05 +0300 (EEST)
From:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To:	Armin Rigo <arigo@...es.org>
Cc:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	peterz@...radead.org, mingo@...nel.org
Subject: Re: [PATCHv2 0/2] remap_file_pages() decommission

Armin Rigo wrote:
> Hi everybody,
> 
> Here is a note from the PyPy project (mentioned earlier in this
> thread, and at https://lwn.net/Articles/587923/ ).
> 
> Yes, we use remap_file_pages() heavily on the x86-64 architecture.
> However, the individual calls to remap_file_pages() are not
> performance-critical, so it is easy to switch to using multiple
> mmap()s.  We need to perform more measurements to know exactly what
> the overhead would be, in terms notably of kernel memory.
> 
> However, an issue with that approach is the upper bound on the number
> of VMAs.  By default, it is not large enough.  Right now, it is
> possible to remap say 10% of the individual pages from an anonymous
> mmap of multiple GBs in size; but doing so with individual calls to
> mmap hits this arbitrary limit.

The limit is not totaly random. We use ELF format for coredumps and ELF has
limitation (16-bit field) on number of sections it can store.

With ELF extended numbering we can bypass 16-bit limit, but some userspace
can be surprised by that.

> I have no particular weight to give
> for or against keeping remap_file_pages() in the kernel, but if it is
> removed or emulated, it would be a plus if the programs would run on a
> machine with the default configuration --- i.e. if you remove or
> emulate remap_file_pages(), please increase the default limit as well.

It's fine to me. Andrew?

-- 
 Kirill A. Shutemov
--
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/