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 1196BC25B74 for ; Fri, 24 May 2024 19:30:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2AF186B0082; Fri, 24 May 2024 15:30:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 25E406B0085; Fri, 24 May 2024 15:30:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 14DFF6B0088; Fri, 24 May 2024 15:30:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EB4886B0082 for ; Fri, 24 May 2024 15:30:34 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 625DF120135 for ; Fri, 24 May 2024 19:30:34 +0000 (UTC) X-FDA: 82154281188.11.8991E1E Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf16.hostedemail.com (Postfix) with ESMTP id 74F7118002D for ; Fri, 24 May 2024 19:30:32 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=b2T4RKH8; spf=pass (imf16.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.214.182 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=1716579032; 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=dzHU3P7qRxjg2ho0r9MNensCeoxNpPcQCmFpOL/oYJM=; b=3CP53jpquXrGNix/W8y2hc3i34j7R5rYxDC6t3RIF1WMyaBh1vWDvTgEBtk514wn24L6yk DNRf5zf/bgHOU7n8DzWWEL4gWMZFxjUlzK7eW/HhYWtGxCtPj8KFswdYnohZT3rhoVfOPS mkGU19hvutLFwO2XtXcBFvVROuz906s= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=b2T4RKH8; spf=pass (imf16.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.214.182 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=1716579032; a=rsa-sha256; cv=none; b=tGBbFpFso9gZLQVM9CFGjdysq8xzO/n+rjhySFoZV26YRmh+Uk+HZaVNTMadXg4Efw1gEq RUHViB1fxyAK0tBS7prQXsVi570y854QmK53Q8dQQnKQ94DN0hDb3yA9VjEcoG8Elt40nd 1MZyslDMA8sc44gWxt4HkpGc4B3PBrw= Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1f44b52f86cso10203205ad.1 for ; Fri, 24 May 2024 12:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716579031; x=1717183831; 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=dzHU3P7qRxjg2ho0r9MNensCeoxNpPcQCmFpOL/oYJM=; b=b2T4RKH8TYjXtUIdXMcv7Ab0Za8eMeHl2oEo8R3VxvUkJcDToVrrzW4tCqV4Scg7of L/3ec17PFPNoMUFTPTGi4866OLEFAD/CBClihlWq+r1ssBaid1PcwxOqQqo7FAZ0Lw4f 6du79niE2xMhzny+TbhUl3kgJW8fMiBfOILfgXM5yM8EDj9DBeLDBe11MVIsywBSxkos 7npRaIE6wMD9xmKZdS6ZXLDogGtHrEGI4ilRqcFzuahmTME2qFjoAQ6IlRmrIMhdvSlW sMVqIwGR6kSFf/HXbPQZa9VDHTOf2m/FC9xvK1+xMLRXqa16PxYM+sagpOudXk4STIGJ j2Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716579031; x=1717183831; 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=dzHU3P7qRxjg2ho0r9MNensCeoxNpPcQCmFpOL/oYJM=; b=QxPn6RBHar3qWjCE/9uyKptzF8rF77vTHeBVD0S6sOjUXowwCvoma+eJKmv4vwkKZV TX31gVBOc92CF/CPBdqkN8d4OIWizQ9o2NFFNhqHsEefZGdRTvS698u5VOHJ++4Gq3NK a66/AoeUfZuEFdp4UtDm+46JlOz0SvmNmmD+mWUgiBacbqoNYDlG/lb+g5Y7+0nK35fr 8Jc0YmjAUSthe4z7J0N1zZXnpsZCYpf3KkHjT36EuCnMPI9MhZi0WWb1WxgbYZ1iGQlY tBWEuRIs8qdeImYqlEiFhKFJytazs9DIQf5l1OgEHbqXU251D5zu5tu2SvcyuCxp/HNU 3qVQ== X-Forwarded-Encrypted: i=1; AJvYcCXBzG4m6+fdbvA02f04eueomVR09uC6NW9xbtJ6DvmpSFssnpcV0Lr5R2D4IOp1K9a2xG50MjVc1vithKCqV6/nrHI= X-Gm-Message-State: AOJu0Yy9dmIjV65xZPqYic+CiF6cuFfN3TqXxsYmg/hc3Ao2YCFi+FNb ls07vI8v4GUqFc36p6DfCM1N1VuJSmGsknTtHVY/ISKqUNdM5joDj18Xt+CJSobi/Aop5K+SCnr bktWoi6T0j9ZmTA3JP7AwW6noYOk= X-Google-Smtp-Source: AGHT+IErPGmKm79ivkmkKeo0JgNi86h6exL4rS7HdkRJQeYCQL17fT0j3PSVuuXjGNENXBV8IjvDmTQR0TXeOsBeJjw= X-Received: by 2002:a17:902:ecc6:b0:1f3:4348:15ca with SMTP id d9443c01a7336-1f4486f294bmr43420585ad.25.1716579031155; Fri, 24 May 2024 12:30:31 -0700 (PDT) MIME-Version: 1.0 References: <20240524041032.1048094-1-andrii@kernel.org> <20240524103212.382d10aed85f2e843e86febb@linux-foundation.org> In-Reply-To: <20240524103212.382d10aed85f2e843e86febb@linux-foundation.org> From: Andrii Nakryiko Date: Fri, 24 May 2024 12:30:18 -0700 Message-ID: Subject: Re: [PATCH v2 0/9] ioctl()-based API to query VMAs from /proc//maps To: Andrew Morton Cc: Andrii Nakryiko , linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, 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-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 74F7118002D X-Stat-Signature: hygm4zhtk6os46iorgqy69o71hghb6yq X-HE-Tag: 1716579032-276019 X-HE-Meta: U2FsdGVkX19BpDgZKQBF3OynG8Nf5L8kmefFqme8wX1z8KH/yb6e3qxXIH4kk1bwHdw3Q/S6m5+oqUv4W4wmpovPWTheSyMgddRaOb8AYimoNjkAHiN2cd9SWTsGtj/FT2I4LvfBLjpcSjJW2/EcZb9tQNjpyV914q8S6QPfYHrztH2SeA0TJt7wapS7CKn6/eqcsd/AzB+d0JVg6tOVaKnCICgoMEBJcnisFtQbC/hpHMNyk5Q4zVsE1bb876iDLvZ6tqc2M2GJtlPd1Rme7dNkHHLfhEhvubKj2A2is+4yCOtjYURdvTxASh13ToVfGXPhIveYHemQ3puKB+m0gUH4VHbmbMZc3Ei4dBLIUmTQ4SBHbzMj0oO2VrKaa/Jnf3hG68s24298E9aM24QepKrIOHyPOOAQUZUqBkFFIE9G2iEeRsHjrx5Kg6pi8fycLUWlVMHlLcb6EXEUEnW06xU7xUAsvU4Nui60Idd34KbihE68gLmJV8rbWaYEwLE5+lI7TpLyU5mF8KtzwpORqX7dj16d7kGCL3Fu8QqYRLImCJMAAyHsashECUIosnq8OLKLjwpIaxGWXV1KjPPCuO+BnLP2eASGNWybflvLhaDwXUMwKnmASFdW4K+cYK2qqS6F0hTW7Yxc8t7a0+VU9E9jpFR6h38bfKaTKMRsOTWXPVxc35LbcbSlGqORe4R5MTYTlLsRsz4XqzHTwrLbFTsJPGtN4+3btEcHqryelyWrOp2mR06uXyJLRU+9OB+e+bN5djqtK2TObrVZIwm3i1/Lu+4RdoaKCn/ojFVTb2dC5ywSyVCWavt2f9298mpB6u7kUZfcnjokaxM3mwrS7tBhQ9GhAyLmRvlJVw/pIkCV1728YiYMvnb++AOfRrbLdgb/x6ADB4s19ZYSdXkqjlEFKOp6RLjWyRUNyxjEuvtHKjEJlX8DQKS0tJ5lsLlUdr+/DtO48hlUw71qxhm i+d/ljCp VKE9HNU08MItgMxCwrrucPH5dU7KmwI7O7O5+a9dbBahNgPa/8tp7qcABrs2ysAEEeTEoGLs0rQEsJCQNT7ga6U9o8orJVMF0HIjn8DbIyOs19Q7h/JH2rb29IlBx58n3KNK0G63cG8TRJYHzEJK5xI7FD2op/ZBmpLobjy5wxmzd8SSlvmlNdh9O2syIXG9pnaF0Ui5hV/jhF8tW1DENFPDpUkPuXpFky8/sh3HCBx9g90rtjdeXhy8GJCixS1059nuLAmB0MPvAdF5u87fwMTeXF++LNMJrRg+IAAGV1BpFFjbCpFr7J8BzxDWrOQKPAdotAt6OOtAWuTxabTjOEGf2mzuW3mc+6hHfafPogSFchPTQjk3f6GL6Yut5X9OMjZrySD/yQg9+lk5N+l98H1iB2CxvXqRSiB5rX38NIqtRGuqgw8xsukrLjs3qWfsq2cQ3Z4zRaQRs/NRC5OD96R0dUEtszqa08uXZE585UGW9RC126mmDiuGwkQUno9JofoYM 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 Fri, May 24, 2024 at 10:32=E2=80=AFAM Andrew Morton wrote: > > On Thu, 23 May 2024 21:10:22 -0700 Andrii Nakryiko wr= ote: > > > Implement binary ioctl()-based interface to /proc//maps file > > Why an ioctl rather than a read() of (say) a sysfs file? This is effectively a request/response kind of API. User provides at least address and a set of flags (that determine what subset of VMAs are of interest), and optionally could provide buffer pointers for extra variable-length data (e.g., VMA name). I'm not sure how to achieve this with read() syscall. Kernel has already established an approach to support these input/output binary-based protocols and how to handle extensibility and backwards/forward compatibility. And so we are using that here as well. ioctl() is just an existing mechanism for passing a pointer to such binary request/response structure in the context of some process (also note that normally it will be a different process from the actual user process that is using this API, that's always the case for profiling, for example). As for the sysfs as a location for this file. It doesn't matter much to me where to open some file, but it has to be a per-PID file, because each process has its own set of VMAs. Applications often will be querying VMAs across many processes, depending on incoming data (in our cases, profiling stack trace address data). So this eliminates something like prctl(). Does sysfs have an existing per-process hierarchy of files or directories that would be a natural match here? As I mentioned, /proc/PID/maps does seem like a natural fit in this case, because it represents the set of VMAs of a specified process. And this new API is just an alternative (to text-based read() protocol) way of querying this set of VMAs.