All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Famulla-Conrad <cfamullaconrad@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v4 0/4] Basic eBPF tests
Date: Wed, 28 Aug 2019 12:15:02 +0200	[thread overview]
Message-ID: <1566987302.6539.21.camel@suse.de> (raw)
In-Reply-To: <2001459109.8602383.1566978371578.JavaMail.zimbra@redhat.com>

On Wed, 2019-08-28 at 03:46 -0400, Jan Stancek wrote:
> ----- Original Message -----
> > On Mon, 2019-08-26 at 10:29 -0400, Jan Stancek wrote:
> > > 
> > > ----- Original Message -----
> > > > I've ended up playing with the patchset and fixed a few loose
> > > > ends
> > > > on
> > > > the map test and as I had the code at hand I decided to send v4
> > > > instead
> > > > of pointing out the mistakes in a review.
> > > > 
> > > > There were numerous small changes for the map test:
> > > > 
> > > > * Make sure the key buffer is sized exactly for the content
> > > > 
> > > > * Initialized the array/hash element value in test setup
> > > > 
> > > > * Made the code flow a bit more obvious, it was hard to tell
> > > > which
> > > >   part was run for n == 0 and which for n == 1
> > > > 
> > > > Also it looks that for me the test that loads the eBPF program
> > > > ends
> > > > up
> > > > with EPERM randomly at about 10th iteration both as
> > > > unpriviledged
> > > > and
> > > > priviledged user, which is really strange.
> > > 
> > > There's one EPERM I can reproduce reliably with bpf_map test,
> > > which
> > > appears
> > > to originate from "bpf_charge_memlock".
> > > 
> > > There's a deferred component to map freeing, and unchange appears
> > > to
> > > be part of it:
> > >   bpf_map_release
> > >     bpf_map_put
> > >       INIT_WORK(&map->work, bpf_map_free_deferred);
> > >         (deferred) bpf_uncharge_memlock
> > > 
> > > When I lower max locked memory, it's easy to hit:
> > > # ulimit  -l 128; ./bpf_map01 -i 100
> > > ...
> > > bpf_map01.c:52: CONF: bpf() requires CAP_SYS_ADMIN on this
> > > system:
> > > EPERM
> > > 
> > > Can you try bumping max locked memory to some high value and
> > > check
> > > if that helps your case?
> > 
> > # for i in 64 128 256 1024; do
> >     echo $i;
> >     ulimit -l $i;
> >     ./bpf_prog01 -i 100 |& grep -P 'passed|CONF';
> > done
> > 
> > 64
> > CONF: bpf() requires CAP_SYS_ADMIN on this system: EPERM
> > passed   16
> > 
> > 128
> > CONF: bpf() requires CAP_SYS_ADMIN on this system: EPERM
> > passed   16
> > 
> > 256
> > CONF: bpf() requires CAP_SYS_ADMIN on this system: EPERM
> > passed   32
> > 
> > 1024
> > CONF: bpf() requires CAP_SYS_ADMIN on this system: EPERM
> > passed   192
> > 
> > 
> > Which produce almost the same results.
> > Same approach with `bpf_map01` differs a lot. Sometimes all pass,
> > sometimes none.
> 
> Seems to make difference for me on 5.2:
> 
> # cat bench.sh; sh bench.sh 
> for i in 128 256 512 1024 4096 65536; do
>         echo $i;
>         ulimit -l $i;
>         ./bpf_prog01 -i 100 |& grep -P 'passed|CONF';
>         sleep 4;
> done
> 
> 128
> bpf_prog01.c:114: CONF: bpf() requires CAP_SYS_ADMIN on this system:
> EPERM
> passed   32
> 256
> bpf_prog01.c:114: CONF: bpf() requires CAP_SYS_ADMIN on this system:
> EPERM
> passed   64
> 512
> bpf_prog01.c:114: CONF: bpf() requires CAP_SYS_ADMIN on this system:
> EPERM
> passed   128
> 1024
> passed   200
> 4096
> passed   200
> 65536
> passed   200
> 

I ran it again and now my results looks like yours...

  reply	other threads:[~2019-08-28 10:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-26 11:10 [LTP] [PATCH v4 0/4] Basic eBPF tests Cyril Hrubis
2019-08-26 11:10 ` [LTP] [PATCH v4 1/4] BPF: Essential headers for map creation Cyril Hrubis
2019-08-26 11:10 ` [LTP] [PATCH v4 2/4] BPF: Sanity check creating and updating maps Cyril Hrubis
2019-08-26 12:52   ` Jan Stancek
2019-09-02 14:05     ` Cyril Hrubis
2019-08-26 11:10 ` [LTP] [PATCH v4 3/4] BPF: Essential headers for a basic program Cyril Hrubis
2019-08-26 11:10 ` [LTP] [PATCH v4 4/4] BPF: Sanity check creating a program Cyril Hrubis
2019-08-26 16:05   ` Jan Stancek
2019-08-28  7:41   ` Clemens Famulla-Conrad
2019-08-26 14:29 ` [LTP] [PATCH v4 0/4] Basic eBPF tests Jan Stancek
2019-08-28  7:26   ` Clemens Famulla-Conrad
2019-08-28  7:46     ` Jan Stancek
2019-08-28 10:15       ` Clemens Famulla-Conrad [this message]
2019-09-02 14:55   ` Cyril Hrubis
2019-09-03  5:50     ` Jan Stancek
2019-09-03  8:58       ` Cyril Hrubis
2019-09-03  9:51         ` Jan Stancek

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=1566987302.6539.21.camel@suse.de \
    --to=cfamullaconrad@suse.de \
    --cc=ltp@lists.linux.it \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.