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 A3245C61DA4 for ; Thu, 2 Feb 2023 11:16:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231953AbjBBLQL (ORCPT ); Thu, 2 Feb 2023 06:16:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231207AbjBBLPx (ORCPT ); Thu, 2 Feb 2023 06:15:53 -0500 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 855708AC2B; Thu, 2 Feb 2023 03:15:52 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id f7so1619289edw.5; Thu, 02 Feb 2023 03:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wpEflEFgONyZvi4WlCVrqQszvFR7vLDMgEvU+XA8+7w=; b=F9HPADDYpgDBMmMTw31hsL/BPt7sHthFt72xAHYYI6C4/tsAnTR9FS5BP08bc1GDo3 DlNxEE3klfp5hJgGUiMrrQ2mXMAacJZUbuP6LwQWECphzi485IppWULASmHz4LQ0aNhe xmD+ztykHvf7YxHzipN8QUabxTl21cADcR325iN5Z22Re7fK+YDv+KzZtQndt4y5qkdR FvWv+JZ4jOrSNBvgP++Q08Zn2vgEBArx8wh4B7VvOiWaOtUyeJ4ZEG+usB/Ibqg1JjPd Y7k9q6EN6VNFNdx2Qh5peMUR9I7rEkdi8CWxdUbf7hKziuzJzDOYs8600k1Q5nl5p6ld vFyg== 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=wpEflEFgONyZvi4WlCVrqQszvFR7vLDMgEvU+XA8+7w=; b=67jBChMPPxdws5c1h2zFqTRIDYzwaeqeBmQ0s3ErSy3/OP4PtHaRlISfa4KXFy4VRk /ssAPlMuKzKqJMkAzlNtsjtndpTEL+yDu5l6rubtgdKvX5yWFezoviFR8Mv2MNRx6gF5 4w1dQRPZ3hQcvT7MOfItHCGRqAKW7hhPQDJr7R6X2skYnyr9qzsYV6F7+r+MUuN5uO8A IGz6tz8Z44IZQargQ6Oc4yfu7CZ5w4Hs6qlNdCcXURM2SqgxgdvVsUe0SHnKM8WdbtNd iK5lJjSmDcUUVDNZJpdaHKVIPhSA71s3nwoMvNs+3otoNTeyZidM1pWt6sFTg+EdFbnZ PNYA== X-Gm-Message-State: AO0yUKV7Iely+RYqo802RLDsRqhpIclqTFhFwQyiph83epWiThbtY5sQ pMHp21oc88VEw0jAa/x9T7oZ+ACL4jhAQZNov5Y= X-Google-Smtp-Source: AK7set/7vshqxPiS23f8zcEnLOB/WqJuLi7g76SaS9Fq+nI1GtacYnaPHdA3rg1UlpyFnJfbN29NT+FyA7W/0XKnnAM= X-Received: by 2002:aa7:d385:0:b0:49e:6501:57a2 with SMTP id x5-20020aa7d385000000b0049e650157a2mr1774099edq.43.1675336550794; Thu, 02 Feb 2023 03:15:50 -0800 (PST) MIME-Version: 1.0 References: <20230201135737.800527-1-jolsa@kernel.org> In-Reply-To: <20230201135737.800527-1-jolsa@kernel.org> From: Alexei Starovoitov Date: Thu, 2 Feb 2023 03:15:39 -0800 Message-ID: Subject: Re: [RFC 0/5] mm/bpf/perf: Store build id in file object To: Jiri Olsa Cc: Alexei Starovoitov , Andrii Nakryiko , Hao Luo , Andrew Morton , Alexander Viro , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , bpf , linux-mm , LKML , Linux-Fsdevel , "linux-perf-use." , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Daniel Borkmann Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 1, 2023 at 5:57 AM Jiri Olsa wrote: > > hi, > we have a use cases for bpf programs to use binary file's build id. > > After some attempts to add helpers/kfuncs [1] [2] Andrii had an idea [3] > to store build id directly in the file object. That would solve our use > case and might be beneficial for other profiling/tracing use cases with > bpf programs. > > This RFC patchset adds new config CONFIG_FILE_BUILD_ID option, which adds > build id object pointer to the file object when enabled. The build id is > read/populated when the file is mmap-ed. > > I also added bpf and perf changes that would benefit from this. > > I'm not sure what's the policy on adding stuff to file object, so apologies > if that's out of line. I'm open to any feedback or suggestions if there's > better place or way to do this. struct file represents all files while build_id is for executables only, and not all executables, but those currently running, so I think it's cleaner to put it into vm_area_struct.