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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 8 Feb 2011 13:26:57 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	martin capitanio <m@...itanio.org>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: mmap, the language go, problems with the linux kernel

On Tue, 08 Feb 2011 13:37:58 +0100
martin capitanio <m@...itanio.org> wrote:

> There popped up a serious problem by implementing a fast memory
> management for the language go. Maybe some experienced kernel hacker
> could join the discussion and help to find the best linux solution for
> the "mmap fiasco" problem.
> 
> https://groups.google.com/forum/#!msg/golang-dev/EpUlHQXWykg/LN2o9fV6R3wJ
> 
> Thanks (in behave of all linux go users:),

I don't actually see a problem.

Linux implements virtual address space limits, and enforces them. The go
language stuff wants to allocate huge amounts of virtual space so you
need to tell the OS you want to allow it to do crazy stuff, which you can
do so. But virtual address space is not free - it has to be tracked and
if the application suddenely tries to fill all of it what will happen ?

You'll hit problems if the kernel is running with vm overcommit disabled
(as well configured servers do),

There are of course ways and means - you can provide your own mmap to
override the libc one for example and manage the address space yourself -
within limits by allocating addresses and doing the syscall giving an
address request.

You'll be ok I suspect on Linux on x86 but there are platforms with very
complicated aliasing rules where the OS tries very hard to map certain
things at certain addresses to avoid cache aliasing work and big slow
downs. There are good reasons why mmap works the way it does.

Alan


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