All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <ast@plumgrid.com>
To: Daniel Wagner <daniel.wagner@bmw-carit.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tom Zanussi <tom.zanussi@linux.intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Wang Nan <wangnan0@huawei.com>
Subject: Re: latency histogram with BPF
Date: Fri, 12 Jun 2015 10:17:15 -0700	[thread overview]
Message-ID: <557B141B.3000704@plumgrid.com> (raw)
In-Reply-To: <557AEDAD.2060507@bmw-carit.de>

On 6/12/15 7:33 AM, Daniel Wagner wrote:
> On 06/12/2015 08:12 AM, Daniel Wagner wrote:
>> On 06/12/2015 12:08 AM, Alexei Starovoitov wrote:
>>> On 6/11/15 12:25 AM, Daniel Wagner wrote:
>>> If you have any suggestions on where to look, I'm all ears.
>>> My stack traces look like:
>>> Running with 10*40 (== 400) tasks.
>>> [   12.032571] kernel BUG at ../mm/slub.c:3413!
>
> I hit this as well.
>
> After looking and playing around for while I think I found the source of
> the problem: The path from the BPF program into the hash table code is
> triggering the crash.
>
> Attaching kprobes to trace_preempt_[on|off] works fine. Empty BPF
> programs connected to the probes is no problem as well. So I changed the
> BPF program to use only arrays instead of hash tables. No crash anymore.

yes. I've tried that too. arrays work fine indeed.

> I suspect the hash table code will call trace_preempt_[off|on]
> eventually and that is not going to fly.

The recursive calls into bpf programs are detected and prevented.
That's ok. I've tested attaching kprobes to kmalloc/kfree and
from the program do hash_map->update_elem->kmalloc which triggers
recursive call into the same program. All works fine.
There is something else here.


  reply	other threads:[~2015-06-12 17:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-11  7:25 latency histogram with BPF Daniel Wagner
2015-06-11 22:08 ` Alexei Starovoitov
2015-06-12  6:12   ` Daniel Wagner
2015-06-12 14:33     ` Daniel Wagner
2015-06-12 17:17       ` Alexei Starovoitov [this message]
2015-06-15  9:03         ` Daniel Wagner
2015-06-12  6:58 ` Wangnan (F)
2015-06-12 17:21   ` Alexei Starovoitov

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=557B141B.3000704@plumgrid.com \
    --to=ast@plumgrid.com \
    --cc=daniel.wagner@bmw-carit.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tom.zanussi@linux.intel.com \
    --cc=wangnan0@huawei.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 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.