Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1036583pxm; Wed, 23 Feb 2022 16:30:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJyKTnoJacT/6qFF3D7DQ318Po8iivLrFj8bds2SQT+WE5gI6Ij+nDgDIamiJ0zImf3krLjM X-Received: by 2002:a17:902:f785:b0:14d:d2b6:b7c with SMTP id q5-20020a170902f78500b0014dd2b60b7cmr59066pln.68.1645662647604; Wed, 23 Feb 2022 16:30:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645662647; cv=none; d=google.com; s=arc-20160816; b=VKZgd94riFf7tK9ZX77B4j9mG4kS95DCH5UCscx3KCnd4lvNge+1ydX7TYWLqTMwbG Aq8fC2LomFLMtxmN1OS/nObm+8P827Rgt+KpYKYdtL8llJsQwTkl+CGZ2Y8+VBjwVT4T 5J0GhG1SYkQCe2EE0V4TQlfJ0KI+furGOj/KN+59tCciSedjg7dnXn5E5+SLpyRZi2m5 //t1YVkjJ9TFAfrjQatj8SFmgtUw1bl0fEBizv8WhaKYOz/INnww0zRqu9aLDb0Fn90f ilY1eLGON/k98I0OIbmXr2ULhBeYU5fp282x/cbkfw2HhrDXTsr/HUdpEoP3U0qWujv7 om0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:mime-version:message-id:date :dkim-signature; bh=iT2nwSp2MDELC5D0BfQ9M2lshxJNXqqajiXX8H+mgdY=; b=Y++EBsB8cloZd4wZmg8U3r8M3HvS1Rh5cYKhWtaflIaFUk5k7Ykig2DRvx8haykNj3 pIMHiiH5g9AHXWmI6374lgzYrLAoCAF8xfZcO6bEPxm6VPbHlKaJBw1K3gWIymutlC7y wWJe6/YnbBpdu5952gXmhqYVGDx4+7UPoriJ4MsUtYM+yuW0VRQH8EG/Ndw8szg3xlv9 jYYD4SlN36CeYvU3ipZ5ECnidLpwhj8S/BH/FvYwqH8Gr55MCZ9Gldv4feLCYHVctOd1 qGX3jnoyrcbmY9o5g6ABEJ+1dpAqd9yfjdMwLNZblTKfVEGFd+sJYudJPLEZQRNeLl2W 38Lg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=kn+bLvQl; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id p21si990065plr.574.2022.02.23.16.30.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Feb 2022 16:30:47 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=kn+bLvQl; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D0E5D6E4FA; Wed, 23 Feb 2022 16:30:44 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245125AbiBXAGH (ORCPT + 99 others); Wed, 23 Feb 2022 19:06:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245121AbiBXAGG (ORCPT ); Wed, 23 Feb 2022 19:06:06 -0500 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D04085E75F for ; Wed, 23 Feb 2022 16:05:36 -0800 (PST) Received: by mail-yb1-xb49.google.com with SMTP id a12-20020a056902056c00b0061dc0f2a94aso294942ybt.6 for ; Wed, 23 Feb 2022 16:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:message-id:mime-version:subject:from:to:cc; bh=iT2nwSp2MDELC5D0BfQ9M2lshxJNXqqajiXX8H+mgdY=; b=kn+bLvQlifPhevSSRCAMPEsDbXAbo11L/fJnHiILGz3s/JmAEsBglIaLuY4Oanwudq gl+XEjYU/xmrN6sxvU8aQyKNSRRTgyqkoKJjuwPLiYQAL158Y7sDWPvuIrbDnEMu1/4e I2QbZW9Zmqd5OzDUhaNVsM57vtVWTELwjqlNT06PFABsBk3UoF1IeouVa0iBUAE9+o6L 61Qt9Aukr+KvAVLr9MfJhk6nVJlycej+oUiOcgUM+sqpLfmJQHxmEhGUR5zL9i+g3UXB 4JWau7fkz8hWBmZrkW3Hp6oJJJdxcRTf/wtyz+LHSgnP4cSN4dA6WS4ZNntl4y7dhONB QmdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=iT2nwSp2MDELC5D0BfQ9M2lshxJNXqqajiXX8H+mgdY=; b=ZNpI29fLcpoqUHFfgMmRqzuwXdZpkoOjoVeqTkvZCS0S/foQpmqxO29mb7s0RW1kLx 6zRgNd+DJWrhg6x8XdoJS53ELqhcz+0qVbXtp1cVVmjWEPtM1arpP4/r6BRhfVDUSoxE w+VC2FoqVSZggioVJ/CR1H2ReSz0nzz2JjDFn0hUAGGnqplqJXmL5KnRW54UsBglc7wN 4wJbeucNxjMN8Y/4xHwQNn5EJ6FFCCNQBIJzkLcW1nIf20J4uhudpqJMsqKdvWe2jT6w FJDQ1piXfw2M00h+KNndrX4x+pyAin6rCXxHUHGgnLK7UmxSyowYnm/aWglHA+UR0YRc P2eQ== X-Gm-Message-State: AOAM53105thiRdt9xYQAIQgGUQFNcLoGsrHbgqw8IyPrW4MVjAitoWCY ycryOU9Z63Ko2xAS6rtaaAp849szonw= X-Received: from haoluo.svl.corp.google.com ([2620:15c:2cd:202:9479:7f16:e9b8:14e4]) (user=haoluo job=sendgmr) by 2002:a25:b226:0:b0:624:5e7a:56b with SMTP id i38-20020a25b226000000b006245e7a056bmr174872ybj.61.1645661136096; Wed, 23 Feb 2022 16:05:36 -0800 (PST) Date: Wed, 23 Feb 2022 16:05:31 -0800 Message-Id: <20220224000531.1265030-1-haoluo@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.35.1.473.g83b2b277ed-goog Subject: [PATCH bpf-next v2] bpf: Cache the last valid build_id. From: Hao Luo To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Cc: Song Liu , Namhyung Kim , Blake Jones , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, Hao Luo , Greg Thelen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For binaries that are statically linked, consecutive stack frames are likely to be in the same VMA and therefore have the same build id. As an optimization for this case, we can cache the previous frame's VMA, if the new frame has the same VMA as the previous one, reuse the previous one's build id. We are holding the MM locks as reader across the entire loop, so we don't need to worry about VMA going away. Tested through "stacktrace_build_id" and "stacktrace_build_id_nmi" in test_progs. Suggested-by: Greg Thelen Signed-off-by: Hao Luo --- kernel/bpf/stackmap.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c index 22c8ae94e4c1..38bdfcd06f55 100644 --- a/kernel/bpf/stackmap.c +++ b/kernel/bpf/stackmap.c @@ -132,7 +132,8 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs, int i; struct mmap_unlock_irq_work *work = NULL; bool irq_work_busy = bpf_mmap_unlock_get_irq_work(&work); - struct vm_area_struct *vma; + struct vm_area_struct *vma, *prev_vma = NULL; + const char *prev_build_id; /* If the irq_work is in use, fall back to report ips. Same * fallback is used for kernel stack (!user) on a stackmap with @@ -150,6 +151,12 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs, } for (i = 0; i < trace_nr; i++) { + if (range_in_vma(prev_vma, ips[i], ips[i])) { + vma = prev_vma; + memcpy(id_offs[i].build_id, prev_build_id, + BUILD_ID_SIZE_MAX); + goto build_id_valid; + } vma = find_vma(current->mm, ips[i]); if (!vma || build_id_parse(vma, id_offs[i].build_id, NULL)) { /* per entry fall back to ips */ @@ -158,9 +165,12 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs, memset(id_offs[i].build_id, 0, BUILD_ID_SIZE_MAX); continue; } +build_id_valid: id_offs[i].offset = (vma->vm_pgoff << PAGE_SHIFT) + ips[i] - vma->vm_start; id_offs[i].status = BPF_STACK_BUILD_ID_VALID; + prev_vma = vma; + prev_build_id = id_offs[i].build_id; } bpf_mmap_unlock_mm(work, current->mm); } -- 2.35.1.473.g83b2b277ed-goog