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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2705EC76196 for ; Fri, 31 Mar 2023 20:28:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 99F846B007B; Fri, 31 Mar 2023 16:28:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 94F3D6B007D; Fri, 31 Mar 2023 16:28:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F1FC6B007E; Fri, 31 Mar 2023 16:28:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6C5BA6B007B for ; Fri, 31 Mar 2023 16:28:01 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 40C0E404D3 for ; Fri, 31 Mar 2023 20:28:01 +0000 (UTC) X-FDA: 80630329962.07.532C6FE Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf14.hostedemail.com (Postfix) with ESMTP id 765B010000D for ; Fri, 31 Mar 2023 20:27:59 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="a/Ja9f9x"; spf=pass (imf14.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680294479; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GK0MF0uNmzEytcPCm/B24vsna4+KtlPH2hXHihrk2Pg=; b=GUED9XPB9XusObGKNCbqIiOHO2+M7MahzxLJ/ufwRp6xijodxuhllQ02rx27o5P3fdKun6 2fkLMfi2FMMcmMqS1qj9ZvDITuDzeTJ3i7ZHNW8p0A65fuMSUyYE/7Vho+OKdvejlo3a3J 8PJhQfKKLHVFYTsUw3Uxk+LwtBtvQbA= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="a/Ja9f9x"; spf=pass (imf14.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680294479; a=rsa-sha256; cv=none; b=MxEiWe2NTtI9QJ/PEHepNYjMrWfAZHSmUGEC6SxvT0B5qOETOM05dQwIGAyGH0qVFybHN2 cM7v5ahr10X8xiFW4nohTIAfyivGmdcczdHrpjsCXT6l4H54Nr3NuvIPazcY13CJugQMoT iIHgWwnah9UrcrKmkwjAT8aXRau37A0= Received: by mail-ed1-f43.google.com with SMTP id y4so94434001edo.2 for ; Fri, 31 Mar 2023 13:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680294478; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GK0MF0uNmzEytcPCm/B24vsna4+KtlPH2hXHihrk2Pg=; b=a/Ja9f9xnk268bxONMh+OrG/q2neNdI+XZOeSE0+gdJLLPyDUH7YsRtBloLv7Tx9Lx 2djuie1urUE8cShkZloYXQjcgj99w0IxdWx6FkeISv+u+Ha1n6hUOk15wyK8p2snyqcw fikUhuKOMKa5WgA4BaKYp70euRK7kdjWxVyAuwEhLiJEmNv2fqZfD1RoTUCY5TwE9A29 gfgkovrzvAvyS1CDUPEG43I6Hwngd15jU5eDD3DKPe1rlro5tvYt5jUY5Nam5MQYpvGL fROJ3HiGFUgcXzuoeFBPXAkV9d0ZdoTjeE77LprD3k1S96+wHJssIUgoAyqS4y268JCP 8uJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680294478; h=content-transfer-encoding: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=GK0MF0uNmzEytcPCm/B24vsna4+KtlPH2hXHihrk2Pg=; b=GxHozvOZhcYn3FgXpOy7h9MY83vzLmLaHHZ2vwoIoDr+E4y+xnsYMjONxl9C0YIYGP nJQGFIESqngWhC1AKEcjQUZp7MxKjmxiycXQafkXdaaBYy1qWemxmf4JnpECKJHAht7H UESNWY/+r7RnzzkvTwd0oiWmyy2UPZJ9Hi5lbfcSD0AvRwptcYkCIbJhIjL5YdcWJfy7 ebPFmKUPVNOpZeo7HaEONieb2DNcYwHucd5snc9IIyHKECA/MfPyPP8gkmSYnnRdMjBY JIqR9hnU3B3RG4p+1bOPfRRlCIm7wKLF+B5hCEVYa8pD9naI240dzMci0+SWBG6VwXSF gY0Q== X-Gm-Message-State: AAQBX9dLDHkZgP90sfcSSgz44jg44PaehTR4iA0Qb1s02Bf/okpv701T mDFVRUTv47ZNYnE5mnUjS1ghUjhL1b1wRMq1WgQ= X-Google-Smtp-Source: AKy350aujevccavshd57e5DTjfc6arS/wKqQ78BHDMvmLt/9c+KO7t8cHimGhGNrYQFNiE3Yn8wTcaUYy+D9jbsyOvQ= X-Received: by 2002:a50:d58c:0:b0:502:719e:e7e9 with SMTP id v12-20020a50d58c000000b00502719ee7e9mr3286257edi.1.1680294477852; Fri, 31 Mar 2023 13:27:57 -0700 (PDT) MIME-Version: 1.0 References: <20230316170149.4106586-1-jolsa@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Fri, 31 Mar 2023 13:27:45 -0700 Message-ID: Subject: Re: [PATCHv3 bpf-next 0/9] mm/bpf/perf: Store build id in file object To: Matthew Wilcox Cc: Arnaldo Carvalho de Melo , Jiri Olsa , Alexei Starovoitov , Andrii Nakryiko , Hao Luo , Andrew Morton , Alexander Viro , Peter Zijlstra , Ingo Molnar , bpf@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Daniel Borkmann , Namhyung Kim , Dave Chinner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: bffymycnr8hw8do5rf3ecg79eytsa681 X-Rspamd-Queue-Id: 765B010000D X-HE-Tag: 1680294479-735165 X-HE-Meta: U2FsdGVkX19qgdzzGisc+t5dT6JOvnR9XHwIEid7bL6dIq+jSTTF8yFWc5LaW1hSXTKVFhfMkA2CdWKRPZYjAMfzDh/wzJgokT69+WfjZGkrdk76BrbkWx4497eSHwgNwNKnKFLQZYwJfWm3n7axzdaI5gk5sRqkaMOmvOJKgd7ir/rLLJLp0yCfvbqmW+qkbuaV2r9tTReh8my+vn+xTcGXfeZTd0HkXm20I/4pQE4PHpFyClq9r01ETUpteQmbBFRUnBlcg/Xh+PBJOjP6XsjTRf4Vn67/ArsrsMITAKHHZ6k+Pr4BFmHYtkVVEBRFGIuuugPhlh2jGYuP/XWSa0cpp6WEJFWXiwoAma8yfK8iCewC3cClV1rVRxCOado6uJA1XIdrDpbZn5HhJDfvO2/LoLXSLtzuAYmI1yPnJjLjuprxplMcuHJL1PLs0qDf9GpURxVCdu6s5CGcjl3ZvxJRZO9CanrHX5kpdozsziUrovmG6yAbN/ucKurGA21QosAD/YjeWYZST3Hbn31fJOS5sCF3qZHaMSMQYuQm5QnNtY5bUnhq5cCGPXdixykZcDuLAm1bB/rYnreJplHiLn560m/44nOaprsNuPV+ECyH3R9+/t57AgxBtSbZNs/uZQYqvJt9zzS5R6jes/5mWw5DEFkQ1Nm/0nuYEom6PkTN1I3IyKZ0LgredDvKTYBk8245i1RFxrTYg2THU62dJ74yQMbBIq+gUBFyfpQrKLOmkkQZ1opKg0+a0YwPRD+NRJ42oqw376Z/lcR6WW7kJjuN/ae6T3aOQXcghfdST1qqswicpGmtbqGDjDNwtnfhmOacKlxcDX9bIUhg/A7HNTPjRQcNE3NNA/IeDQdNPbmAM2G4BgNmapLqTlY3o9mmXi7odegRZ1sRmPeK0TBQHbhLGYRYVdf+AYwa5PJh7Q7wjWxVrromTCA3cUzVIulzfOwkFF2HgsVP03S7A/g rYJqcbkm oywWiPYP5QhQL2IKu+hyUMKYvdCp/gxbcSm+NnTVsAm2YSgDtEMUeGclEo9og/D89ftAa+6JOph4/HkTW9ah4O1T6bAqKpYIpOr/dXpMhtuQPkesATPyO1ABU7MT6KQHLy88OERdLLuZ7HYGDrgDOPQi5o0i/SN1rpjVg5e0StFQ6OSX+Yfl0hfJXEhr6tObJbD5cTgHuWV+hb1BHNLtYD4IFjAFOvOI4AjZE4zuz+yL6TW9HiqiYq7zISYjPt6qyccni9Za+Uvh3xDZuE3bXhXOm6Rd1jzn1lU0i1T0oCp7Zx/9bFfdBpH9zxx0WqLlJCQGTdbojA5+XO8nibw1yeJpNJOgEBmcaU167rbYcS6fCwbcSJXHox22QGTUb/wrJ0+uXQSn7tu1soNIGBkJkpuAqQI+CErkgNY/MedVq95nH7Ai2yCEDuEEcOiTHKqSm4he0JiKIiPBEf811Qd44mwC9KYcTs655/TTHXRQV6I+8jx+dYoErhv29OEpy5QKm05UzZX0a18/6UazikstcnsAtDW6CfsmhrsivEB7LludwotIMSv059tsbU4t7ZX7x3TvEmuotEjeQOvYclLRwpkO5Vg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Mar 31, 2023 at 11:36=E2=80=AFAM Matthew Wilcox wrote: > > On Fri, Mar 31, 2023 at 11:19:45AM -0700, Andrii Nakryiko wrote: > > On Wed, Mar 22, 2023 at 8:45=E2=80=AFAM Arnaldo Carvalho de Melo > > wrote: > > > Having said that, it seems there will be no extra memory overhead at > > > least for a fedora:36 x86_64 kernel: > > > > Makes sense to me as well. Whatever the solution, as long as it's > > usable from NMI contexts would be fine for the purposes of fetching > > build ID. It would be good to hear from folks that are opposing adding > > a pointer field to struct file whether they prefer this way instead? > > Still no. While it may not take up any room right now, this will > surely not be the last thing added to struct file. When something > which is genuinely useful needs to be added, that person should > not have to sort out your mess first, So I assume you are talking about adding a pointer field to the struct file, right? What about the alternative proposed by Arnaldo to have a struct exec_file that extends a struct file? > > NAK now, NAK tomorrow, NAK forever. Al told you how you could do it > without trampling on core data structures. As I replied to Al, any solution that will have a lookup table on the side isn't compatible with usage from NMI context due to locking. And lots of tracing use cases are based on perf counters which are handled in NMI context. And that's besides all the complexities with right-sizing hash maps (if hashmaps are to be used).