From: Sebastian Sewior <bigeasy@linutronix.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Clark Williams <williams@redhat.com>,
David Miller <davem@davemloft.net>,
daniel@iogearbox.net, bpf@vger.kernel.org, ast@kernel.org,
kafai@fb.com, songliubraving@fb.com, yhs@fb.com,
Peter Zijlstra <peterz@infradead.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: [PATCH] BPF: Disable on PREEMPT_RT
Date: Fri, 18 Oct 2019 14:43:37 +0200 [thread overview]
Message-ID: <20191018124337.eycbrt25jmxfmar6@linutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1910181038130.1869@nanos.tec.linutronix.de>
On 2019-10-18 10:46:01 [+0200], Thomas Gleixner wrote:
> Clark,
>
> On Thu, 17 Oct 2019, Clark Williams wrote:
> > On Thu, 17 Oct 2019 23:54:07 +0200 (CEST)
> > Thomas Gleixner <tglx@linutronix.de> wrote:
> > > #2) BPF does allocations in atomic contexts, which is a dubious decision
> > > even for non RT. That's related to #1
> >
> > I guess my question here is, are the allocations done on behalf of an about-to-run
> > BPF program, or as a result of executing BPF code? Is it something we might be able
> > to satisfy from a pre-allocated pool rather than kmalloc()? Ok, I need to go dive
> > into BPF a bit deeper.
>
> Sebastion?
The data structures use raw_spinlock_t as protection. This is where the
atomic context is from.
lpm_trie with trie_update_elem() allocates a new element while holding
the lock. I tried to make it a spinlock_t which wouldn't have the
problem but then
https://lore.kernel.org/bpf/4150a0db-18f9-aa93-cdb4-8cf047093740@iogearbox.net/
pointed out that it has been made raw_spinlock_t due to kprobe on -RT.
Commit ac00881f92210 ("bpf: convert hashtab lock to raw lock") was
"okay" back then (according to Steven Rostedt) but it got wrong with the
memory allocation which came in later.
In order to tackle one thing at a time, I would say that kprobe isn't
our biggest concern…
> tglx
Sebastian
next prev parent reply other threads:[~2019-10-18 12:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 9:05 [PATCH] BPF: Disable on PREEMPT_RT Sebastian Andrzej Siewior
2019-10-17 14:53 ` Daniel Borkmann
2019-10-17 15:40 ` Sebastian Andrzej Siewior
2019-10-17 17:25 ` David Miller
2019-10-17 21:54 ` Thomas Gleixner
2019-10-17 22:13 ` David Miller
2019-10-17 23:50 ` Thomas Gleixner
2019-10-17 23:27 ` Alexei Starovoitov
2019-10-18 0:22 ` Thomas Gleixner
2019-10-18 5:52 ` Alexei Starovoitov
2019-10-18 11:28 ` Thomas Gleixner
2019-10-18 12:48 ` Sebastian Sewior
2019-10-18 23:05 ` Alexei Starovoitov
2019-10-20 9:06 ` Thomas Gleixner
2019-10-22 1:43 ` Alexei Starovoitov
2019-10-18 2:49 ` Clark Williams
2019-10-18 4:57 ` David Miller
2019-10-18 5:54 ` Alexei Starovoitov
2019-10-18 8:38 ` Thomas Gleixner
2019-10-18 12:49 ` Clark Williams
2019-10-18 8:46 ` Thomas Gleixner
2019-10-18 12:43 ` Sebastian Sewior [this message]
2019-10-18 12:58 ` Clark Williams
2019-10-17 22:11 ` Thomas Gleixner
2019-10-17 22:23 ` David Miller
2019-10-17 17:26 ` David Miller
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=20191018124337.eycbrt25jmxfmar6@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=acme@redhat.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kafai@fb.com \
--cc=peterz@infradead.org \
--cc=songliubraving@fb.com \
--cc=tglx@linutronix.de \
--cc=williams@redhat.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).