linux-kernel - Re: [Qemu-devel] [PATCH 0/4] madvise(MADV_USERFAULT) & sys_remap_anon

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] [day] [month] [year] [list]

Date:	Tue, 7 May 2013 14:19:54 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Andrew Jones <drjones@...hat.com>
Cc:	qemu-devel@...gnu.org, linux-kernel@...r.kernel.org,
	Anthony Liguori <aliguori@...ibm.com>,
	Orit Wasserman <owasserm@...hat.com>,
	Juan Quintela <quintela@...hat.com>,
	Hugh Dickins <hughd@...gle.com>,
	Isaku Yamahata <yamahata@...inux.co.jp>,
	Mel Gorman <mgorman@...e.de>,
	Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [Qemu-devel] [PATCH 0/4] madvise(MADV_USERFAULT) &
 sys_remap_anon_pages()

On Tue, May 07, 2013 at 01:38:10PM +0200, Andrew Jones wrote:
> What about instead of adding a new syscall (remap_anon_pages) to
> instead extend mremap with new flags giving it a strict mode?

I actually thought about this and it's a very interesting argument.

When I thought about it, I felt the problem was that we won't know
until we did some work (at least until reaching _each_ individual page
structure of every page mapped in the mremapped range) if we can avoid
the vma mangling or not. So then remap_anon_pages should be more
efficient because it will just error out if strict mode is not
possible, it won't need to search all page structures before it know
if it has to do the vma mangling or not.

It likely is simpler too than to try to teach mremap to do both things
after checking which one it can do.

Also, the same argument could be made about remap_file_pages too.

But it's still an interesting point, let's see what others thinks
about it.
--
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/