[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180925141551.GE10209@port70.net>
Date: Tue, 25 Sep 2018 16:15:52 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Rabbitstack <rabbitstack7@...il.com>
Subject: Re: setrlimit hangs the process
* Rabbitstack <rabbitstack7@...il.com> [2018-09-25 14:59:45 +0200]:
> I'm using the latest golang:alpine Docker image to produce a
> statically-linked Go binary. Even though I'm able to build the binary, when
> I run it the process gets stuck during ebpf program loading. I've
> investigated a bit and found the root cause is the call to setrlimit (this
> is the offending line
>
> https://github.com/iovisor/gobpf/blob/2e314be67b1854ad226f012f08a984e0e89b6da9/elf/elf.go#L105).
> Are you aware of such behaviour in musl?
>
well you could have described what goes wrong in more detail
(error message, strace output, target platform, are you root, ...)
i assume you are not running this on mips (since there is no
alpine docker image for mips), which has the issue of
SYSCALL_RLIM_INFINITY != RLIM_INFINITY
the kernel side value is different from userspace so musl
has to translate the value which may go wrong.
nor on x32 (which may have various issues with the raw
syscalls both in the go code and c code).
increasing rlimit is not allowed by default, so you have to
ensure you have permissions, musl should have no special
behaviour with respect to RLIMIT_MEMLOCK, so it's more likely
that you just don't have bpf and setrlimit permissions.
instead of using a complex system like go + c code + elf loader,
try a minimal c program to see if the bpf syscall succeeds at
all in your docker environment.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
