From: Cyril Hrubis <chrubis@suse.cz>
To: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <jakub.kicinski@netronome.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, ltp@lists.linux.it,
Richard Palethorpe <rpalethorpe@suse.de>
Subject: EPERM failures for repeated runs
Date: Tue, 22 Oct 2019 16:36:04 +0200 [thread overview]
Message-ID: <20191022143604.GA18468@rei> (raw)
Hi!
Lately we started to write BPF testcases for LTP and after writing a
first few tests we found out that running more than a few in a row
causes them to fail with EPERM.
The culprit is deferred cleanup of the bpf maps that are locked in the
memory, see:
http://lists.linux.it/pipermail/ltp/2019-August/013349.html
We worked around that by bumping the limit for the tests in:
https://github.com/linux-test-project/ltp/commit/85c4e886b357f7844f6ab8ec5719168c38703a76
But it looks like this value will not scale, especially for
architectures that have larger than 4k pages, running four BPF tests in
a row still fails on ppc64le even with the increased limit.
Perhaps I'm naive but can't we check, in the kernel, if there is
deferred cleanup in progress if we fail to lock memory for a map and
retry once it's done?
Or is this intended behavior and should we retry on EPERM in userspace?
--
Cyril Hrubis
chrubis@suse.cz
reply other threads:[~2019-10-22 14:36 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191022143604.GA18468@rei \
--to=chrubis@suse.cz \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=hawk@kernel.org \
--cc=jakub.kicinski@netronome.com \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=netdev@vger.kernel.org \
--cc=rpalethorpe@suse.de \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).