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 046F8C64ED6 for ; Wed, 1 Mar 2023 15:41:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D1036B007D; Wed, 1 Mar 2023 10:41:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8817E6B007E; Wed, 1 Mar 2023 10:41:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 749A46B0080; Wed, 1 Mar 2023 10:41:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6441C6B007D for ; Wed, 1 Mar 2023 10:41:29 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 13270140C65 for ; Wed, 1 Mar 2023 15:41:29 +0000 (UTC) X-FDA: 80520743898.12.1BB4EB9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf25.hostedemail.com (Postfix) with ESMTP id 394BBA0006 for ; Wed, 1 Mar 2023 15:41:26 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=WP5sZE1Y; spf=pass (imf25.hostedemail.com: domain of acme@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=acme@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677685286; 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=lChIvqr17QxTdxrGqlh50ps4+ehvdZdMui962rqbUfc=; b=qimWsIKD2nVMUdx8vrRBQwWBy4FqZ8p/B4eTGdEbwzS6O6Wd651goA8sWMeXa9k/MuS8xV 4V78CRuZzI9mkSFogfGD3c+Ji8TsNBsaZMwxxp9TIFYTfoERPkY4tJpxZuJLqhz3aOf3RA eOrr8HzL3R5sGyb388htKOAfH1t6Yn8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=WP5sZE1Y; spf=pass (imf25.hostedemail.com: domain of acme@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=acme@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677685286; a=rsa-sha256; cv=none; b=M9OWRZqW3qD3oTBciO5wzSUJcRj/8Fde3B8iBpfLiXTysw68nMZay3ceRmn0v1CA6w9lPs 6LwhrtQEOWRsMPREUW5CB/jZG5uUiit8ys6bKpmGj51v1ygobejYwEvXJav7l4mWe/0IED Ex0aCQY/0J3hFvXnEBiI+lW7h96k4sU= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1FBA761376; Wed, 1 Mar 2023 15:41:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43BC4C433EF; Wed, 1 Mar 2023 15:41:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677685284; bh=+qv6It5dGq3Z5N42zbPSFy3HhrWC6PisO2WM+ec3U58=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WP5sZE1YDwJteuvwIPzuCpoH8l4GQ3vJF3Z7Ew12qTs0sbiTAQoUAm1H0GN3neq0g kp546ONmr7KhXv/OQUUR8Q4v9HGkXwxIkySx2osYW0AECu/h+LiCSlJYGrORbKmaO4 g4uq3yVfsDmsO3UgjEtMI3vZbLHI1G/1eW9MSUs9j0ASnxnxkn+q8ygx2oaGcvrg0A Q/i341yhJtzkSLYJaV+MfWAud9gG08qCfdCloNRQrNSpIBiVsvNHpv1gjpIzbO72iC rvMoh/37GKzizCK7Frcw3ReUx01IyAYKX8YsZSlI3EI3xgodOG7Alct6KUWKTHNaeR JERnhAKzpSPIA== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 7A4534049F; Wed, 1 Mar 2023 12:41:20 -0300 (-03) Date: Wed, 1 Mar 2023 12:41:20 -0300 From: Arnaldo Carvalho de Melo To: Dave Chinner Cc: Jiri Olsa , Alexei Starovoitov , Andrii Nakryiko , Hao Luo , Andrew Morton , Alexander Viro , Peter Zijlstra , Ingo Molnar , 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: References: <20230228093206.821563-1-jolsa@kernel.org> <20230228220714.GJ2825702@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230228220714.GJ2825702@dread.disaster.area> X-Url: http://acmel.wordpress.com X-Stat-Signature: f5c89ib96ek5wcqqxeptkg5zefwmqtny X-Rspam-User: X-Rspamd-Queue-Id: 394BBA0006 X-Rspamd-Server: rspam06 X-HE-Tag: 1677685286-370784 X-HE-Meta: U2FsdGVkX19aDP7kRLk8bPWaPjZtwZGQ2uHaKl4clAYyp/IqLATjtoyYhQC8P3hzrlL1b3eEbsd0HThOnlvJgLWmHJ68J8fuDk29+kHQsg7QbIkSaEBHfsUaP16zARxLD5Sin8SSsJYJBTFBgLUwdx0+Qv2Dfukj7RIF6JvrzVEIvhWRDDi4dpkswoILxiL8KejNMtNK6ZThJSvVzzwbwWuCHD0UJFa8SACZQy0k6vZ0DXqw8kXZi9SsryJhLqV5euBYRrmMBlhgqjfE3/3rxqJs09h7Q6aBZWe9uR3RdgXq2hYYG40azp4JeRzN+2rXy1iVeR5pc9NJYP54vMFME1LnUdIlBPfqASt5sFsihQakR7HMorQztVjOgOGghSPwsWSchz/qLeSAH5UnJrRW3JR3VqE1qenIaBlODLF0yD3z4bDJ45fm5DJgv/qZJoPPyDXd6wI5VYWCox6CJFU6K83s9uZSJVfaJPA5Wb+g1o9eewssTMNssh4MXSEl6b/VoIOBl4yibr/ibKitBevOXisSnuOyXHHAq8ts7AmJNZbPeq5zSr3B0rIJN1p1vOC1q718HLCu2n4I8wvj94auQJkZcUncrdlM5VC2DlQc2vD21dlpBp4vKbTa+OBdN8gUYMzj9nsTVA2znOunp+E7iALiBulY63hJemnbNH5EBvNelsSgHb1TPbIyFgvxb+86ri8QG3EKCtLn+F//WfYiBIotLD7EJCHNtnfedUJBMxVdgO2B1ZuzwS2Ggco5RLBLb91R3PDyC7TBTk21UDSykvyKv0UnT8HHaDIKEY+WkOBuqvpofN9120KQcccK8XgUk1tQCVGqLVzi9XcAW1s7QhaeHjtkB5Kg3RtulnT0JCElbgXOFX3pZgvI87qgJiTpeYv1kJ0vdGrwdhBDVexC3G/Vd5VOS088cqutuDN2l8wqqEwKxy+sLt/yBVyLO8nkLwFVmLNsgRY5ZHDfxji ZdOazHCT 7vPktORVvzOjTrTl2fRj4tbGu0/AJ0iI/ElQKyUiDft+MIaF3Ay2LXLErfIwngwIFNq87221NztiSDQghO3xx39NRmhAntPeKDNAotrhYfsmZEXpn9sYDftgeD/hNj5MfA2xCUSXwI5GXV3nWwgmQBU0HB7n9Rile/KhHUIaBBhC+989+719NUpYG+2HhlAL/B6tPeBww5MV/g4uxJSrOeKP0AtzwZb/A7a71IB8IpNltqxNTBKaI72OKS+tV5Mbdj/21lPn1D2RG8/qVBOWZxw5TOBW4UysDz7cXypVrzJm0O0A8+8fnCScoZI7ISmYhOPy8OwPHs0mpfB1/BY5oba2Ed9rJFOfR3lBP/GVFoLLoleDIGW22XpVkL01Z8noBuW95hlwrG5StKbEelnXwRUseyERh17dBHF1Eq5D6j66oIkQGiLAcRvgmBnZFCzjB3ud4LQsDFh3xcJFJhjgZrTSL/Dte/MXPYozFdWhlC4CG7KAQaiLNQbBvwA== 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: Em Wed, Mar 01, 2023 at 09:07:14AM +1100, Dave Chinner escreveu: > On Tue, Feb 28, 2023 at 10:31:57AM +0100, Jiri Olsa wrote: > > 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. [root@quaco ~]# file /bin/bash /bin/bash: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=160df51238a38ca27d03290f3ad5f7df75560ae0, for GNU/Linux 3.2.0, stripped [root@quaco ~]# file /lib64/libc.so.6 /lib64/libc.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=8257ee907646e9b057197533d1e4ac8ede7a9c5c, for GNU/Linux 3.2.0, not stripped [root@quaco ~]# Those BuildID[sha1]= bits, that is present in all binaries I think in all distros for quite a while. This page, from when this was initially designed, has a discussion about it, why it is needed, etc: https://fedoraproject.org/wiki/RolandMcGrath/BuildID 'perf record' will receive MMAP records, initially without build-ids, now we have one that has, but collecting it when the mmap is executed (and thus a PERF_RECORD_MMAP* record is emitted) may not work, thus this work from Jiri. - Arnaldo > > > > 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