Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1113789ybl; Thu, 23 Jan 2020 13:54:47 -0800 (PST) X-Google-Smtp-Source: APXvYqw05FDdMCVOBCFADAoPT/DyNBnbh8fw0fzHjuR0D9EyzYSxrreEvUJ93xvNqd2U7Uzb1YNb X-Received: by 2002:aca:59c2:: with SMTP id n185mr30975oib.170.1579816487075; Thu, 23 Jan 2020 13:54:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579816487; cv=none; d=google.com; s=arc-20160816; b=HMam+quK4d86TtnCqdCqDBJuH2rn8/O/GDnSlJCl05dGT+hndpOA9WYob8FJlQcwJB LIytb+ciWh+jVKBrDpXAHhYw+GrPkbP2DW9X3g7ru8Non/tECPIi6/Ry15mCbgpCRrD7 t2zd9c5BnUzUok4yJ3Xthum7qZ8xHIdIYvBvD+z+x2hMjwVPAUNipg8ezM7YpZlWSZ7k QXwkvG/Qc0voN+0FOxzWQG3wTiuc1Py2YbUYWOcV0cmqXqR3/YJqYlSHpUzJC6WiMyDX RP8YGhB3itR8+R7uhAluDDJ6GoeK23lHOsuONXT63XYyaMafOL8NQRr3kgeNZRsSNdV2 jo5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-signature; bh=1pOY6NnXuTrtOrNBPH2A+RlZvbQQ49qUow5adELd1XU=; b=NxD4M/zB5Kv51U9PwDgR6A9rTq9tF2bvHSJ/N14G7ZqzVwcTXbq7RAWaSBFhI9NYxL n0PG14nYNHWJe1Z5/8X6Gh4VcjubfVXXrHw6cyZmLN27iC6M5QL+iAGbi4r9SIAPW+AX Ee9mW0rdB6z83ZZxV5Tga7yHWIFvCJU5agaAwm2yc91AxW3NXaYhYHoAIMYmo2QzCe7Z 2AaF9y5eRNRUodkl4mYXvrcVtS/GtAz8iVamZHsPoU28L+3/7ynwAoGAhVYupS7C+Xnw Om8kIYyQje+2XYJnUoF6DW3fKpuox1EFC7M9Pr0yHoM1TnZcfghqytOaCOv4zJKMsAVp av8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dxuuu.xyz header.s=fm2 header.b=bIkCNs2s; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b="UgcTrf8/"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u12si1452815oiv.13.2020.01.23.13.54.33; Thu, 23 Jan 2020 13:54:47 -0800 (PST) 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; dkim=pass header.i=@dxuuu.xyz header.s=fm2 header.b=bIkCNs2s; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b="UgcTrf8/"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729433AbgAWVXn (ORCPT + 99 others); Thu, 23 Jan 2020 16:23:43 -0500 Received: from new2-smtp.messagingengine.com ([66.111.4.224]:35833 "EHLO new2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729508AbgAWVXk (ORCPT ); Thu, 23 Jan 2020 16:23:40 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 2FB604765; Thu, 23 Jan 2020 16:23:39 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 23 Jan 2020 16:23:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dxuuu.xyz; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; s=fm2; bh=1pOY6NnXuTrtO rNBPH2A+RlZvbQQ49qUow5adELd1XU=; b=bIkCNs2sMGQHoDxOjQQ/GYS9JH1+R fL7+0fvIaS634Kpn3S0JK2jsNncgQ4/cvwz4VrF/NHRMpIrPXhAPB0lLv3a0iCRG XLt6HYZtD0YRlg5Hl0n+IfpJVbwxGf1VMEbPOYRGbJCXBqDyUsmBroSuuw+ffAb3 G51JUnlliTZGidl7RCOY8ZZea6f2IsQsCrA+pTDE5a3kbEwX7o2WsXFyjHevNCjX 2A1T1btS4DEflrNrjJokE/KWe4LvGqW6/VZ+3h3oX54Ukk1V/kjqC7XTW2G3A6n2 tzl0npEaq92Ao46xdhwu0fFifIvznRkGcBN6ysDOPeLJGtOsMt9aIhggw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=1pOY6NnXuTrtOrNBPH2A+RlZvbQQ49qUow5adELd1XU=; b=UgcTrf8/ LPmX82x0/micOOnkGzWYbcyTU7I1E1cH4xbJN0u7H1XDZGWo5JRJmiwrrcr0Wzj5 0CXSlNEjl3LK+WAQx+AlwFj++MOiNGWYLOWCgUrHu4UoaWaT+j4vJ7AIDcdAC8f6 fdah3MrupbPwHO735zWDv5F8avg+3usJW4kiMVbBASTSG/0MdHApE6SPaGXJ/qQW jRcu9g0Ui0B1Dkwnd/QUxCNmZjVIW4yxy0Rn9hGZd+kNbpY6NbxCWgyvIquJTouK HNLxdWni/23GUjWIiYXt9GvktahhEQQI5LAfV31Y2gh24pMiFERQVkge+KUv7ePM qa4wYhCoEmTXWg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrvddvgdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecufghrlhcuvffnffculdejtddmnecujfgurhephffvuf ffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeffrghnihgvlhcuighuuceougig uhesugiguhhuuhdrgiihiieqnecukfhppeduleelrddvtddurdeigedrudefheenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegugihusegugihu uhhurdighiii X-ME-Proxy: Received: from dlxu-fedora-R90QNFJV.thefacebook.com (unknown [199.201.64.135]) by mail.messagingengine.com (Postfix) with ESMTPA id BB0883060ACE; Thu, 23 Jan 2020 16:23:37 -0500 (EST) From: Daniel Xu To: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, songliubraving@fb.com, yhs@fb.com, andriin@fb.com Cc: Daniel Xu , linux-kernel@vger.kernel.org, kernel-team@fb.com, peterz@infradead.org, mingo@redhat.com, acme@kernel.org Subject: [PATCH v3 bpf-next 1/3] bpf: Add bpf_perf_prog_read_branches() helper Date: Thu, 23 Jan 2020 13:23:10 -0800 Message-Id: <20200123212312.3963-2-dxu@dxuuu.xyz> X-Mailer: git-send-email 2.21.1 In-Reply-To: <20200123212312.3963-1-dxu@dxuuu.xyz> References: <20200123212312.3963-1-dxu@dxuuu.xyz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Branch records are a CPU feature that can be configured to record certain branches that are taken during code execution. This data is particularly interesting for profile guided optimizations. perf has had branch record support for a while but the data collection can be a bit coarse grained. We (Facebook) have seen in experiments that associating metadata with branch records can improve results (after postprocessing). We generally use bpf_probe_read_*() to get metadata out of userspace. That's why bpf support for branch records is useful. Aside from this particular use case, having branch data available to bpf progs can be useful to get stack traces out of userspace applications that omit frame pointers. Signed-off-by: Daniel Xu --- include/uapi/linux/bpf.h | 15 ++++++++++++++- kernel/trace/bpf_trace.c | 31 +++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index f1d74a2bd234..50c580c8a201 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -2892,6 +2892,18 @@ union bpf_attr { * Obtain the 64bit jiffies * Return * The 64 bit jiffies + * + * int bpf_perf_prog_read_branches(struct bpf_perf_event_data *ctx, void *buf, u32 buf_size) + * Description + * For en eBPF program attached to a perf event, retrieve the + * branch records (struct perf_branch_entry) associated to *ctx* + * and store it in the buffer pointed by *buf* up to size + * *buf_size* bytes. + * + * Any unused parts of *buf* will be filled with zeros. + * Return + * On success, number of bytes written to *buf*. On error, a + * negative value. */ #define __BPF_FUNC_MAPPER(FN) \ FN(unspec), \ @@ -3012,7 +3024,8 @@ union bpf_attr { FN(probe_read_kernel_str), \ FN(tcp_send_ack), \ FN(send_signal_thread), \ - FN(jiffies64), + FN(jiffies64), \ + FN(perf_prog_read_branches), /* integer value in 'imm' field of BPF_CALL instruction selects which helper * function eBPF program intends to call diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 19e793aa441a..24c51272a1f7 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -1028,6 +1028,35 @@ static const struct bpf_func_proto bpf_perf_prog_read_value_proto = { .arg3_type = ARG_CONST_SIZE, }; +BPF_CALL_3(bpf_perf_prog_read_branches, struct bpf_perf_event_data_kern *, ctx, + void *, buf, u32, size) +{ + struct perf_branch_stack *br_stack = ctx->data->br_stack; + u32 to_copy = 0, to_clear = size; + int err = -EINVAL; + + if (unlikely(!br_stack)) + goto clear; + + to_copy = min_t(u32, br_stack->nr * sizeof(struct perf_branch_entry), size); + to_clear -= to_copy; + + memcpy(buf, br_stack->entries, to_copy); + err = to_copy; +clear: + memset(buf + to_copy, 0, to_clear); + return err; +} + +static const struct bpf_func_proto bpf_perf_prog_read_branches_proto = { + .func = bpf_perf_prog_read_branches, + .gpl_only = true, + .ret_type = RET_INTEGER, + .arg1_type = ARG_PTR_TO_CTX, + .arg2_type = ARG_PTR_TO_UNINIT_MEM, + .arg3_type = ARG_CONST_SIZE, +}; + static const struct bpf_func_proto * pe_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) { @@ -1040,6 +1069,8 @@ pe_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) return &bpf_get_stack_proto_tp; case BPF_FUNC_perf_prog_read_value: return &bpf_perf_prog_read_value_proto; + case BPF_FUNC_perf_prog_read_branches: + return &bpf_perf_prog_read_branches_proto; default: return tracing_func_proto(func_id, prog); } -- 2.21.1