Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp336277pxp; Fri, 11 Mar 2022 05:23:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJwlved9XsgUP0P4HvPFUUjJTbdBx25iqor5nPk0OPtx+vh88yD9JucHP4+79FrAcEmXfeng X-Received: by 2002:a05:6402:718:b0:415:a0e5:48c with SMTP id w24-20020a056402071800b00415a0e5048cmr8927325edx.156.1647005013836; Fri, 11 Mar 2022 05:23:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1647005013; cv=none; d=google.com; s=arc-20160816; b=PBDcZXPdAG+MJ+yG2/8g0djqgNwchfxNumCg7hSzkqTjeq7XWfpr64QhR3YurNbX48 eq/4ymgNd7XCxuXNhbP6XGASGAeUGoTnu0KV8jLgOgrXzco8IihFodU/1p6pC8TyDaRW VcqihohSTO+HGxGdnvB0WpzXtSBUjzGRfscRgtrNi2q4LRPMgJcosS0Keagtn75znXgj 8UAHjPetRb+807cmz+TiF4LwykKdSzo/I3os6+dBuOllGkzHqUp0CzEy8j+2RgxlbtwM HYhbeWI2bvbIJXaHZVWh9m0e3mxqGMlSw4Sy+84oVFpRwD087V8g0W2kIAoG6Pk0dRfP FQfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=8ztmSGKB7K4TQG0uwXYKwyrxqq4V9q91bmnu9QHKsFM=; b=guDkbfsoqfrz3IsA+JLb8ADgzoVcIICLWFvMN8eq4ZZlBL2JiufNCxK7mTFhE+hAWn TTW9QjBZ2DWl2fQrTFm58euL9C9UC9awE4wl+H73JzwI8+sm2TmLsPjk+KqNix4xBN3x 4Tl573FJzzz53I9rlt5VSAsXjOxxMMbDaJ1LRTC7VjBxMFRQ2h2qX85e13v+TaGFrFQ4 k6IquCbYNyOiEwFLzNUoDPZv5wlMttPg4mtXy5qOwolL8c7TvBid+U8hnjh5MoVrIgzT hiO0x4AicmMfYT5zS0RvGWbEWjPVpju0Ga4U2i9VFwFbfoLDF57wJiFDMrJgilU53Yy/ MfJg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q11-20020a1709064ccb00b006adbcd37c7esi4763328ejt.116.2022.03.11.05.23.07; Fri, 11 Mar 2022 05:23:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345429AbiCKAdj (ORCPT + 99 others); Thu, 10 Mar 2022 19:33:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34046 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344995AbiCKAdh (ORCPT ); Thu, 10 Mar 2022 19:33:37 -0500 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15BED403DC; Thu, 10 Mar 2022 16:32:35 -0800 (PST) Received: by mail-lf1-f44.google.com with SMTP id w12so12326407lfr.9; Thu, 10 Mar 2022 16:32:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8ztmSGKB7K4TQG0uwXYKwyrxqq4V9q91bmnu9QHKsFM=; b=2MwkadopyPfXwXX67ck0lWPud4LCq6TUCwwRGsVF7T2/mvK3BxEQ3aqkV+H4UiLSJj 9Q+k3M9RVRxGWHCQmRlZTvtguZyalS46A5zqDjrj4dRdXeRxawA9iHaVJ9roH1XWlhMF P1BTLcFVqlCG6GWqy3VJc/DKDBoyQ5+IqQfueP9v7C+jJHAhripZhOYJjvWyhk7vOSqY MBr2j1aJvf/zIxUd/qrezS306XjEpYgvh+XBF+mY2LmwuW+SkzVeoe92APmN8/syVuUb ShXU7E0aXj3GuDf9v48kOHJL0ZbaLC0iINhrQuCqyFMrNe4oELt0FQHg27M332am/l55 /Qpw== X-Gm-Message-State: AOAM532QxkgCTnqA/iabGTX8WOPZtHodECwjAmbqw1fwvmxD2s389gsN Z4aWBVnKP30vE564YAmA3atLFsjDtSw7R+eqUF0= X-Received: by 2002:a05:6512:1195:b0:448:4fcc:34f2 with SMTP id g21-20020a056512119500b004484fcc34f2mr4391524lfr.454.1646958753412; Thu, 10 Mar 2022 16:32:33 -0800 (PST) MIME-Version: 1.0 References: <20220310082202.1229345-1-namhyung@kernel.org> In-Reply-To: From: Namhyung Kim Date: Thu, 10 Mar 2022 16:32:22 -0800 Message-ID: Subject: Re: [PATCH 1/2] bpf: Adjust BPF stack helper functions to accommodate skip > 0 To: Yonghong Song Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , John Fastabend , KP Singh , Network Development , bpf , LKML , Arnaldo Carvalho de Melo , Peter Zijlstra , Eugene Loh , Hao Luo Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE 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 Hello, On Thu, Mar 10, 2022 at 2:55 PM Yonghong Song wrote: > > > > On 3/10/22 12:22 AM, Namhyung Kim wrote: > > Let's say that the caller has storage for num_elem stack frames. Then, > > the BPF stack helper functions walk the stack for only num_elem frames. > > This means that if skip > 0, one keeps only 'num_elem - skip' frames. > > > > This is because it sets init_nr in the perf_callchain_entry to the end > > of the buffer to save num_elem entries only. I believe it was because > > the perf callchain code unwound the stack frames until it reached the > > global max size (sysctl_perf_event_max_stack). > > > > However it now has perf_callchain_entry_ctx.max_stack to limit the > > iteration locally. This simplifies the code to handle init_nr in the > > BPF callstack entries and removes the confusion with the perf_event's > > __PERF_SAMPLE_CALLCHAIN_EARLY which sets init_nr to 0. > > > > Also change the comment on bpf_get_stack() in the header file to be > > more explicit what the return value means. > > > > Based-on-patch-by: Eugene Loh > > Signed-off-by: Namhyung Kim > > The change looks good to me. This patch actually fixed a bug > discussed below: > > > https://lore.kernel.org/bpf/30a7b5d5-6726-1cc2-eaee-8da2828a9a9c@oracle.com/ > > A reference to the above link in the commit message > will be useful for people to understand better with an > example. Ok, will do. > > Also, the following fixes tag should be added: > > Fixes: c195651e565a ("bpf: add bpf_get_stack helper") Sure. > > Since the bug needs skip > 0 which is seldomly used, > and the current returned stack is still correct although > with less entries, I guess that is why less people > complains. > > Anyway, ack the patch: > Acked-by: Yonghong Song Thanks for your review! Namhyung > > > > --- > > include/uapi/linux/bpf.h | 4 +-- > > kernel/bpf/stackmap.c | 56 +++++++++++++++++----------------------- > > 2 files changed, 26 insertions(+), 34 deletions(-) > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > index b0383d371b9a..77f4a022c60c 100644 > > --- a/include/uapi/linux/bpf.h > > +++ b/include/uapi/linux/bpf.h > > @@ -2975,8 +2975,8 @@ union bpf_attr { > > * > > * # sysctl kernel.perf_event_max_stack= > > * Return > > - * A non-negative value equal to or less than *size* on success, > > - * or a negative error in case of failure. > > + * The non-negative copied *buf* length equal to or less than > > + * *size* on success, or a negative error in case of failure. > > * > > * long bpf_skb_load_bytes_relative(const void *skb, u32 offset, void *to, u32 len, u32 start_header) > [...]