Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp1395713ybm; Wed, 22 May 2019 23:49:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqwT/Dsgv+ZJZOCzK8/xw5+AJ0y4kxoenXt6gul41bpkt/hbnwP8iWcVSOk2Jl/duzMnLzed X-Received: by 2002:a65:4c86:: with SMTP id m6mr93862653pgt.75.1558594184073; Wed, 22 May 2019 23:49:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558594184; cv=none; d=google.com; s=arc-20160816; b=i2Uiqypb3OrUsKLERnqBqKFlGk79Jkc8qFWUhXIGSmqdTx89LzJLFUJ+996xhrqAQF nDSa+p3CYndBHHgJXBZJL0Jg0Xad+I40wnA6ujpZRW6WndbISXDXF8hM3La6JWjbYwwr ZBQIe38GtlOw+Y2iibuMjkH2NMoH/1JCavOq+VA3l6UgA+FUDaGtZbme5L0cWEs4l2t2 nO7Cl4EU2IAWHsD2EjYM/XhJBb4Aah61lEmcEXrAQXmf7PtUSZ2gFqKPHoNVct1FuCUh Z1halW337+xKqX4mCm9vsFZOjqea9koLsLk4KtbFRVZkojm+AFKdSY4J3/SckPTsZeSl eKow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=4uQOlqrYqfub5rCDYjNxrdl9e2pbaXo8ryrZOfrvSAQ=; b=UzajYeTx1NIDIk2NImIy4CpQN3Z+6Y8I4z+0lLyqQvmH7cEPN5jh4kTwvEpiYmw1o9 PXMH+ksx1qI/tJNU25NkxEQyTmLnPjS0cMsTlG6dNs+vieE3HemwtPrLotzWP8af5HL/ aek6H6EWAcbyOBnGKr8aXjo3CEP/tB0QQrYJUED/PuoEySE9PanqF5uHXKdMX2D6FIQq Gc+4OKJtTKeF+NcgkdGIiXex0SyBzyjY/0jjv5TNnasFr/x818OSu7Z3+mQzLAjpn3fR L8eFIPqm+r67Sd3P/Vy6fznezOkCR63Ak442TTMQY7HD+dKtSPZUAK3duGJOFJZVDD3p 6vag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z23si29076942pfa.277.2019.05.22.23.49.28; Wed, 22 May 2019 23:49:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726363AbfEWGsY (ORCPT + 99 others); Thu, 23 May 2019 02:48:24 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:34629 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725814AbfEWGsX (ORCPT ); Thu, 23 May 2019 02:48:23 -0400 Received: by mail-io1-f65.google.com with SMTP id g84so3993714ioa.1 for ; Wed, 22 May 2019 23:48:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4uQOlqrYqfub5rCDYjNxrdl9e2pbaXo8ryrZOfrvSAQ=; b=ewhI6BqWDi7RHeJtsMHtO/HHLdB04CQ/DVW6wQnvOyFQdFUq21A0TbOQ+xfOM4fEyF s9ndptTx/p7u0QGbl4tO/DKCxbSP+zIbnw5ESmCv7vIvI9mSNEj5Hls+RWaigCY+Lp1u mQgfjjWjWRWlHeDvMWR9qWn7urwPEXp5isuNDjq8h6j31URE7G4cIK7SS8LxJ/hS5vzT gvcXRB3sM4DTDy2en8CF1eI/n5o2lOAalvFg1OqYIT7xSf2XNYnP+qaWXZdp8AyKr7Gi QIVFFCoLhD8y1HtHGuoEeLiEZ3oEJ4fx0/kLx9fEXaBYMsOY5aU/aIOZkNSLX7Sr7EDj woGg== X-Gm-Message-State: APjAAAUgEV4zw2gXLJg056pRAqTttRNffVP6PJmEx9H7zB/O1RqOUQL2 jjXlmVG0wJFN+WEJYR38zAC3a3gWJaYDL6MtcI6Aew== X-Received: by 2002:a5d:9c85:: with SMTP id p5mr33369424iop.13.1558594103032; Wed, 22 May 2019 23:48:23 -0700 (PDT) MIME-Version: 1.0 References: <3CD3EE63-0CD2-404A-A403-E11DCF2DF8D9@fb.com> <20190517074600.GJ2623@hirez.programming.kicks-ass.net> <20190517081057.GQ2650@hirez.programming.kicks-ass.net> <20190517091044.GM2606@hirez.programming.kicks-ass.net> <20190522140233.GC16275@worktop.programming.kicks-ass.net> <20190522174517.pbdopvookggen3d7@treble> <20190522234635.a47bettklcf5gt7c@treble> In-Reply-To: <20190522234635.a47bettklcf5gt7c@treble> From: Kairui Song Date: Thu, 23 May 2019 14:48:11 +0800 Message-ID: Subject: Re: Getting empty callchain from perf_callchain_kernel() To: Josh Poimboeuf Cc: Alexei Starovoitov , Peter Zijlstra , Song Liu , lkml , Kernel Team , Alexei Starovoitov , Daniel Borkmann , "bpf@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 23, 2019 at 7:46 AM Josh Poimboeuf wrote: > > On Wed, May 22, 2019 at 12:45:17PM -0500, Josh Poimboeuf wrote: > > On Wed, May 22, 2019 at 02:49:07PM +0000, Alexei Starovoitov wrote: > > > The one that is broken is prog_tests/stacktrace_map.c > > > There we attach bpf to standard tracepoint where > > > kernel suppose to collect pt_regs before calling into bpf. > > > And that's what bpf_get_stackid_tp() is doing. > > > It passes pt_regs (that was collected before any bpf) > > > into bpf_get_stackid() which calls get_perf_callchain(). > > > Same thing with kprobes, uprobes. > > > > Is it trying to unwind through ___bpf_prog_run()? > > > > If so, that would at least explain why ORC isn't working. Objtool > > currently ignores that function because it can't follow the jump table. > > Here's a tentative fix (for ORC, at least). I'll need to make sure this > doesn't break anything else. > > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c > index 242a643af82f..1d9a7cc4b836 100644 > --- a/kernel/bpf/core.c > +++ b/kernel/bpf/core.c > @@ -1562,7 +1562,6 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack) > BUG_ON(1); > return 0; > } > -STACK_FRAME_NON_STANDARD(___bpf_prog_run); /* jump table */ > > #define PROG_NAME(stack_size) __bpf_prog_run##stack_size > #define DEFINE_BPF_PROG_RUN(stack_size) \ > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > index 172f99195726..2567027fce95 100644 > --- a/tools/objtool/check.c > +++ b/tools/objtool/check.c > @@ -1033,13 +1033,6 @@ static struct rela *find_switch_table(struct objtool_file *file, > if (text_rela->type == R_X86_64_PC32) > table_offset += 4; > > - /* > - * Make sure the .rodata address isn't associated with a > - * symbol. gcc jump tables are anonymous data. > - */ > - if (find_symbol_containing(rodata_sec, table_offset)) > - continue; > - > rodata_rela = find_rela_by_dest(rodata_sec, table_offset); > if (rodata_rela) { > /* Hi Josh, this still won't fix the problem. Problem is not (or not only) with ___bpf_prog_run, what actually went wrong is with the JITed bpf code. For frame pointer unwinder, it seems the JITed bpf code will have a shifted "BP" register? (arch/x86/net/bpf_jit_comp.c:217), so if we can unshift it properly then it will work. I tried below code, and problem is fixed (only for frame pointer unwinder though). Need to find a better way to detect and do any similar trick for bpf part, if this is a feasible way to fix it: diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c index 9b9fd4826e7a..2c0fa2aaa7e4 100644 --- a/arch/x86/kernel/unwind_frame.c +++ b/arch/x86/kernel/unwind_frame.c @@ -330,8 +330,17 @@ bool unwind_next_frame(struct unwind_state *state) } /* Move to the next frame if it's safe: */ - if (!update_stack_state(state, next_bp)) - goto bad_address; + if (!update_stack_state(state, next_bp)) { + // Try again with shifted BP + state->bp += 5; // see AUX_STACK_SPACE + next_bp = (unsigned long *)READ_ONCE_TASK_STACK(state->task, *state->bp); + // Clean and refetch stack info, it's marked as error outed + state->stack_mask = 0; + get_stack_info(next_bp, state->task, &state->stack_info, &state->stack_mask); + if (!update_stack_state(state, next_bp)) { + goto bad_address; + } + } return true; For ORC unwinder, I think the unwinder can't find any info about the JITed part. Maybe if can let it just skip the JITed part and go to kernel context, then should be good enough. -- Best Regards, Kairui Song