linux-kernel - Re: 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]

Date:	Sun, 25 May 2014 19:19:37 -0500
From:	Jeff Smith <jsmith.lkml@...il.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Kenny Simpson <theonetruekenny@...il.com>,
	Michal Hocko <mhocko@...e.cz>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Dave Jones <davej@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: remap_file_pages() use

On Mon, May 19, 2014 at 9:38 AM, Christoph Hellwig <hch@...radead.org> wrote:
> On Mon, May 19, 2014 at 05:35:40PM +0300, Kirill A. Shutemov wrote:
>> >From functional POV, emulation *should* be identical to original
>> remap_file_pages(), but slower. It would be nice, if you test it early.
>>
>> It's not clear yet how long emulation will be there.
>
> Stop right there.  We found out about two real life users of
> remap_file_pages() already, without even committing the patches to warn
> about using it to any tree.
>
> I think at this point the whole idea of removing the API should be dead
> on the floor, as we do not needlessly break userspace programs.
>
> If we can get rid of the ugly guts and provide a good enough emulation
> that the user won't cry I'd love to get rid of this cruft, but even
> that doesn't look certain yet.

Sorry for being late to the party, but I just noticed this proposal
via the LWN summary byline.

I wanted to comment that Kenny's use case is (I believe) quite
widespread. I've used the technique since ~2008, and I've come across
other people in subsequent jobs who independently developed the same
technique. Mirrored mapping is absolutely required by several
independent proprietary platforms I'm aware of, and remap_file_pages()
has historically been the only sane way to accomplish this. (i.e.,
shm_open(), mmap(NULL, 2^(n+1) pages), remap_file_pages() on 2nd
half).

It may not be individuals who are involved in the kernel development
scene to any great extent, but I am sure that remap_file_pages() being
deprecated would seriously piss off a lot of individuals. The pattern
has even had a section in the Wikipedia article for quite some time:
http://en.wikipedia.org/wiki/Circular_buffer#Mirroring

It would be most preferable from a user standpoint to keep the
existing system intact, but failing that, a reservation API would need
to be created (possibly a MAP_RESERVE flag) that would set aside a
region that could only be subsequently mapped via explicit
address-requesting mmap() calls.

Thanks for any consideration of these concerns.
--Jeff
--
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/