code review 6997049: runtime/linux: die more gracefully when locked mem quot... (issue 6997049)

33 views
Skip to first unread message

sebastien...@gmail.com

unread,
Dec 23, 2012, 5:16:12 AM12/23/12
to golan...@googlegroups.com, re...@codereview-hr.appspotmail.com
Reviewers: golang-dev_googlegroups.com,

Message:
Hello golan...@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go/


Description:
runtime/linux: die more gracefully when locked mem quota is overrun.

Used to then die on a nil pointer situation. Most Linux standard setups
are rather restrictive regarding the default amount of lockable memory.

Please review this at https://codereview.appspot.com/6997049/

Affected files:
M src/pkg/runtime/mem_linux.c


Index: src/pkg/runtime/mem_linux.c
===================================================================
--- a/src/pkg/runtime/mem_linux.c
+++ b/src/pkg/runtime/mem_linux.c
@@ -10,6 +10,7 @@

enum
{
+ EAGAIN = 11,
ENOMEM = 12,
_PAGE_SIZE = 4096,
};
@@ -63,6 +64,10 @@
runtime·printf("if you're running SELinux, enable execmem for this
process.\n");
runtime·exit(2);
}
+ if(p == (void*)EAGAIN) {
+ runtime·printf("runtime: mmap: too much locked memory (check
rlimits).\n");
+ runtime·exit(2);
+ }
return nil;
}
return p;


minu...@gmail.com

unread,
Dec 23, 2012, 8:35:22 AM12/23/12
to sebastien...@gmail.com, golan...@googlegroups.com, re...@codereview-hr.appspotmail.com

https://codereview.appspot.com/6997049/diff/2002/src/pkg/runtime/mem_linux.c
File src/pkg/runtime/mem_linux.c (right):

https://codereview.appspot.com/6997049/diff/2002/src/pkg/runtime/mem_linux.c#newcode68
src/pkg/runtime/mem_linux.c:68: runtime·printf("runtime: mmap: too much
locked memory (check rlimits).\n");
check 'ulimit -l'?

https://codereview.appspot.com/6997049/

Russ Cox

unread,
Dec 23, 2012, 2:22:01 PM12/23/12
to Sébastien Paolacci, golang-dev, minux ma, re...@codereview-hr.appspotmail.com
How can this happen?

sebastien...@gmail.com

unread,
Dec 23, 2012, 2:52:28 PM12/23/12
to golan...@googlegroups.com, minu...@gmail.com, r...@golang.org, re...@codereview-hr.appspotmail.com
On 2012/12/23 19:22:02, rsc wrote:
> How can this happen?

For exemple, by using `syscall.Mlockall(syscall.MCL_FUTURE)' with an
under-provisioned enough "ulimit -l". That's (at least) what happened to
me.

mmap's describe the situation as "EAGAIN: The file has been locked, or
too much memory has been locked". I can't really get why they choose
that error code, but it really does happen..

Sebastien

https://codereview.appspot.com/6997049/

sebastien...@gmail.com

unread,
Dec 23, 2012, 2:56:08 PM12/23/12
to golan...@googlegroups.com, minu...@gmail.com, r...@golang.org, re...@codereview-hr.appspotmail.com

https://codereview.appspot.com/6997049/diff/2002/src/pkg/runtime/mem_linux.c
File src/pkg/runtime/mem_linux.c (right):

https://codereview.appspot.com/6997049/diff/2002/src/pkg/runtime/mem_linux.c#newcode68
src/pkg/runtime/mem_linux.c:68: runtime·printf("runtime: mmap: too much
locked memory (check rlimits).\n");
On 2012/12/23 13:35:22, minux wrote:
> check 'ulimit -l'?

Done.

https://codereview.appspot.com/6997049/

minu...@gmail.com

unread,
Dec 23, 2012, 2:59:58 PM12/23/12
to sebastien...@gmail.com, golan...@googlegroups.com, r...@golang.org, re...@codereview-hr.appspotmail.com
LGTM.
Will wait for Russ's comment.

https://codereview.appspot.com/6997049/
Reply all
Reply to author
Forward
0 new messages