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 078A3C27C79 for ; Thu, 20 Jun 2024 18:51:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8C1CA8D00A7; Thu, 20 Jun 2024 14:51:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8933C8D00D5; Thu, 20 Jun 2024 14:51:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 711E18D00A7; Thu, 20 Jun 2024 14:51:03 -0400 (EDT) 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 511666B027C for ; Thu, 20 Jun 2024 14:51:03 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 05DE31404DC for ; Thu, 20 Jun 2024 18:51:03 +0000 (UTC) X-FDA: 82252159206.05.91C5192 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by imf28.hostedemail.com (Postfix) with ESMTP id 2BF3BC001F for ; Thu, 20 Jun 2024 18:51:00 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=U73vvu6P; spf=pass (imf28.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.53 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=1718909448; 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=89o8ujkIHq6PMM4aoMW4/XgYMSFc2QsW0KmDVaz6Gcw=; b=f4XUFTBQV/WFwNURybF1oMi4TdWzmJFEYpLYhIM4gP1ev46D33sbXDzUQhJ6y4hAbL5Wf0 k1p6c99OTqQcEQrbIUwXt/iEDGBurDzb8ETaVZ2NnuVRkx9u1DUGxSn1GQBP8MhyJGY+aT Hmc8oPYINnI4s5DXlnPi6s5kJrVW+XI= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=U73vvu6P; spf=pass (imf28.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.53 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=1718909448; a=rsa-sha256; cv=none; b=vnPI/ChQkJYqkpSPjjRkBpiiGeZac2DwYKezDVo2zCKmI9NEY3ujhgzV1SsvWcHQWg754M uzgAaVdOUfEqegS0Gz1L7/AG+dyqEGqaxIWKcgxiV0qvHF0zc2DuZbB7OERe+9r5Zua6Dl bT8hZxzoTtcCQqm+kAAra28sPo6DruA= Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-2c7dff0f4e4so1039580a91.2 for ; Thu, 20 Jun 2024 11:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718909460; x=1719514260; 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=89o8ujkIHq6PMM4aoMW4/XgYMSFc2QsW0KmDVaz6Gcw=; b=U73vvu6PGJ2ew+N3i1Jo8HdD3KGqv7fxjRvQ7IRWsLiTFqeKn9Fz3hvqriqLqEWVWC akhdrUJnI+zvqQeFJfTjCPvGbaA74Xnmt2TXTE938mvfJ0N229hJ7044y5aPlfe63ie/ 0M8opya6vtKeWdscPsSW+thFXK+A2BjQ06mIfqI+9GiHh/oZ35Mz8nrdmmH0d8fSmsx1 qwnRyAECFiQRbutrWfvsNQmV7jxjVX46xvHZBsXu+3UTTzWrl0SU3cQ5BY9XylaUXIas gb3RICnvmI/EHCAppM90exC8j15eAbbqYL5zjpzMukh+mC+JuF8Sj/rNB/CbxblcnAZA ugog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718909460; x=1719514260; 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=89o8ujkIHq6PMM4aoMW4/XgYMSFc2QsW0KmDVaz6Gcw=; b=iP5IrX8EEPqCQsFJW8JZTwL1I2Qegz5DwI4kgYGD7SJOI3w2YxprtyKuDt0kbEHiYW NxOxgSpcZdA0R185AGYalf7i2Rq0S06pBzq+dmIzzKj9dlrob7akuWJGUTCG5PcR8phx L7qM1SdgO/yZvb9wI0bY+UrlKrkb5iHyK0qdx3vGX34hdArs2GcP8LvkXNumV4ZKVChS mlq819c/MJ6GXQEhzvoOmw5F1iqansVF2qEr9uweCcVPf60NpDDsyO/97SMGUDpgrnb+ GCRZMLKqJYs1MQnVXfTMeRBzPyiE83GOu6+h0ejEj6kdUO3M3i/3rhLn/jxZ2J8R0i/3 2I3g== X-Forwarded-Encrypted: i=1; AJvYcCW/UiZ8NFN3spXQI1Q0Vg5FYY/kCKGztB43azt6ywe3hrb9NUiOYiaqhdFPWres9p2+ZvWr940NJH2+i75SqXYJDf4= X-Gm-Message-State: AOJu0Yw1VBpSXGbvI+MiEpx7SRL6cs7gYOiu30lSVhpMCUAIGdQbKVue 3eoqbjJV/VD3Dmp09uRf2gpZPIVawDyKvPkREAhx0Sm0zscUwkpcw8jHXKPx9kFuz/maYyiuzge xhPn8U8j5CkNhEu1Q437sJNhyXBM= X-Google-Smtp-Source: AGHT+IHejfXXhcSCG+8k7941Dm3EbX0ewHLJ/3VEPrjpG3OW0flhMpyIcVTUB8X7jTk9vLYpIJrEnWTTU3wycg008lE= X-Received: by 2002:a17:90a:1346:b0:2c3:2da1:c8bc with SMTP id 98e67ed59e1d1-2c7b5af9211mr5980842a91.15.1718909459936; Thu, 20 Jun 2024 11:50:59 -0700 (PDT) MIME-Version: 1.0 References: <20240618224527.3685213-1-andrii@kernel.org> <20240618224527.3685213-4-andrii@kernel.org> <984d7898-d86a-4cea-9cdf-262b9ec4bc84@p183> In-Reply-To: <984d7898-d86a-4cea-9cdf-262b9ec4bc84@p183> From: Andrii Nakryiko Date: Thu, 20 Jun 2024 11:50:48 -0700 Message-ID: Subject: Re: [PATCH v5 3/6] fs/procfs: add build ID fetching to PROCMAP_QUERY API To: Alexey Dobriyan 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2BF3BC001F X-Stat-Signature: yyac6pgniuf1iccqp5s43sawsug4dr14 X-Rspam-User: X-HE-Tag: 1718909460-34516 X-HE-Meta: U2FsdGVkX1+nLkkjbDzcG0r9otQY+sQ0GAJ1jj3+g5A/bnGwR3pW4jzMG4BXgoAmBlHzCPOPPFTgbfHOQSLY/wcxT9tedWIk8PqosjhXpBn/6XrNoJ3sStRQ2va8AssJMZG3lfJ1YFcBtzN/q5QUI/ZApzEOqycYb6mVc9v3wddKtFCnt075fzmSY4sIooaq6e7keYr0VvSBd4kFtbPiJVj4O9SY7NbHv9AeomNlglztKwyk7qazCOcqUmMVdAxazlczppvFdwIbperCAn6j3hpwH6POjUL6nYC0DU3AB3cVCh6SdUVIAp9DW2CkyxBRpgqDoBoBgoILKtjANvMFlQ/Q9Tg4ndMHiBHJmXydGA5J58UASmQrWbCVkTIlghIxTR5oBPmn6LB1AsADuJlmQDF2sjyq/KMGRT/RJ2bfbdTo9EgPYLiba5kIZw2eBfefHL+9k6lMmznKL6Ld5eXrc7QAhcVpl1s6at5vpaKedLe5KWTFeatMaPtNLgCG9LxAhFEYmORsPY4VUYn53fwlafeVdYNnkVt909YnmFSuLNClzbJPnVwqu5hUI5J22blg1mv4WSBdP2nSsmud5iQ3WBvjhw1QzZ7fYswDmTdJEbLcE2b0Ifq8VDz4qNvGs8lMykT5amw1Kksb3GKhcPQ6qpTEdOqHdmI88DDFFDcr3+9oKnxF8A5uMysBZaB9umyFHx1LigXb4DMFt9S3wwbNVUXXWtIfoDtNdZNYtSVs16GfLw/gQ654xXwIIr+daFYez4Yh01tX2fY4/OvwQ6p/dhw68ySBBLPQosURYkgAFX2n/SudhcD0WBeFbRHeBWVq6NlRPg9SpOXl6/o2CBBb6180EHV1wXNKfZPfe4L4Ybwsxnji4bacXEtxpLEkJyGXtv17nhJ2wN0M82qkcGcB2v3ntVrkqYY0lwYCy/5ozYfm0MfzzKgeFFYyLZFaetduLDlzTf28ctm4LcjbYdV Agz7nL1B TAZza7cTBX2kh1ChmwX4wxfkBFkjYMMxs3k8HdRHKqAcznu7R3Z/VOGsbhqVpHMD645/d+TSvd0mUe8aNXJhdOMzDcYZ3uziO80m0ld6FUbAfrHml/r8dPrZIGDNmxlTC5CbXeU5OaxJxXdzLEQRl+oQjW+zGs9wc5cqMXN1r5CQrXemJXULrtL+4YF7b4S/i8FfZ9ijy3iUInqa3RWyXgOYTT4y+IFHUdNmgg7dgxv9tYGNlTsQhg1ei046aY9EE8gBuTcA+PCwm+MaXaJY5166VqpKF5dFlkPueCC9fqSEdC6oW13lf88ZWkXjQBynZPUVI3yB75uCzQK5WmANGnOwSEimKE6vUDtjL+Ryf4cvsgHOcjSFc9Gq5VgON8ALJk/a1/aTpj2qCnsKOOs/Ws0/LWA== 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 Wed, Jun 19, 2024 at 3:14=E2=80=AFAM Alexey Dobriyan wrote: > > On Tue, Jun 18, 2024 at 03:45:22PM -0700, Andrii Nakryiko wrote: > > The need to get ELF build ID reliably is an important aspect when > > dealing with profiling and stack trace symbolization, and > > /proc//maps textual representation doesn't help with this. > > > @@ -539,6 +543,21 @@ static int do_procmap_query(struct proc_maps_priva= te *priv, void __user *uarg) > > } > > } > > > > + if (karg.build_id_size) { > > + __u32 build_id_sz; > > + > > + err =3D build_id_parse(vma, build_id_buf, &build_id_sz); > > This is not your bug but build_id_parse() assumes program headers > immediately follow ELF header which is not guaranteed. Yes, I'm aware, and I think I stated somewhere that I want to fix/improve that. The thing is, current build_id_parse() was built for BPF under NMI context assumption, which is why it can't page in memory and so on (and this "build ID has to be in the first page" was a surprise to me, but probably just a technical shortcut to make it a bit easier to implement). Regardless, my plan, once this API is merged, is to follow up with make build_id_parse() variant that would work reliably under sleepable context assumptions. Hopefully that's ok not to bundle all that with these patches? > > > + * If this field is set to non-zero value, build_id_addr should p= oint > > + * to valid user space memory buffer of at least build_id_size by= tes. > > + * If set to zero, build_id_addr should be set to zero as well > > + */ > > + __u32 build_id_size; /* in/out */ > > /* > > * User-supplied address of a buffer of at least vma_name_size by= tes > > * for kernel to fill with matched VMA's name (see vma_name_size = field > > @@ -519,6 +539,14 @@ struct procmap_query { > > * Should be set to zero if VMA name should not be returned. > > */ > > __u64 vma_name_addr; /* in */ > > + /* > > + * User-supplied address of a buffer of at least build_id_size by= tes > > + * for kernel to fill with matched VMA's ELF build ID, if availab= le > > + * (see build_id_size field description above for details). > > + * > > + * Should be set to zero if build ID should not be returned. > > + */ > > + __u64 build_id_addr; /* in */ > > Can this be simplified to 512-bit buffer in ioctl structure? > BUILD_ID_SIZE_MAX is 20 which is sha1. I'd prefer not to because vma_name can't use the same trick, so we'll have to have this size+buffer address approach anyway. And because of that I'd like to have all these optional variable-length/string output arguments handled in a uniform way. In practice, it's really simple to use this from user-space, the only mildly annoying part is casting pointer to __u64. But as I said, for vma_name users will do this anyways, so not much benefit simplifying the build_id part only.