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 21858C3271E for ; Tue, 9 Jul 2024 03:15:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8279F6B009D; Mon, 8 Jul 2024 23:15:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D7AF6B009E; Mon, 8 Jul 2024 23:15:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69E9E6B00A0; Mon, 8 Jul 2024 23:15:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4B9956B009D for ; Mon, 8 Jul 2024 23:15:04 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C43C980B5F for ; Tue, 9 Jul 2024 03:15:03 +0000 (UTC) X-FDA: 82318747686.09.E78E18C Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) by imf08.hostedemail.com (Postfix) with ESMTP id 0341C160017 for ; Tue, 9 Jul 2024 03:15:01 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lc0PmQbD; spf=pass (imf08.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.166.177 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=1720494887; 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=4ZZio3Wb7LL1vgb5mt6lXU9W0NhwIVtcCUDpe3CmPn8=; b=qDprmX2Eu39trVLazt/4UD7LIfL+EeYVcJn6KY1fRavQ/dm08AKZqcy8wooc9eluVRewj+ MRUCtNVYHfJcIqpL06m5Nd7a6G8xa63/PBd4HktM9OrPfYfTzEo3My+T72i9Gu6Oep39N3 BS4SWEwtSAavVxSRtyXtoiJ+aQwdFm4= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lc0PmQbD; spf=pass (imf08.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.166.177 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=1720494887; a=rsa-sha256; cv=none; b=UcZO7CoisJKgHztr6kBRtqf6da0bpMaZA155oWu9Eisl9ATq5Qe/w18gHfxEMRZR02Dsih gD7WBQQhkrgyp9EPXhjn2G+q9sBdfwJyBOYCijlUdpZJDM8Dze4saq9cODLyXxLKT+IJxa TBKSgRp1h3NrHVlEzzo6B+GJqJ4UJhg= Received: by mail-il1-f177.google.com with SMTP id e9e14a558f8ab-389ccd2f0abso4050865ab.2 for ; Mon, 08 Jul 2024 20:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720494901; x=1721099701; darn=kvack.org; 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=4ZZio3Wb7LL1vgb5mt6lXU9W0NhwIVtcCUDpe3CmPn8=; b=lc0PmQbDIKAcTsYjF5lI6S/yHLo+db6JgvtEaUHBPsDv5pCxrMRnUrOLft6hVzEXtg HY3VFUx87rS0NbIELu4QQQTvzKSNZA8thJk4NfxQaHnVxxdotatZWeouNeyJEWcBPoGI OXmPBOVWtKpo+QPSpRmCgkWFB4RNC3GtMOVczJJoyPNR8Ll1HCMJ3Niw32tJ4g5FRpkU kyVDOY3oMu6rKKktefpMbdF/bxUw/8tZZDKc6c9zjGtlrQC6RXew55KIZR8h6guRYeBr f6gUo3l+2+WR6Mi1KbmwAp3n/sDUH0A9IFF+EH2lw2CTF032wu/o5Gvd9qJqWEVQtau8 sbwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720494901; x=1721099701; 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=4ZZio3Wb7LL1vgb5mt6lXU9W0NhwIVtcCUDpe3CmPn8=; b=OpDjKSGD2wvSfoovat5bawvi8/qWLDLVFqojen6syKW901WcXJxa+mGNYBWo6Qg/Wd wJdIC7VKqzSfKkOtVdxbSscsR2fGUEHMAI/qIT7XJPfRDm0EoHHozXr7tSOs3sNYc2Y+ elVyCnxxwsuWuHk5iUxSyOmvGDTG3mV3FfHEEkA4uw8/tuhd9P4HIyzvUamBjNFrAWXN jbtWT97CYIsJW1bpdtpG2CQSHtE0aSYfntsNhCp4+UNGygvMMJWosYQj9IR27xVkmnYe /QD3URl3zulpQulPFGzDnE60NHfHbtttntXmkrLsVKaWnvZvCj+OfUCaE6fjzFJfid7U GIIw== X-Forwarded-Encrypted: i=1; AJvYcCWH1sXFP+mOrK6e4/x+UrahqtV8epPiTdU+MnwGoxGnXm6o1PiBm9whrse5r7p06oJF2gjPYxZVXONDKzmHKAKFI5A= X-Gm-Message-State: AOJu0YzZ2e9000+Z/6MtByKCmlFjBLFphLX03uFXR3z9i4sk9D79N56c Y0mtpJVJ0huLOAAb80FlWGMrCUwb8e39siuUJxTkUI1Frx+n5v//crlecztNdt+E1PcvkTA6/AH uaJEg1LWgvZQbnFqDQQFC3eYbqTk= X-Google-Smtp-Source: AGHT+IHHmXTRDZjaslqjVeI4snU9357L42htoF1UJL+C84StlG4Jwrg6KF8y1KxRD7RthYqkPyl9yDBwl8IWF0Yrv2c= X-Received: by 2002:a05:6e02:1847:b0:374:ada1:295a with SMTP id e9e14a558f8ab-38a5848daeamr16806195ab.16.1720494901020; Mon, 08 Jul 2024 20:15:01 -0700 (PDT) MIME-Version: 1.0 References: <20240627170900.1672542-1-andrii@kernel.org> <20240627170900.1672542-4-andrii@kernel.org> <878qyqyorq.fsf@linux.intel.com> In-Reply-To: From: Andrii Nakryiko Date: Mon, 8 Jul 2024 20:14:48 -0700 Message-ID: Subject: Re: [PATCH v6 3/6] fs/procfs: add build ID fetching to PROCMAP_QUERY API To: Andi Kleen Cc: Andrii Nakryiko , linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, gregkh@linuxfoundation.org, linux-mm@kvack.org, liam.howlett@oracle.com, surenb@google.com, rppt@kernel.org, adobriyan@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 0341C160017 X-Stat-Signature: kntkifmjysm8f73xbmkq4ysu56cahodw X-HE-Tag: 1720494901-388715 X-HE-Meta: U2FsdGVkX189Up4xST/YuP58Jq7h2yQt80MoX44GiXXvguRoHOHR2CZEUngrqDlkrEv9C8aq334ZW7G78dvlz0LDMi8F70BHKoH0UprCOcJwNx7/VJXavumkMGC3wNmatv6/DMbSCRvpz/K5MLQg/xtOos31ixi/uTI9B68GjmID07ltNVJF7dDpSNKZlrG+0MiuqNyBSg70EuH21TmY+PhckfQ+2sqC1pKSDY4+GgN41+hrZMb2Pw/5OByLwIZ9urPMSLESEh5evpU7p3/64MdUR5IsIQk7D+3tZxW9I6jylTQcx8k8VI8mxCJEiqtWtlH0z094GAQ52xyaHiSYQ9S2IBVUWm4lUuhdmkQoE/zZYxUmzNmzgGuP7pW/DJaLGCHmDn41vVAS4z9mRl3KcFbwkjYEOa6I7e3EejXcShJr8XY/BbWd1ZXwr1Ow7zuIkY0THU5ZIRX4GFQnCXouPpsVJlpLhhJjwCnJAY5+3a/MQ3FgYyfLnNNHATRNh6wjoKqUbT25CaEaC2+qa+Gk5Wl8p9eTCPkqjrWIVXtmqYdFHBky4RPmhzSlrnccgO/+IWw7YkZsYSQaWr4+BG3rDe/VzQ6t+V0gLASTUcEmI/72sCGequS6kZ7Axw3mQUSt08cwOYK8N+0dkHGLNZkI6v2LcBYp2jdUSUoYhCuaUvOQlaohmjJxM/dkL6Nb2LiIvq8taH4JhX236x0WfgJQI8ryUNkQoOwnXi9Q+jb6FHXk2vLaJhr4tD0tup0g2oOx5JyuW3krbOyNLZX4/UD2FIqGKxWhHJgWep38Ht2TI2ZIGp0rcF7XTngUmCD9E1YxHjgu7s4AFF2m9evHaTTGqAceVToYxG78z3P0TWi681HG0waFeg7mLK6RSwwkl5kunukGP5l+2QphZL58eghTzKOCGCqJz4FXU62mKy6Rel8V0IEnZKjawSSHU3S/y/JUwt7LKAuw+YaN298LPMN 7UiW+xpA csxDQbDMeAqjmv64IJQecpdTPSDvA2iE7YIJniSOr4FwGwxaO+R0e40NgYp95iSJWIMEKx37rGcTlP7XUKJBXGuYf2u8MVf3AyCkmsUlEX/oT72MrHftH2QCgTBs6OGQymk1DkQZjyZ2oMH+gGV58QstFuKQD449EP3Fc+C1Otr/59kUirpl2tyO3orUe9/RQlkC6kU0lUAf+Uk2BdDdfBH8b7+VExB/M9FBovuiLlJrrsA62YXw+dkZ+pCoOBX2pWCmG8KON/52Fg3lbxfC1x8Gse/Pgkefv9eFzX2g1t7hPKAQoPETc+TlMoIQSPj0KXVcJ/wrw9X98+x6S21zpiHO684C6QLRLsrBnTI+hfF8mfF9u/X30HuqMI5k6S5iLQTVWUNSfS/qOp0A= 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: List-Subscribe: List-Unsubscribe: On Mon, Jul 8, 2024 at 6:27=E2=80=AFPM Andi Kleen wrot= e: > > > So what exactly did you have in mind when you were proposing that > > check? Did you mean to do a pass over all VMAs within the process to > > check if there is at least one executable VMA belonging to > > address_space? If yes, then that would certainly be way too expensive > > to be usable. > > I was thinking to only report the build ID when the VMA queried > is executable. If software wanted to look up a data symbol > and needs that buildid it would need to check a x vma too. I think that's way too restrictive and for no good reason, tbh. If there is some .rodata ELF section mapped as r/o VMA, I don't see any reason why user shouldn't be able to request build ID for it. > > Normally tools iterate over all the mappings anyways so this > shouldn't be a big burden for them. > This API aims to make this unnecessary. So that tools can request only relevant VMAs based on whatever captured data or code addresses it got from, say, profiling of perf events. And if there are some locks or other global data structures that fall into mapped portions of ELF data sections, the ability to get build ID for those is just as important as getting build ID for executable sections. > Did I miss something? > > I guess an alternative would be a new VMA flag, but iirc we're low on > bits there already. I think we should just keep things as is. I don't think there is any real added security in restricting this just to executable VMAs. > > -Andi