From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9876CC433FE for ; Wed, 2 Nov 2022 22:18:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231388AbiKBWS2 (ORCPT ); Wed, 2 Nov 2022 18:18:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229709AbiKBWS0 (ORCPT ); Wed, 2 Nov 2022 18:18:26 -0400 Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C841760FF; Wed, 2 Nov 2022 15:18:24 -0700 (PDT) Received: by mail-oi1-f173.google.com with SMTP id t62so175051oib.12; Wed, 02 Nov 2022 15:18:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dR8uIufVFmQcFdrcHJYjIkFyqVjcm0qVXvQv/HVwRjc=; b=d3Zn6YxfLie56/O3Wm2JZwzO7nurUYi3rOmteRFj5pU5/sqXUvu9pCJgwBeEdjCTXU ASCas664Uy5cxV3PTPTXwvHUjET1a3ng3mcZkgoOPcPVeFqxvfRFCr48GW811T+DZyDZ heQ9LOspNpCuprPXhn87gcUP7pqNsYDXiL/t2N+pFyFXc/QOl0BM+bPFu4ORvCeBSmOR op4oy7y5TMbQEEP9bPqzlo/tHIXDvQl1DX+8Ok5SzB7SHDnw6F3gKR8NQOgYqfqOIh4A yOckmqIgBkQ6XS2q3WusM24dbvhmiDUnFZfAm3Cz070cWk+kF2CPnPUerVvr3LSmFKtH mGgg== X-Gm-Message-State: ACrzQf1gpglYoPNsHx2oZMQZIAYGPzHkI73Q1erRB+MjiM2SyVx0uADd 29cE/P9k4+mRk5Cy6h7cTBE4YOGu0YGyJR0HMYU= X-Google-Smtp-Source: AMsMyM6q7R3EyYUPkk/AzDCYX0Ctf96X0PBm7eOp29CIWSHbiGQPUh1ET5i4QdZWILZLdwuEtKSd+kLveoPLddfA/Dk= X-Received: by 2002:aca:ac82:0:b0:359:d662:5bfb with SMTP id v124-20020acaac82000000b00359d6625bfbmr15283796oie.218.1667427504100; Wed, 02 Nov 2022 15:18:24 -0700 (PDT) MIME-Version: 1.0 References: <20221101052340.1210239-1-namhyung@kernel.org> <20221101052340.1210239-3-namhyung@kernel.org> In-Reply-To: From: Namhyung Kim Date: Wed, 2 Nov 2022 15:18:12 -0700 Message-ID: Subject: Re: [PATCH bpf-next 2/3] bpf: Add bpf_perf_event_read_sample() helper To: Song Liu Cc: Alexei Starovoitov , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Song Liu , Peter Zijlstra , Martin KaFai Lau , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Stanislav Fomichev , LKML , bpf , Steven Rostedt , Ingo Molnar , Arnaldo Carvalho de Melo Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 1, 2022 at 5:13 PM Song Liu wrote: > > On Tue, Nov 1, 2022 at 3:17 PM Namhyung Kim wrote: > > IIUC we want something like below to access sample data directly, > > right? > > > > BPF_CORE_READ(ctx, data, ip); > > > > I haven't tried this, but I guess we may need something like > > data = ctx->data; > BPF_CORE_READ(data, ip); Ok, will try. > > > Some fields like raw and callchains will have variable length data > > so it'd be hard to check the boundary at load time. > > I think we are fine as long as we can check boundaries at run time. Sure, that means it's the responsibility of BPF writers, right? > > > Also it's possible > > that some fields are not set (according to sample type), and it'd be > > the user's (or programmer's) responsibility to check if the data is > > valid. If these are not the concerns, I think I'm good. > > So we still need 1/3 of the set to make sure the data is valid? Of course, I'll keep it in the v2. Thanks, Namhyung