From patchwork Fri Feb 2 22:53:18 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Song Liu X-Patchwork-Id: 868817 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=fb.com header.i=@fb.com header.b="C0pz9QWX"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3zYC3158zWz9sP9 for ; Sat, 3 Feb 2018 09:54:05 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752139AbeBBWyB (ORCPT ); Fri, 2 Feb 2018 17:54:01 -0500 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:38132 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751468AbeBBWx7 (ORCPT ); Fri, 2 Feb 2018 17:53:59 -0500 Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w12Mqd72018579 for ; Fri, 2 Feb 2018 14:53:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : mime-version : content-type; s=facebook; bh=F6DF/9C7xCmqySzBkIp7KkNIVNjSHm9sPmEqeewiUpw=; b=C0pz9QWXmoYasZJiVchXfPapsGlBf1YUdutevv1bZK3Y8XUVhof41NZPmr/5R642K63T +AZQR6waxK8TQuunyP3aXWsrOD1OkyiUVwjHKSP3YXO/zpFr0xPUe60BguLgq3QaJEsN vb9xIBg+aNfmIiYQ3dJDB1pP1TdUceSYpE4= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fvy4ggnqn-3 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 02 Feb 2018 14:53:59 -0800 Received: from mx-out.facebook.com (192.168.52.123) by PRN-CHUB14.TheFacebook.com (192.168.16.24) with Microsoft SMTP Server id 14.3.361.1; Fri, 2 Feb 2018 14:53:57 -0800 Received: by devbig102.frc2.facebook.com (Postfix, from userid 4523) id EA89D4282302; Fri, 2 Feb 2018 14:53:56 -0800 (PST) Smtp-Origin-Hostprefix: devbig From: Song Liu Smtp-Origin-Hostname: devbig102.frc2.facebook.com To: , , , CC: , , Song Liu Smtp-Origin-Cluster: frc2c02 Subject: [RFC bpf-next 0/2] stackmap with build_id+offset Date: Fri, 2 Feb 2018 14:53:18 -0800 Message-ID: <20180202225320.2462163-1-songliubraving@fb.com> X-Mailer: git-send-email 2.9.5 X-FB-Internal: Safe MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-02_04:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org This work follows up discussion at Plumbers'17 on improving addr->sym resolution of user stack traces. The following links have more information of the discussion: http://www.linuxplumbersconf.org/2017/ocw/proposals/4764 https://lwn.net/Articles/734453/ Section "Stack traces and kprobes" Currently, bpf stackmap store address for each entry in the call trace. To map these addresses to user space files, it is necessary to maintain the mapping from these virtual address to symbols in the binary. Usually, the user space profiler (such as perf) has to scan /proc/pid/maps at the beginning of profiling, and monitor mmap2() calls afterwards. Given the cost of maintaining the address map, this solution is not practical for system wide profiling that is always on. This patch tries to address this with a variation to stackmap. Instead of storing addresses, the variation stores ELF file build_id + offset. After profiling, a user space tool will look up these functions with build_id (to find the binary or shared library) and the offset. I also updated bcc/cc library for the stackmap (no python/lua support yet). You can find the work at: https://github.com/liu-song-6/bcc/commits/bpf_get_stackid_v02 Thanks, Song Song Liu (2): bpf: extend stackmap to save binary_build_id+offset instead of address bpf: add selftest for stackmap with BPF_F_STACK_BUILD_ID include/uapi/linux/bpf.h | 15 ++ kernel/bpf/stackmap.c | 261 +++++++++++++++++++-- tools/include/uapi/linux/bpf.h | 15 ++ tools/testing/selftests/bpf/Makefile | 12 +- tools/testing/selftests/bpf/test_progs.c | 164 ++++++++++++- .../selftests/bpf/test_stacktrace_build_id.c | 60 +++++ tools/testing/selftests/bpf/urandom_read.c | 22 ++ 7 files changed, 525 insertions(+), 24 deletions(-) create mode 100644 tools/testing/selftests/bpf/test_stacktrace_build_id.c create mode 100644 tools/testing/selftests/bpf/urandom_read.c --- 2.9.5