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

[Dmitry V. Levin]

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
64

$ 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
3
1448
484
1139
903

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:
https://github.com/strace/strace/issues/74#issuecomment-562978462
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20191208/3dd4f1d0/attachment.html>