Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp857974ybt; Fri, 26 Jun 2020 13:18:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz6AQUeTsuM405AEe0TXMl+cEA7x1i9F92xEHbtFnE9l2PtwEi6wh7oR+3qvuypbaRwUTG4 X-Received: by 2002:a17:907:2058:: with SMTP id pg24mr4379275ejb.79.1593202708641; Fri, 26 Jun 2020 13:18:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593202708; cv=none; d=google.com; s=arc-20160816; b=xhujLrWwTJxtiAc/3FPVmi58E/qO+urZEd6LOjy+pabq/mxH4Su5Rrbc7XbkqLeML+ oYNug3M7jWMRa+fQIvDYfnxM9DbqW8yKjjYAUU3qShf9HUlghVuIebId32kuKBLdwGh0 zgDjIGYl7gj0j28XI38tOoOKVGIvba6omP4ivkxtwZZ8GGGeyKalwFdBp51krZCssPSy z1h5p6Qzf1R84byGNPxTOiRFL4TO6+R7Ki5i8EqgeflQaqji3Q4ST3i25wy/Hs/SBiq8 FF4sbL2H+vdJ3dq+xzVCJfUgTA1OOzFRWzszCKY8FH0ENJXRslvPKpieAEItROJWMGf7 EY0w== 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:dkim-signature; bh=QIwB+ahDHPjVVdK6sMA4E03ym0nLZs4H6OPzI5/Dx1U=; b=W7PES7Kfj/e4MDnFl4741PqWR4daMM4m80IT76mvSk1J5/LQPq3//VC6p9CNggP4Au mPdIhYKcVAQPGbjqQK4EqSblWXhnJOJkKqGOYYHEPxE8763vvMjIL2Xi+ourE3d8+czs boRXsiFwKyNlTGkR6+SAr/0lS9yJEqfGE7IrwUYSRD/B5fKrAbItoyTKAvves9I+ftSm utf91GDK4kbQiljxgzH5vWNnSlVi6QCpcEhLsZx5qB7Nf2EyNic5/jDkxws0TdV6ELE3 iMMU1RgNQvMqAe6+0qlCdu+V/GtM2xvstP36Drn0J8Ikp31tnR5i4jNVKSnrDmeywtx1 KYJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=sRlyoOnV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c11si8964027edv.140.2020.06.26.13.18.04; Fri, 26 Jun 2020 13:18:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=sRlyoOnV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725838AbgFZURy (ORCPT + 99 others); Fri, 26 Jun 2020 16:17:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725780AbgFZURx (ORCPT ); Fri, 26 Jun 2020 16:17:53 -0400 Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3C83C03E979; Fri, 26 Jun 2020 13:17:53 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id x62so8451977qtd.3; Fri, 26 Jun 2020 13:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QIwB+ahDHPjVVdK6sMA4E03ym0nLZs4H6OPzI5/Dx1U=; b=sRlyoOnVvort/pt7VBpA2D1hOKmlklptjK0SxmcfqR4jzVT9rw3cvsoVXMqciTvt9b T3jqmVTOhFEflEv7YF+eVwMRHzh2xdS/jzYgdfq12PM/qpSCPoKFRAX4HY4DGYWoI/ML znmpMIMaX/TzwVPWrOWPae+lnHPCLktioVsUNhnbqFbIi10xRXCLAWE/rCVCuAW+gYKw 8rZPkt7vugAQ9y4VtGBcaxVvAF09XYZuYl5i6iYjBfy7IERYELNBKh24x3jXU9DAcT62 kb2dJG61WkvOCcIx9r8Czhb5RKXsPTMbanp89vRpOJTjZHnq0LXUudBbJB7zsZ5IR8AR WVDQ== 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=QIwB+ahDHPjVVdK6sMA4E03ym0nLZs4H6OPzI5/Dx1U=; b=JUN8pGbLWGxLmp1J6TeIXAeVNBbCJZ/VOQ2jnuU47jVNOm+kK/BaowRwetaSaqWpph qEZ03wMZyp4Mn4EoZU2PyZPlXDtVoU3QDlI3cablFKOjf66ULXx0fVlrl5u73sBgEjRN lSifbo0jZwK3GvUiF95rZ4kEqmv6qhE3j8Bl6Z17H0aIK8wkygY7rtAJZsQjDNsGkuEE akLP6eCqqA9fshu6CRtpGtHDWHMBm+H75uOJXuT/JPXdlJupe2WIVAxWbFzpQin5AC/k ZpZ9zTNJKoE0EkwZnusVzRFnaicustkDprXOwtM5cfW2gOzGWiEp2x1yp8nScJtwuepp mE4w== X-Gm-Message-State: AOAM530Ac3aCF55x4QkqsKhE+8vHp4WAAvl3qekUr3/NAh2gwXJHxDdl hfTz4ptX1S/t/q+U9YZ0ayrd7eNGL+CuE8F52BE= X-Received: by 2002:ac8:4714:: with SMTP id f20mr4578814qtp.141.1593202672978; Fri, 26 Jun 2020 13:17:52 -0700 (PDT) MIME-Version: 1.0 References: <20200626001332.1554603-1-songliubraving@fb.com> <20200626001332.1554603-3-songliubraving@fb.com> In-Reply-To: <20200626001332.1554603-3-songliubraving@fb.com> From: Andrii Nakryiko Date: Fri, 26 Jun 2020 13:17:41 -0700 Message-ID: Subject: Re: [PATCH v2 bpf-next 2/4] bpf: introduce helper bpf_get_task_stak() To: Song Liu Cc: bpf , Networking , open list , Peter Ziljstra , Alexei Starovoitov , Daniel Borkmann , Kernel Team , john fastabend , KP Singh 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, Jun 25, 2020 at 5:14 PM Song Liu wrote: > > Introduce helper bpf_get_task_stack(), which dumps stack trace of given > task. This is different to bpf_get_stack(), which gets stack track of > current task. One potential use case of bpf_get_task_stack() is to call > it from bpf_iter__task and dump all /proc//stack to a seq_file. > > bpf_get_task_stack() uses stack_trace_save_tsk() instead of > get_perf_callchain() for kernel stack. The benefit of this choice is that > stack_trace_save_tsk() doesn't require changes in arch/. The downside of > using stack_trace_save_tsk() is that stack_trace_save_tsk() dumps the > stack trace to unsigned long array. For 32-bit systems, we need to > translate it to u64 array. > > Signed-off-by: Song Liu > --- Looks great, I just think that there are cases where user doesn't necessarily has valid task_struct pointer, just pid, so would be nice to not artificially restrict such cases by having extra helper. Acked-by: Andrii Nakryiko > include/linux/bpf.h | 1 + > include/uapi/linux/bpf.h | 35 ++++++++++++++- > kernel/bpf/stackmap.c | 79 ++++++++++++++++++++++++++++++++-- > kernel/trace/bpf_trace.c | 2 + > scripts/bpf_helpers_doc.py | 2 + > tools/include/uapi/linux/bpf.h | 35 ++++++++++++++- > 6 files changed, 149 insertions(+), 5 deletions(-) > [...] > + /* stack_trace_save_tsk() works on unsigned long array, while > + * perf_callchain_entry uses u64 array. For 32-bit systems, it is > + * necessary to fix this mismatch. > + */ > + if (__BITS_PER_LONG != 64) { > + unsigned long *from = (unsigned long *) entry->ip; > + u64 *to = entry->ip; > + int i; > + > + /* copy data from the end to avoid using extra buffer */ > + for (i = entry->nr - 1; i >= (int)init_nr; i--) > + to[i] = (u64)(from[i]); doing this forward would be just fine as well, no? First iteration will cast and overwrite low 32-bits, all the subsequent iterations won't even overlap. > + } > + > +exit_put: > + put_callchain_entry(rctx); > + > + return entry; > +} > + [...] > +BPF_CALL_4(bpf_get_task_stack, struct task_struct *, task, void *, buf, > + u32, size, u64, flags) > +{ > + struct pt_regs *regs = task_pt_regs(task); > + > + return __bpf_get_stack(regs, task, buf, size, flags); > +} So this takes advantage of BTF and having a direct task_struct pointer. But for kprobes/tracepoint I think it would also be extremely helpful to be able to request stack trace by PID. How about one more helper which will wrap this one with get/put task by PID, e.g., bpf_get_pid_stack(int pid, void *buf, u32 size, u64 flags)? Would that be a problem? > + > +static int bpf_get_task_stack_btf_ids[5]; > +const struct bpf_func_proto bpf_get_task_stack_proto = { > + .func = bpf_get_task_stack, > + .gpl_only = false, > + .ret_type = RET_INTEGER, > + .arg1_type = ARG_PTR_TO_BTF_ID, > + .arg2_type = ARG_PTR_TO_UNINIT_MEM, > + .arg3_type = ARG_CONST_SIZE_OR_ZERO, > + .arg4_type = ARG_ANYTHING, > + .btf_id = bpf_get_task_stack_btf_ids, > +}; > + [...]