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 D3291C64EC4 for ; Tue, 28 Feb 2023 22:07:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5EA426B0071; Tue, 28 Feb 2023 17:07:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 59A676B0072; Tue, 28 Feb 2023 17:07:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 489AB6B0073; Tue, 28 Feb 2023 17:07:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3A57C6B0071 for ; Tue, 28 Feb 2023 17:07:22 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 121141404BE for ; Tue, 28 Feb 2023 22:07:22 +0000 (UTC) X-FDA: 80518087524.20.F0DFB6C Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by imf20.hostedemail.com (Postfix) with ESMTP id E42D51C0012 for ; Tue, 28 Feb 2023 22:07:19 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=fromorbit-com.20210112.gappssmtp.com header.s=20210112 header.b=mEiI40fN; spf=pass (imf20.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.44 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677622040; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YRCOA+ylhY8BYizlMsPJIRnUep7ueVrntpLfbub6Ho8=; b=garmn/UiTk9epEgwk894UQL3mR6az1Y42412mm+J0lVZ9ldivp5v/UTSue6HnjrQPAGXjQ KamM8Ipr+E2FVIjxQcyrzLSUxqXJy6VWPt8L1IH4FaYnyyhnh0oh09VOq6m6Tty/ur/Aao WPfqjMGSDLTTLPPz9Z1hFsD/rdB2WR4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=fromorbit-com.20210112.gappssmtp.com header.s=20210112 header.b=mEiI40fN; spf=pass (imf20.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.44 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677622040; a=rsa-sha256; cv=none; b=N6biyJv42DQovYyvfKxjjHDlQPuQnIc1U+YgClILr6LSp2hYRTiAIcHfS+OWGg41wdfvvW Neh6vO0c7Oh+QsWz4dGETvWbH9A2u+ceQRvB5cX/BZrcxxu9CeaMZSJEaBQywItH36MPGC CM/2syMPmo8bN8uVA0xO0wtdwYq+tu4= Received: by mail-pj1-f44.google.com with SMTP id k21-20020a17090aaa1500b002376652e160so11077411pjq.0 for ; Tue, 28 Feb 2023 14:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=YRCOA+ylhY8BYizlMsPJIRnUep7ueVrntpLfbub6Ho8=; b=mEiI40fNyimk2yi3utKlVT4Y6/XfiZzMjf8IL7rx8OZsMKma/44lGsAnfhQMTGCIOg XwvFvk+ZnJmZe9+sdLNWPkH1TdM+I4pNgrG1evG8lyp0RSNhFvrtiSo6iMPFR5Acpwfy Gq9DjLyDHgC0vFM4FAJfYVG+okzSshZtjiOJSUFJJZMUJbnLm8ZnikUj0L5RaPwWgSMG uvZmyfdN0NiOFEtzPa+f8Wx053NjMRjhE1YFf8eOyqQTPSMHobAOoSptMdDuJvuJm2Ek fCsUiKusB2DxBsB5dssZ2d7zDkIjFa6Epeo3CDsDMsfBdVQ2wwKx4rzUqmq5HEg//qc5 wJRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YRCOA+ylhY8BYizlMsPJIRnUep7ueVrntpLfbub6Ho8=; b=X1izCbYsHcwGboMHLb3k13MLTu0naw3ODZKY2Ckawn0WQXJL38lRWL4qXO0NXjogDU Ktcn9fTi4hxSoCy8vuQMlU4mWuz8N4R0ySAskuKmAqVny75bkLVyxYyK0GfHL83GXPCf GCYN+pcrYsFK9X5jbKkd1gnqAGp527Uh2mht5LwblINPj2+8VySu5H76Trie/6/g7Yiz vEfJWbVKF0yWcFzmqNG3Mi5RYhOHW5b38P/s4TR+3jFSVcjRvqvy8Xdv1bwak9SUz5L2 ZB63rVpo5kEoi2ETbxmdz8yhW1IHaEN4jLWeEAd6eZZLD23rOfzehvp7xrG29g6IR93n 2dCg== X-Gm-Message-State: AO0yUKV9G0sde4+kDTz7ABKmfpanK45/1OUvw9/KHvjuVGoY+SgSTg2/ MXoZO6deZTgt+ng2nkE6GQgXPg== X-Google-Smtp-Source: AK7set/jYgli/Hpbv8aT03CHshIOUH7bFyfP1JcTprKwyvrob0wmRB9dc55aO9ppjsNzZUynNOiyPQ== X-Received: by 2002:a17:903:1ce:b0:19d:1f42:b018 with SMTP id e14-20020a17090301ce00b0019d1f42b018mr8426976plh.27.1677622038760; Tue, 28 Feb 2023 14:07:18 -0800 (PST) Received: from dread.disaster.area (pa49-186-4-237.pa.vic.optusnet.com.au. [49.186.4.237]) by smtp.gmail.com with ESMTPSA id bc7-20020a170902930700b0019aaccb665bsm6957404plb.245.2023.02.28.14.07.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Feb 2023 14:07:18 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1pX87u-003HvY-Hh; Wed, 01 Mar 2023 09:07:14 +1100 Date: Wed, 1 Mar 2023 09:07:14 +1100 From: Dave Chinner To: Jiri Olsa Cc: Alexei Starovoitov , Andrii Nakryiko , Hao Luo , Andrew Morton , Alexander Viro , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Matthew Wilcox , 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 Subject: Re: [RFC v2 bpf-next 0/9] mm/bpf/perf: Store build id in inode object Message-ID: <20230228220714.GJ2825702@dread.disaster.area> References: <20230228093206.821563-1-jolsa@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230228093206.821563-1-jolsa@kernel.org> X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: yy8589ewzsfw5t1rqwxnjnx7nyd4nnck X-Rspamd-Queue-Id: E42D51C0012 X-HE-Tag: 1677622039-439554 X-HE-Meta: U2FsdGVkX19zy2a/aKGRawmaV3bQWcz2kVpPOdsMazYqKbLPpeWjlSw+3/NbGVPcUE92HVVl8j4f6tCt5qubqP6i8payAlvbZ2DDUckDxVLhNpi6H7Usm7eCUl6XYR3Ng9hJ0kYHw6nY9HDt4dzJSLoVRSBueQcEUCwESmtSbbaGYhUMXeEy+nLkwOkVPl4xrMGxfjczCYN2RjJOoZxJAYJXI4vx9nehZH1wtWr8sE1Pju4sNhdAbBMeQVEmMSTq9AQgjVsPV+5JmPNRW+DHi3OXFUJ98IyjOfzO5Rk1rD5mPQOB4HwF/q/zVsZ2NLyH1RU9w828PAvb2fKNM8ooMLk7ZnWQ42cmoyynWAeOIf0gYsbTdYfgG0MY1nKikSnZ6bbXs18ftX6x2NJyIuOmPWGGToZv0rNDtDLIoSoTjSE39XHpFGHclmyWvI8cnFLpbJqrB0u5PqFnPM5NlyH3cbOmQ8ib/Ou1EI/l505iBuuP8ng+oecftoVZfgh+qxJ22z46UjMaWgE2rodQL/7Hb1o8qpW0STTWj/mquhSK5N7Xd3se36v8PyVySeuewWCOBWK1rXqi2TU6jqTxrSl2I/7N3gwklcMl0plR3tL2L7xYTEDnlvyJYtD6u3kqeEqHlc1bngiXI1UK0/bLMa3T/t7pwWQCeRB4+jtBlxdhNdAZGF1gk2mj9eZ32zkvBTVMboLs9NYc3zXAz302T31RyAmwDfSCcK8cdHldpI8TN2Ddygh3PzdJSiq90zw5ZObZU53H30mFEB0OqzO7/SA+dId9pPofFvZ+a3l3vxvyR7yl/K9ra89Zy6mHJanigBqj7xv1T6GaqLXoCuRl4yvJjsr5rzqm5Hy/pjCReHz596hs/qp2Uzg6Y4BnCZtzThlqPXdzk6QAykAMmyEjruUYUzRZBgi3K0I/J0PNVuoLim681mE/JVYaciP/6atHuy2jgz7906eZAoK6ZmYY6Xj sLUhuG9u r15SfGtyIvrUdNaPdfSSdNvBk//avdDVcGuB7JJdmp3q2zYm0+Pey8SH9Wf5Wxjh4TaLbJKJq7U90oRM3g3atnJjg039MWYyqj7EzkkLKw4vF5hyotsvTZvbeavBWXhad0WyfF1msCHifpY+QhvSocmMdyx9npO1OfVZbXjBxWr//+H4F6Y9AWyQcufq9Yvr9QUMImPlL4zL/BIoNtHTm3BOYscG5spArA1tGOEryVkyJsBMDBimMbx7Wu6TOjYtDmV5IUvIvAYRV2pk4KJjqCb7sCqiz4SKHU2DaF+IByO9XIS1LoPTMhJPsTksQJkGGfrjf29357iLE4VmNFRXI1gfM4ewMCu+3/dLtVZsjd9iaFo1wxi0ZlPr7evR5ylFNOd8rf0V+SQ745WFgtBDI/qEDb71c3Gh4ARt1z2v99bB7VIScB0ODO84kBHzhnPzzyiTNtkUchPEBUYm5djb8wRHg8yWxSOr2q1/CsRRzD/6Li66Pb38se+J+MaR3nVG6E5w0rDy6Bcb9hKH9gc8oUmVHpQ== 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 Tue, Feb 28, 2023 at 10:31:57AM +0100, Jiri Olsa wrote: > hi, > this is RFC patchset for adding build id under inode's object. > > The main change to previous post [1] is to use inode object instead of file > object for build id data. Please explain what a "build id" is, the use case for it, why we need to store it in VFS objects, what threat model it is protecting the system against, etc. > > However.. ;-) while using inode as build id storage place saves some memory > by keeping just one copy of the build id for all file instances, there seems > to be another problem. Yes, the problem being that we can cache hundreds of millions of inodes in memory, and only a very small subset of them are going to have open files associated with them. And an even smaller subset are going to be mmapped. So, in reality, this proposal won't save any memory at all - it costs memory for every inode that is not currently being used as a mmapped elf executable, right? > The problem is that we read the build id when the file is mmap-ed. Why? I'm completely clueless as to what this thing does or how it's used.... > Which is fine for our use case, Which is? -Dave. -- Dave Chinner david@fromorbit.com