[strace/strace] make check fails with -j16 and higher (#74)

Dmitry V. Levin notifications at github.com
Sun Dec 8 18:33:01 UTC 2019

On Thu, Jul 26, 2018 at 01:32:15AM -0700, Jiri Slaby wrote:
> Running
> ```
> for aa in `seq 1 120`; do ./tests/bpf-obj_get_info_by_fd >> log & done
> ```
> results in *no* `EPERM`. It must be some other test interfering. Looking into the bpf code, `EPERM` is returned when we are over `RLIMIT_MEMLOCK`. And this `BPF_MAP_CREATE` only adds few bytes to that limit AFAIU (`value_size=8` × `max_entries=1` + some constant, the sum rounded to `PAGE_SIZE`, i.e. exactly one page). And `ulimit -l` is set 64 k (which is not that much, I agree, looking where is this limit from; my machine has set that to 16 M). 

Finally, I've managed to reproduce this issue:

$ uname -a
Linux ppc64le-test.fedorainfracloud.org 5.2.16-200.fc30.ppc64le #1 SMP Thu Sep 19 15:47:22 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

$ ulimit -l

$ for n in `seq 1 5`; do i=1; while ./bpf-obj_get_info_by_fd; do i="$(($i+1))"; done &>/dev/null; echo $i; done

Yes, these were consequent invocations with no concurrency whatsoever.
What can I say?  It's definitely a kernel bug that has to be addressed
on the kernel side.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20191208/3dd4f1d0/attachment.html>

More information about the Strace-devel mailing list